摘要：每個微服務提供一組，供其他微服務或者應用客戶端所用。由于微服務架構的分布式特點，測試一個基于微服務架構的應用也是很復雜的任務。微服務架構模式下，應用的改變將會波及多個服務。

微服務“Microservices”已經成為軟件架構最流行的熱詞之一。網絡上看到很多關于微服務的文章，但是感覺很多離我們還很遙遠，并且沒有找到多少真正在企業場景中應用的實例。此處省略一萬字~~~~于是想要將自己最近一段時間使用微服務以及通過看大師們的文章的所思所想梳理出來，分享出來，以供大家參考（熱切歡迎大家拍磚，頭破血流最好）。

記得剛看到微服務的時候，注意點在微字上，然后才是服務，初步理解為：將整塊兒的服務拆分成多個類似工具類的微小web服務，供其他服務調用，每個服務應該是極其微小的，就像各個零件一樣，各司其職，拼裝成一個偉大的服務群

由于自己是技術出身，對理論并不是很重視，于是基于初期的理解，就向著“微服務”（這里要打引號，不然會被拍板磚）邁進。先是實現了微服務的多種搭建方式，聽說有springboot的、有jersey+jetty的、有Python的、有NodeJS的等等。進而了解到，微服務主要是以restful風格架構以提供服務（還有Thrift），rest的實現是HTTP的“請求-響應”，而rest是基于資源的API風格，進而可以理解微服務是多個能夠表現對一個資源及對此資源執行的操作集成的服務。既然是對一個資源的使用及操作，那么每個微服務應該是獨立的個體。

基于以上理解，迫不及待的使用“微服務”來實現自己手上的業務需求，就拿簡單的客戶信息管理系統為例：主要有客戶信息管理、用戶管理、組織架構管理等（這里不多舉例）。根據之前的理解，客戶、用戶、組織架構，應該是三種不同的資源，那么應該分為三個不同的微服務?？墒悄骋粚咏M織架構下，會有多個用戶，而某個用戶又會擁有屬于自己的多個客戶，如此并沒有辦法將三個服務徹底分離（還是有關聯關系），這不符合之前的理解。然而業務關系上，三者的聯系必不可少，存在即合理，那么也理應是三個微服務互相協作而又相互獨立的關系。如同團隊成員之間的協作關系，相互獨立而又相互依賴。


小結：微服務是基于Restful風格的，基于資源及資源操作一組API的集合，可以實現模塊兒或者說是特定的業務范圍內的一個完全獨立、細粒度、自包含的一個服務。每個微服務提供一組API，供其他微服務或者應用客戶端所用。

既然提到微服務架構，那么單體應用架構以及SOA架構也必須拿出來聊聊。

說到單體應用，直接舉例來說吧，典型的單體應用有ERP、CRM、BPM等軟件。對于ERP和大型的CRM應用來說，可能一個軟件就包含有數百個功能點。對于此類軟件的開發、維護、部署、糾錯、擴展及升級對于相關人員來說都將是大麻煩（噩夢）。

SOA是解決單體應用架構的問題的一個解決方案：SOA是面向服務的體系架構，是一個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。既然每個服務是有不同的功能單元組成，那么這個服務的范圍就非常廣了。
SOA架構與微服務架構比較相似，以至于國外不少人范圍微服務的原因是認為微服務只是對SOA的二次包裝。這里不去討論SOA與微服務的長短，這個要討論估計要三天三夜了吧~~~

表面上看，微服務架構范式與 SOA 非常類似，這兩種架構都包括一套服務。然而，微服務架構范式被看作不包含某些功能的 SOA 。這些功能包括網絡服務說明（ WS- ）和 Enterprise Service Bus (ESB) 的商品化和請求包。基于微服務的應用更青睞 REST 這樣簡單的、輕量級的協議，而不是 WS- 。他們也極力避免在微服務中使用 ESBs 及類似功能。微服務架構范式也拒絕 SOA 的其它部分，比如 canonical schema 的概念（摘自“Chris Richardson 微服務系列”）。

可以解決復雜性的問題，在功能不變的情況下，分解為多個相互協作的微服務，通過rest API定義邊界，這樣極大易于開發、理解和維護。

微服務架構是的每個服務可以由專門的開發團隊或者個人開發者進行開發，開發者可以自由選擇技術，不必受制于規定的技術和框架，只要API服務協議好交互方式即可（如restful）。這樣即使重新技術過時的微服務模塊兒或者重寫以前的代碼，也不是很困難。

微服務架構模式使得每個微服務獨立部署，且每個服務獨立擴展，開發者不再需要協調其它服務部署對本服務的影響。微服務架構模式使得持續化部署成為可能。

"微服務"強調了服務大小，所以很多人的關注點主要在“微”字上，盡管小服務更容易被采用，但是微服務只是結果，而不是最終目的。微服務的目的是有效拆分應用，實現敏捷開發和部署。

微服務應用是分布式系統，必然會帶來固有的復雜性，開發者需要協議消息傳遞規則的選擇并完成進程間通訊。相對于單體應用，微服務下這種技術顯得更加復雜一些。

關于微服務的數據庫架構，由于同一事務更新多個業務很普遍，這種事務操作對于單體應用來說很容易解決，因為只有一個數據庫，而在微服務架構中，由于每個微服務使用不同的數據庫，使用分布式事務并不一定是好的選擇。并且現在高擴展性的NoSQL數據庫和消息傳遞中間件并不支持這樣的需求。從而對開發者提出了更高的要求和挑戰。

由于微服務架構的分布式特點，測試一個基于微服務架構的應用也是很復雜的任務。測試單個微服務的一套REST API 相對簡單，但是往往要啟動與之相關的所有服務。所以，采用了微服務架構帶來的并不僅僅是敏捷開發和部署，還會帶來一定的復雜性。

微服務架構模式下，應用的改變將會波及多個服務。比如，假設你在完成一個需求，需要修改服務A、B、C，而A依賴B，B依賴C。在單體應用中，你只需要改變相關模塊，整合變化，部署就好了。對比之下，微服務架構模式就需要考慮相關改變對不同服務的影響。比如，你需要更新服務C，然后是B，最后才是A。幸運的是，許多改變一般只影響一個服務，而需要協調多服務的改變很少。

部署一個微服務應用也很復雜，一個單體應用只需要在復雜均衡器后面部署各自的服務器就好了。每個應用實例是需要配置諸如數據庫和消息中間件等基礎服務。相比之下，一個微服務應用一般由大批服務構成。根據 Adrian Cockcroft 的分享，Hailo 由 160 個不同服務構成，而NetFlix則超過600個服務。每個服務都有多個實例，這就形成大量需要配置、部署、擴展和監控的部分。除此之外，你還需要完成一個服務發現機制，以用來發現與它通訊服務的地址（包括服務器地址和端口）。傳統的解決問題辦法并不能解決這么復雜的問題。最終，成功部署一個微服務應用需要開發者有足夠的控制部署方法，并高度自動化。(摘自“Chris Richardson 微服務系列”)

根據上一點的描述，在微服務架構的應用中，往往有很多個微服務實例，并且每個服務都有多個實例，那么服務的自動化部署必然與服務發現機制同樣要解決。

微服務實戰：從架構到部署

創建微服務？請先回答這10個問題

by 劉迎光@螢火蟲工作室  
OpenBI交流群：495266201  
MicroService 微服務交流群：217722918    
mail: liuyg#liuyingguang.cn  
博主首頁（==防止爬蟲==）：http://blog.liuyingguang.cn  
OpenBI問答社區：http://www.openbi.tk