摘要：每個微服務(wù)提供一組，供其他微服務(wù)或者應(yīng)用客戶端所用。由于微服務(wù)架構(gòu)的分布式特點(diǎn)，測試一個基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)。微服務(wù)架構(gòu)模式下，應(yīng)用的改變將會波及多個服務(wù)。

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

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

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

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


小結(jié)：微服務(wù)是基于Restful風(fēng)格的，基于資源及資源操作一組API的集合，可以實(shí)現(xiàn)模塊兒或者說是特定的業(yè)務(wù)范圍內(nèi)的一個完全獨(dú)立、細(xì)粒度、自包含的一個服務(wù)。每個微服務(wù)提供一組API，供其他微服務(wù)或者應(yīng)用客戶端所用。

既然提到微服務(wù)架構(gòu)，那么單體應(yīng)用架構(gòu)以及SOA架構(gòu)也必須拿出來聊聊。

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

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

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

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

微服務(wù)架構(gòu)是的每個服務(wù)可以由專門的開發(fā)團(tuán)隊或者個人開發(fā)者進(jìn)行開發(fā)，開發(fā)者可以自由選擇技術(shù)，不必受制于規(guī)定的技術(shù)和框架，只要API服務(wù)協(xié)議好交互方式即可（如restful）。這樣即使重新技術(shù)過時的微服務(wù)模塊兒或者重寫以前的代碼，也不是很困難。

微服務(wù)架構(gòu)模式使得每個微服務(wù)獨(dú)立部署，且每個服務(wù)獨(dú)立擴(kuò)展，開發(fā)者不再需要協(xié)調(diào)其它服務(wù)部署對本服務(wù)的影響。微服務(wù)架構(gòu)模式使得持續(xù)化部署成為可能。

"微服務(wù)"強(qiáng)調(diào)了服務(wù)大小，所以很多人的關(guān)注點(diǎn)主要在“微”字上，盡管小服務(wù)更容易被采用，但是微服務(wù)只是結(jié)果，而不是最終目的。微服務(wù)的目的是有效拆分應(yīng)用，實(shí)現(xiàn)敏捷開發(fā)和部署。

微服務(wù)應(yīng)用是分布式系統(tǒng)，必然會帶來固有的復(fù)雜性，開發(fā)者需要協(xié)議消息傳遞規(guī)則的選擇并完成進(jìn)程間通訊。相對于單體應(yīng)用，微服務(wù)下這種技術(shù)顯得更加復(fù)雜一些。

關(guān)于微服務(wù)的數(shù)據(jù)庫架構(gòu)，由于同一事務(wù)更新多個業(yè)務(wù)很普遍，這種事務(wù)操作對于單體應(yīng)用來說很容易解決，因?yàn)橹挥幸粋€數(shù)據(jù)庫，而在微服務(wù)架構(gòu)中，由于每個微服務(wù)使用不同的數(shù)據(jù)庫，使用分布式事務(wù)并不一定是好的選擇。并且現(xiàn)在高擴(kuò)展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這樣的需求。從而對開發(fā)者提出了更高的要求和挑戰(zhàn)。

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

微服務(wù)架構(gòu)模式下，應(yīng)用的改變將會波及多個服務(wù)。比如，假設(shè)你在完成一個需求，需要修改服務(wù)A、B、C，而A依賴B，B依賴C。在單體應(yīng)用中，你只需要改變相關(guān)模塊，整合變化，部署就好了。對比之下，微服務(wù)架構(gòu)模式就需要考慮相關(guān)改變對不同服務(wù)的影響。比如，你需要更新服務(wù)C，然后是B，最后才是A。幸運(yùn)的是，許多改變一般只影響一個服務(wù)，而需要協(xié)調(diào)多服務(wù)的改變很少。

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

根據(jù)上一點(diǎn)的描述，在微服務(wù)架構(gòu)的應(yīng)用中，往往有很多個微服務(wù)實(shí)例，并且每個服務(wù)都有多個實(shí)例，那么服務(wù)的自動化部署必然與服務(wù)發(fā)現(xiàn)機(jī)制同樣要解決。

微服務(wù)實(shí)戰(zhàn)：從架構(gòu)到部署

創(chuàng)建微服務(wù)？請先回答這10個問題

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