javascript
基于Spring Boot和Spring Cloud实现微服务架构学习
目錄
Spring 頂級框架
Spring cloud子項目
WHAT - 什么是微服務(wù)
微服務(wù)簡介
微服務(wù)的具體特征
SOA vs Microservice
HOW - 怎么具體實踐微服務(wù)
客戶端如何訪問這些服務(wù)？
服務(wù)之間如何通信？
這么多服務(wù)，怎么找?
這么多服務(wù)，服務(wù)掛了怎么辦？
WHY - 微服務(wù)的應(yīng)用
So What - 思考
參考資料和推薦閱讀
看了幾周Spring相關(guān)框架的書籍和官方demo，是時候開始總結(jié)下這中間的學習感悟。
首先，最想說的是，當你要學習一套最新的技術(shù)時，官網(wǎng)的英文文檔是學習的最佳渠道。因為網(wǎng)上流傳的多數(shù)資料是官網(wǎng)翻譯而來，很多描述的重點也都偏向于作者自身碰到的問題，這樣就很容易讓你理解和操作出現(xiàn)偏差，最開始我就進入了這樣誤區(qū)。官網(wǎng)的技術(shù)導(dǎo)讀真的描述的很詳細，雖然對于我們看英文很費勁，但如果英文不是很差，請選擇沉下心去讀，你一定能收獲好多。我的學習是先從Spring boot開始的，然后接觸到微服務(wù)架構(gòu)，當然，這一切最大的啟迪還是感謝我的一個老師，是他給我指明了新的道路，讓我眼前一亮，再次感謝。
Spring 頂級框架
談及微服務(wù)，作為當前主流的企業(yè)框架Spring，它提供了一整套相關(guān)的頂級項目，能讓開發(fā)者快速的上手實現(xiàn)自己的應(yīng)用，今天就介紹下Spring旗下各個頂級項目：
?
Spring IO platform:用于系統(tǒng)部署，是可集成的，構(gòu)建現(xiàn)代化應(yīng)用的版本平臺，具體來說當你使用maven dependency引入spring jar包時它就在工作了。
Spring Boot:旨在簡化創(chuàng)建產(chǎn)品級的 Spring 應(yīng)用和服務(wù)，簡化了配置文件，使用嵌入式web服務(wù)器，含有諸多開箱即用微服務(wù)功能，可以和spring cloud聯(lián)合部署。
Spring Framework:即通常所說的spring 框架，是一個開源的Java/Java EE全功能棧應(yīng)用程序框架，其它spring項目如spring boot也依賴于此框架。
Spring Cloud：微服務(wù)工具包，為開發(fā)者提供了在分布式系統(tǒng)的配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線等開發(fā)工具包。
Spring XD：是一種運行時環(huán)境（服務(wù)器軟件，非開發(fā)框架），組合spring技術(shù)，如spring batch、spring boot、spring data，采集大數(shù)據(jù)并處理。
Spring Data：是一個數(shù)據(jù)訪問及操作的工具包，封裝了很多種數(shù)據(jù)及數(shù)據(jù)庫的訪問相關(guān)技術(shù)，包括：jdbc、Redis、MongoDB、Neo4j等。
Spring Batch：批處理框架，或說是批量任務(wù)執(zhí)行管理器，功能包括任務(wù)調(diào)度、日志記錄/跟蹤等。
Spring Security：是一個能夠為基于Spring的企業(yè)應(yīng)用系統(tǒng)提供聲明式的安全訪問控制解決方案的安全框架。
Spring Integration：面向企業(yè)應(yīng)用集成（EAI/ESB）的編程框架，支持的通信方式包括HTTP、FTP、TCP/UDP、JMS、RabbitMQ、Email等。
Spring Social：一組工具包，一組連接社交服務(wù)API，如Twitter、Facebook、LinkedIn、GitHub等，有幾十個。
Spring AMQP：消息隊列操作的工具包，主要是封裝了RabbitMQ的操作。
Spring HATEOAS：是一個用于支持實現(xiàn)超文本驅(qū)動的 REST Web 服務(wù)的開發(fā)庫。
Spring Mobile：是Spring MVC的擴展，用來簡化手機上的Web應(yīng)用開發(fā)。
Spring for Android：是Spring框架的一個擴展，其主要目的在乎簡化Android本地應(yīng)用的開發(fā)，提供RestTemplate來訪問Rest服務(wù)。
Spring Web Flow：目標是成為管理Web應(yīng)用頁面流程的最佳方案，將頁面跳轉(zhuǎn)流程單獨管理，并可配置。
Spring LDAP：是一個用于操作LDAP的Java工具包，基于Spring的JdbcTemplate模式，簡化LDAP訪問。
Spring Session：session管理的開發(fā)工具包，讓你可以把session保存到redis等，進行集群化session管理。
Spring Web Services：是基于Spring的Web服務(wù)框架，提供SOAP服務(wù)開發(fā)，允許通過多種方式創(chuàng)建Web服務(wù)。
Spring Shell：提供交互式的Shell可讓你使用簡單的基于Spring的編程模型來開發(fā)命令，比如Spring Roo命令。
Spring Roo：是一種Spring開發(fā)的輔助工具，使用命令行操作來生成自動化項目，操作非常類似于Rails。
Spring Scala：為Scala語言編程提供的spring框架的封裝（新的編程語言，Java平臺的Scala于2003年底/2004年初發(fā)布）。
Spring BlazeDS Integration：一個開發(fā)RIA工具包，可以集成Adobe Flex、BlazeDS、Spring以及Java技術(shù)創(chuàng)建RIA。
Spring Loaded：用于實現(xiàn)java程序和web應(yīng)用的熱部署的開源工具。
Spring REST Shell：可以調(diào)用Rest服務(wù)的命令行工具，敲命令行操作Rest服務(wù)。
?
Spring cloud子項目
目前來說spring主要集中于spring boot（用于開發(fā)微服務(wù)）和spring cloud相關(guān)框架的開發(fā)，我們從幾張圖著手理解，然后再具體介紹：
spring cloud子項目包括：
Spring Cloud Config：配置管理開發(fā)工具包，可以讓你把配置放到遠程服務(wù)器，目前支持本地存儲、Git以及Subversion。
?
Spring Cloud Bus：事件、消息總線，用于在集群（例如，配置變化事件）中傳播狀態(tài)變化，可與Spring Cloud Config聯(lián)合實現(xiàn)熱部署。
Spring Cloud Netflix：針對多種Netflix組件提供的開發(fā)工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。
Netflix Eureka：云端負載均衡，一個基于 REST 的服務(wù)，用于定位服務(wù)，以實現(xiàn)云端的負載均衡和中間層服務(wù)器的故障轉(zhuǎn)移。
Netflix Hystrix：容錯管理工具，旨在通過控制服務(wù)和第三方庫的節(jié)點,從而對延遲和故障提供更強大的容錯能力。
Netflix Zuul：邊緣服務(wù)工具，是提供動態(tài)路由，監(jiān)控，彈性，安全等的邊緣服務(wù)。
Netflix Archaius：配置管理API，包含一系列配置管理API，提供動態(tài)類型化屬性、線程安全配置操作、輪詢框架、回調(diào)機制等功能。
Spring Cloud for Cloud Foundry：通過Oauth2協(xié)議綁定服務(wù)到CloudFoundry，CloudFoundry是VMware推出的開源PaaS云平臺。
Spring Cloud Sleuth：日志收集工具包，封裝了Dapper,Zipkin和HTrace操作。
Spring Cloud Data Flow：大數(shù)據(jù)操作工具，通過命令行方式操作數(shù)據(jù)流。
Spring Cloud Security：安全工具包，為你的應(yīng)用程序添加安全控制，主要是指OAuth2。
Spring Cloud Consul：封裝了Consul操作，consul是一個服務(wù)發(fā)現(xiàn)與配置工具，與Docker容器可以無縫集成。
Spring Cloud Zookeeper：操作Zookeeper的工具包，用于使用zookeeper方式的服務(wù)注冊和發(fā)現(xiàn)。
Spring Cloud Stream：數(shù)據(jù)流操作開發(fā)包，封裝了與Redis,Rabbit、Kafka等發(fā)送接收消息。
Spring Cloud CLI：基于 Spring Boot CLI，可以讓你以命令行方式快速建立云組件。
【參考詳解】為什么選擇Spring Boot作為微服務(wù)的入門級微框架-CSDN.NET http://www.csdn.net/article/a/2016-05-12/15838098
?
?
WHAT - 什么是微服務(wù)
微服務(wù)簡介
?
這次參加JavaOne2015最大的困難就是聽Microservice相關(guān)的session，無論內(nèi)容多么水，只要題目帶microservice，必定報不上名，可見Microservice有多火。最喜歡其中一頁。關(guān)于這個典故，可以參考this，此圖適用于一切高大上的名字——技術(shù)有SOA，Agile，CLOUD，DevOps等等，古代有道，氣，八卦等等。此類名詞的最大特點就是?一解釋就懂，一問就不知，一討論就打架。?
微服務(wù)的流行，Martin功不可沒，這老頭也是個奇人，特別擅長抽象歸納和制造概念，我覺的這就是最牛逼的markting啊，感覺這也是目前國人欠缺的能力。
Martin Fowler是國際著名的OO專家，敏捷開發(fā)方法的創(chuàng)始人之一，現(xiàn)為ThoughtWorks公司的首席科學家.福勒（Martin Fowler），在面向?qū)ο蠓治鲈O(shè)計、UML、模式、軟件開發(fā)方法學、XP、重構(gòu)等方面，都是世界頂級的專家，現(xiàn)為Thought Works公司的首席科學家。Thought Works是一家從事企業(yè)應(yīng)用開發(fā)和集成的公司。早在20世紀80年代，Fowler就是使用對象技術(shù)構(gòu)建多層企業(yè)應(yīng)用的倡導(dǎo)者，他著有幾本經(jīng)典書籍： 《企業(yè)應(yīng)用架構(gòu)模式》、《UML精粹》和《重構(gòu)》等?！?百度百科
先來看看傳統(tǒng)的web開發(fā)方式，通過對比比較容易理解什么是Microservice Architecture。和Microservice相對應(yīng)的，這種方式一般被稱為Monolithic（比較難傳神的翻譯）。所有的功能打包在一個 WAR包里，基本沒有外部依賴（除了容器），部署在一個JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有邏輯。
Monolithic比較適合小項目，優(yōu)點是：
-
開發(fā)簡單直接，集中式管理
-
基本不會重復(fù)開發(fā)
-
功能都在本地，沒有分布式的管理開銷和調(diào)用開銷
它的缺點也非常明顯，特別對于互聯(lián)網(wǎng)公司來說（不一一列舉了）：
-
開發(fā)效率低：所有的開發(fā)在一個項目改代碼，遞交代碼相互等待，代碼沖突不斷
-
代碼維護難：代碼功能耦合在一起，新人不知道何從下手
-
部署不靈活：構(gòu)建時間長，任何小修改必須重新構(gòu)建整個項目，這個過程往往很長
-
穩(wěn)定性不高：一個微不足道的小問題，可以導(dǎo)致整個應(yīng)用掛掉
-
擴展性不夠：無法滿足高并發(fā)情況下的業(yè)務(wù)需求
所以，現(xiàn)在主流的設(shè)計一般會采用Microservice Architecture，就是基于微服務(wù)的架構(gòu)。簡單來說，?微服務(wù)的目的是有效的拆分應(yīng)用，實現(xiàn)敏捷開發(fā)和部署?。
用《The art of scalability》一書里提到的scale cube比較容易理解如何拆分。你看，我們叫分庫分表，別人總結(jié)成了scale cube，這就是抽象的能力啊，把復(fù)雜的東西用最簡單的概念解釋和總結(jié)。X軸代表運行多個負載均衡器之后運行的實例，Y軸代表將應(yīng)用進一步分解為微服務(wù) （分庫），數(shù)據(jù)量大時，還可以用Z軸將服務(wù)按數(shù)據(jù)分區(qū)（分表）
微服務(wù)的具體特征
先看看最官方的定義吧
The microservice architectural style is an approach to developing a single application as?a?suite of small services, each?running in its own process?and communicating with lightweight mechanisms, often an HTTP resource API. These services are?**built around business capabilities**?and independently deployable?by fully automated deployment machinery. There is?a?bare minimum of centralized management?of these services?, which may be written in different programming languages and use different data storage technologies.
-- James Lewis and Martin Fowler
把Martin老頭的定義大概的翻譯一下就是下面幾條，這個定義還是太抽象是不是，那就對了，就是要務(wù)虛，都說明白了誰還找他付費咨詢啊，這么貴。
1. 一些列的獨立的服務(wù)共同組成系統(tǒng)
2. 單獨部署，跑在自己的進程里
3. 每個服務(wù)為獨立的業(yè)務(wù)開發(fā)
4. 分布式的管理
Martin自己也說了，每個人對微服務(wù)都可以有自己的理解，不過大概的標準還是有一些的。
-
分布式服務(wù)組成的系統(tǒng)
-
按照業(yè)務(wù)而不是技術(shù)來劃分組織
-
做有生命的產(chǎn)品而不是項目
-
Smart endpoints and dumb pipes（我的理解是強服務(wù)個體和弱通信）
-
自動化運維（DevOps）
-
容錯
-
快速演化
SOA vs Microservice
除了Smart endpoints and dumb pipes都很容易理解對嗎？相信很多人都會問一個問題，這是不是就是SOA換了個概念，掛羊頭賣狗肉啊，有說法把Microservice叫成 Lightway SOA。也有很多傳統(tǒng)磚家跳出來說Microservice就是SOA。其實Martin也沒否認SOA和Microservice的關(guān)系。
我個人理解，Microservice是SOA的傳承，但一個最本質(zhì)的區(qū)別就在于Smart endpoints and dumb pipes，或者說是真正的分布式的、去中心化的。Smart endpoints and dumb pipes本質(zhì)就是去ESB，把所有的“思考”邏輯包括路由、消息解析等放在服務(wù)內(nèi)部（Smart endpoints），去掉一個大一統(tǒng)的ESB，服務(wù)間輕（dumb pipes）通信，是比SOA更徹底的拆分。
HOW - 怎么具體實踐微服務(wù)
聽上去好像都不錯，具體怎么落地啊？這需要回答下面幾個問題：
-
客戶端如何訪問這些服務(wù)？
-
服務(wù)之間如何通信？
-
這么多服務(wù)，怎么找?
-
服務(wù)掛了怎么辦？
客戶端如何訪問這些服務(wù)？
原來的Monolithic方式開發(fā)，所有的服務(wù)都是本地的，UI可以直接調(diào)用，現(xiàn)在按功能拆分成獨立的服務(wù)，跑在獨立的一般都在獨立的虛擬機上的 Java進程了?？蛻舳薝I如何訪問他的？后臺有N個服務(wù)，前臺就需要記住管理N個服務(wù)，一個服務(wù)下線/更新/升級，前臺就要重新部署，這明顯不服務(wù)我們 拆分的理念，特別當前臺是移動應(yīng)用的時候，通常業(yè)務(wù)變化的節(jié)奏更快。另外，N個小服務(wù)的調(diào)用也是一個不小的網(wǎng)絡(luò)開銷。還有一般微服務(wù)在系統(tǒng)內(nèi)部，通常是無 狀態(tài)的，用戶登錄信息和權(quán)限管理最好有一個統(tǒng)一的地方維護管理（OAuth）。
所以，一般在后臺N個服務(wù)和UI之間一般會一個代理或者叫API Gateway，他的作用包括
-
提供統(tǒng)一服務(wù)入口，讓微服務(wù)對前臺透明
-
聚合后臺的服務(wù)，節(jié)省流量，提升性能
-
提供安全，過濾，流控等API管理功能
我的理解其實這個API Gateway可以有很多廣義的實現(xiàn)辦法，可以是一個軟硬一體的盒子，也可以是一個簡單的MVC框架，甚至是一個Node.js的服務(wù)端。他們最重要的作 用是為前臺（通常是移動應(yīng)用）提供后臺服務(wù)的聚合，提供一個統(tǒng)一的服務(wù)出口，解除他們之間的耦合，不過API Gateway也有可能成為單點故障點或者性能的瓶頸。
一般用過Taobao Open Platform的就能很容易的體會，TAO就是這個API Gateway。
服務(wù)之間如何通信？
因為所有的微服務(wù)都是獨立的Java進程跑在獨立的虛擬機上，所以服務(wù)間的通行就是IPC（inter process communication），已經(jīng)有很多成熟的方案。現(xiàn)在基本最通用的有兩種方式。這幾種方式，展開來講都可以寫本書，而且大家一般都比較熟悉細節(jié)了， 就不展開講了。
-
同步調(diào)用
-
REST（JAX-RS，Spring Boot）
-
RPC（Thrift, Dubbo）
-
-
異步消息調(diào)用(Kafka, Notify, MetaQ)
一般同步調(diào)用比較簡單，一致性強，但是容易出調(diào)用問題，性能體驗上也會差些，特別是調(diào)用層次多的時候。RESTful和RPC的比較也是一個很有意 思的話題。一般REST基于HTTP，更容易實現(xiàn)，更容易被接受，服務(wù)端實現(xiàn)技術(shù)也更靈活些，各個語言都能支持，同時能跨客戶端，對客戶端沒有特殊的要 求，只要封裝了HTTP的SDK就能調(diào)用，所以相對使用的廣一些。RPC也有自己的優(yōu)點，傳輸協(xié)議更高效，安全更可控，特別在一個公司內(nèi)部，如果有統(tǒng)一個 的開發(fā)規(guī)范和統(tǒng)一的服務(wù)框架時，他的開發(fā)效率優(yōu)勢更明顯些。就看各自的技術(shù)積累實際條件，自己的選擇了。
而異步消息的方式在分布式系統(tǒng)中有特別廣泛的應(yīng)用，他既能減低調(diào)用服務(wù)之間的耦合，又能成為調(diào)用之間的緩沖，確保消息積壓不會沖垮被調(diào)用方，同時能 保證調(diào)用方的服務(wù)體驗，繼續(xù)干自己該干的活，不至于被后臺性能拖慢。不過需要付出的代價是一致性的減弱，需要接受數(shù)據(jù)最終一致性；還有就是后臺服務(wù)一般要 實現(xiàn)冪等性，因為消息發(fā)送出于性能的考慮一般會有重復(fù)（保證消息的被收到且僅收到一次對性能是很大的考驗）；最后就是必須引入一個獨立的broker，如 果公司內(nèi)部沒有技術(shù)積累，對broker分布式管理也是一個很大的挑戰(zhàn)。
這么多服務(wù)，怎么找?
在微服務(wù)架構(gòu)中，一般每一個服務(wù)都是有多個拷貝，來做負載均衡。一個服務(wù)隨時可能下線，也可能應(yīng)對臨時訪問壓力增加新的服務(wù)節(jié)點。服務(wù)之間如何相互 感知？服務(wù)如何管理？這就是服務(wù)發(fā)現(xiàn)的問題了。一般有兩類做法，也各有優(yōu)缺點?；径际峭ㄟ^zookeeper等類似技術(shù)做服務(wù)注冊信息的分布式管理。當 服務(wù)上線時，服務(wù)提供者將自己的服務(wù)信息注冊到ZK（或類似框架），并通過心跳維持長鏈接，實時更新鏈接信息。服務(wù)調(diào)用者通過ZK尋址，根據(jù)可定制算法， 找到一個服務(wù)，還可以將服務(wù)信息緩存在本地以提高性能。當服務(wù)下線時，ZK會發(fā)通知給服務(wù)客戶端。
-
客戶端做：優(yōu)點是架構(gòu)簡單，擴展靈活，只對服務(wù)注冊器依賴。缺點是客戶端要維護所有調(diào)用服務(wù)的地址，有技術(shù)難度，一般大公司都有成熟的內(nèi)部框架支持，比如Dubbo。
-
服務(wù)端做：優(yōu)點是簡單，所有服務(wù)對于前臺調(diào)用方透明，一般在小公司在云服務(wù)上部署的應(yīng)用采用的比較多。
這么多服務(wù)，服務(wù)掛了怎么辦？
前面提到，Monolithic方式開發(fā)一個很大的風險是，把所有雞蛋放在一個籃子里，一榮俱榮，一損俱損。而分布式最大的特性就是網(wǎng)絡(luò)是不可靠 的。通過微服務(wù)拆分能降低這個風險，不過如果沒有特別的保障，結(jié)局肯定是噩夢。我們剛遇到一個線上故障就是一個很不起眼的SQL計數(shù)功能，在訪問量上升 時，導(dǎo)致數(shù)據(jù)庫load彪高，影響了所在應(yīng)用的性能，從而影響所有調(diào)用這個應(yīng)用服務(wù)的前臺應(yīng)用。所以當我們的系統(tǒng)是由一系列的服務(wù)調(diào)用鏈組成的時候，我們 必須確保任一環(huán)節(jié)出問題都不至于影響整體鏈路。相應(yīng)的手段有很多：
-
重試機制
-
限流
-
熔斷機制
-
負載均衡
-
降級（本地緩存）
這些方法基本上都很明確通用，就不詳細說明了。比如Netflix的Hystrix：https://github.com/Netflix/Hystrix
WHY - 微服務(wù)的應(yīng)用
這里有一個圖非常好的總結(jié)微服務(wù)架構(gòu)需要考慮的問題，包括
-
API Gateway
-
服務(wù)間調(diào)用
-
服務(wù)發(fā)現(xiàn)
-
服務(wù)容錯
-
服務(wù)部署
-
數(shù)據(jù)調(diào)用
微服務(wù)的優(yōu)點和缺點（或者說挑戰(zhàn)）一樣明顯。
-
優(yōu)點
-
開發(fā)簡單
-
技術(shù)棧靈活
-
服務(wù)獨立無依賴
-
獨立按需擴展
-
可用性高
-
-
缺點（挑戰(zhàn)）
-
多服務(wù)運維難度
-
系統(tǒng)部署依賴
-
服務(wù)間通信成本
-
數(shù)據(jù)一致性
-
系統(tǒng)集成測試
-
重復(fù)工作
-
性能監(jiān)控
-
沒有最好的，只有適合自己的。
-
對于大的互聯(lián)網(wǎng)公司，微服務(wù)架構(gòu)是血液，是習慣，每家公司都有自己的套路和架構(gòu)，細節(jié)有不同，但是核心理念是通的。
-
對于一般的公司而言，實踐微服務(wù)有非常大的技術(shù)挑戰(zhàn)，于是乎才有了這么多IT供應(yīng)商考慮這里的商機。微服務(wù)比較適合未來有一定的擴展復(fù)雜度，且有 很大用戶增量預(yù)期的應(yīng)用，說人話就是新興的互聯(lián)網(wǎng)公司。創(chuàng)業(yè)初期，不可能買大量的機器或者很貴的機器，但是又必須考慮應(yīng)對成功后的巨量的用戶，微服務(wù)架構(gòu) 成了最好的選擇。?
So What - 思考
看到上面的圖，不是不覺得特別的熟悉？其實我們N年前就用的滾瓜爛熟了好不好？褲子都拖了，你就給我看這個？
from:?https://github.com/Netflix/recipes-rss/wiki/Architecture
其實本來所謂的微服務(wù)就是對互聯(lián)網(wǎng)在應(yīng)用技術(shù)的一個總結(jié)歸納，IT廠商鼓吹所有概念無非是為了生意（business），SOA是，Cloud是，Microservice也是。下面玩笑很有意思的概括了這個情況（我加了第一條線，原圖見這里）
所以微服對我們的思考我覺得更多的是思維上的，對已微服務(wù)架構(gòu)，?技術(shù)上不是問題，意識比工具重要。
-
按照業(yè)務(wù) 或者客戶需求組織資源（這是最難的）
-
做有生命的產(chǎn)品，而不是項目
-
頭狼戰(zhàn)隊，全?；?/p>
-
后臺服務(wù)貫徹Single Responsibility Principle
-
VM->Docker （to PE）
-
DevOps (to PE)
同時，對于開發(fā)同學，有這么多的中間件和強大的PE支持固然是好事，我們也需要深入去了解這些中間件背后的原理，知其然知其所以然，設(shè)想下，如果我們是一個小公司的CTO，離開的阿里的大環(huán)境，在有限的技術(shù)資源如何通過開源技術(shù)實施微服務(wù)？
最后，一般提到微服務(wù)都離不開DevOps和Docker，理解微服務(wù)架構(gòu)是核心，devops和docker是工具，是手段。下次在抽時間再學習整理下。
參考資料和推薦閱讀
-
http://www.infoq.com/articles/microservices-intro
-
http://martinfowler.com/articles/microservices.html
-
http://martinfowler.com/microservices/
-
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
-
https://www.nginx.com/blog/introduction-to-microservices/
-
http://microservices.io/patterns/microservices.html
-
http://www.infoq.com/presentations/migration-cloud-native
-
https://github.com/Netflix/recipes-rss
-
http://www.mattstine.com/microservices
構(gòu)建微服務(wù)：Spring boot 提高篇 - 純潔的微笑 - 博客園 http://www.cnblogs.com/ityouknow/p/5730412.html
---------------------
作者：天府云創(chuàng)
來源：CSDN
原文：https://blog.csdn.net/enweitech/article/details/52582918
版權(quán)聲明：本文為作者原創(chuàng)文章，轉(zhuǎn)載請附上博文鏈接！
總結(jié)
以上是生活随笔為你收集整理的基于Spring Boot和Spring Cloud实现微服务架构学习的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 原生js声音播放代码
- 下一篇： 利用JS脚本快速删除百度网盘同一目录下的