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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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