微服務“Microservices”已經(jīng)成為軟件架構(gòu)最流行的熱詞之一。網(wǎng)絡上看到很多關于微服務的文章，但是感覺很多離我們還很遙遠，并且沒有找到多少真正在企業(yè)場景中應用的實例。此處省略一萬字~~~~于是想要將自己最近一段時間使用微服務以及通過看大師們的文章的所思所想梳理出來，分享出來，以供大家參考（熱切歡迎大家拍磚，頭破血流最好）。
一、什么是微服務
記得剛看到微服務的時候，注意點在微字上，然后才是服務，初步理解為：將整塊兒的服務拆分成多個類似工具類的微小web服務，供其他服務調(diào)用，每個服務應該是極其微小的，就像各個零件一樣，各司其職，拼裝成一個偉大的服務群
由于自己是技術出身，對理論并不是很重視，于是基于初期的理解，就向著“微服務”（這里要打引號，不然會被拍板磚）邁進。先是實現(xiàn)了微服務的多種搭建方式，聽說有springboot的、有jersey+jetty的、有Python的、有NodeJS的等等。進而了解到，微服務主要是以restful風格架構(gòu)以提供服務（還有Thrift），rest的實現(xiàn)是HTTP的“請求-響應”，而rest是基于資源的API風格，進而可以理解微服務是多個能夠表現(xiàn)對一個資源及對此資源執(zhí)行的操作集成的服務。既然是對一個資源的使用及操作，那么每個微服務應該是獨立的個體。
基于以上理解，迫不及待的使用“微服務”來實現(xiàn)自己手上的業(yè)務需求，就拿簡單的客戶信息管理系統(tǒng)為例：主要有客戶信息管理、用戶管理、組織架構(gòu)管理等（這里不多舉例）。根據(jù)之前的理解，客戶、用戶、組織架構(gòu)，應該是三種不同的資源，那么應該分為三個不同的微服務?？墒悄骋粚咏M織架構(gòu)下，會有多個用戶，而某個用戶又會擁有屬于自己的多個客戶，如此并沒有辦法將三個服務徹底分離（還是有關聯(lián)關系），這不符合之前的理解。然而業(yè)務關系上，三者的聯(lián)系必不可少，存在即合理，那么也理應是三個微服務互相協(xié)作而又相互獨立的關系。如同團隊成員之間的協(xié)作關系，相互獨立而又相互依賴。
小結(jié)：微服務是基于Restful風格的，基于資源及資源操作一組API的集合，可以實現(xiàn)模塊兒或者說是特定的業(yè)務范圍內(nèi)的一個完全獨立、細粒度、自包含的一個服務。每個微服務提供一組API，供其他微服務或者應用客戶端所用。
二、什么是微服務架構(gòu)
既然提到微服務架構(gòu)，那么單體應用架構(gòu)以及SOA架構(gòu)也必須拿出來聊聊。
1. 什么是單體應用：
說到單體應用，直接舉例來說吧，典型的單體應用有ERP、CRM、BPM等軟件。對于ERP和大型的CRM應用來說，可能一個軟件就包含有數(shù)百個功能點。對于此類軟件的開發(fā)、維護、部署、糾錯、擴展及升級對于相關人員來說都將是大麻煩（噩夢）。
2. 什么是SOA架構(gòu)
SOA是解決單體應用架構(gòu)的問題的一個解決方案：SOA是面向服務的體系架構(gòu)，是一個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯(lián)系起來。既然每個服務是有不同的功能單元組成，那么這個服務的范圍就非常廣了。
SOA架構(gòu)與微服務架構(gòu)比較相似，以至于國外不少人范圍微服務的原因是認為微服務只是對SOA的二次包裝。這里不去討論SOA與微服務的長短，這個要討論估計要三天三夜了吧~~~
3. 什么是微服務架構(gòu)
表面上看，微服務架構(gòu)范式與 SOA 非常類似，這兩種架構(gòu)都包括一套服務。然而，微服務架構(gòu)范式被看作不包含某些功能的 SOA 。這些功能包括網(wǎng)絡服務說明（ WS-* ）和 Enterprise Service Bus (ESB) 的商品化和請求包?；谖⒎盏膽酶嗖A REST 這樣簡單的、輕量級的協(xié)議，而不是 WS-* 。他們也極力避免在微服務中使用 ESBs 及類似功能。微服務架構(gòu)范式也拒絕 SOA 的其它部分，比如 canonical schema 的概念（摘自“Chris Richardson 微服務系列”）。
三、微服務架構(gòu)的好處與不足
微服務架構(gòu)的好處
可以解決復雜性的問題，在功能不變的情況下，分解為多個相互協(xié)作的微服務，通過rest API定義邊界，這樣極大易于開發(fā)、理解和維護。
微服務架構(gòu)是的每個服務可以由專門的開發(fā)團隊或者個人開發(fā)者進行開發(fā)，開發(fā)者可以自由選擇技術，不必受制于規(guī)定的技術和框架，只要API服務協(xié)議好交互方式即可（如restful）。這樣即使重新技術過時的微服務模塊兒或者重寫以前的代碼，也不是很困難。
微服務架構(gòu)模式使得每個微服務獨立部署，且每個服務獨立擴展，開發(fā)者不再需要協(xié)調(diào)其它服務部署對本服務的影響。微服務架構(gòu)模式使得持續(xù)化部署成為可能。
微服務架構(gòu)的不足
"微服務"強調(diào)了服務大小，所以很多人的關注點主要在“微”字上，盡管小服務更容易被采用，但是微服務只是結(jié)果，而不是最終目的。微服務的目的是有效拆分應用，實現(xiàn)敏捷開發(fā)和部署。
微服務應用是分布式系統(tǒng)，必然會帶來固有的復雜性，開發(fā)者需要協(xié)議消息傳遞規(guī)則的選擇并完成進程間通訊。相對于單體應用，微服務下這種技術顯得更加復雜一些。
關于微服務的數(shù)據(jù)庫架構(gòu)，由于同一事務更新多個業(yè)務很普遍，這種事務操作對于單體應用來說很容易解決，因為只有一個數(shù)據(jù)庫，而在微服務架構(gòu)中，由于每個微服務使用不同的數(shù)據(jù)庫，使用分布式事務并不一定是好的選擇。并且現(xiàn)在高擴展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這樣的需求。從而對開發(fā)者提出了更高的要求和挑戰(zhàn)。
由于微服務架構(gòu)的分布式特點，測試一個基于微服務架構(gòu)的應用也是很復雜的任務。測試單個微服務的一套REST API 相對簡單，但是往往要啟動與之相關的所有服務。所以，采用了微服務架構(gòu)帶來的并不僅僅是敏捷開發(fā)和部署，還會帶來一定的復雜性。
微服務架構(gòu)模式下，應用的改變將會波及多個服務。比如，假設你在完成一個需求，需要修改服務A、B、C，而A依賴B，B依賴C。在單體應用中，你只需要改變相關模塊，整合變化，部署就好了。對比之下，微服務架構(gòu)模式就需要考慮相關改變對不同服務的影響。比如，你需要更新服務C，然后是B，最后才是A。幸運的是，許多改變一般只影響一個服務，而需要協(xié)調(diào)多服務的改變很少。
部署一個微服務應用也很復雜，一個單體應用只需要在復雜均衡器后面部署各自的服務器就好了。每個應用實例是需要配置諸如數(shù)據(jù)庫和消息中間件等基礎服務。相比之下，一個微服務應用一般由大批服務構(gòu)成。根據(jù) Adrian Cockcroft 的分享，Hailo 由 160 個不同服務構(gòu)成，而NetFlix則超過600個服務。每個服務都有多個實例，這就形成大量需要配置、部署、擴展和監(jiān)控的部分。除此之外，你還需要完成一個服務發(fā)現(xiàn)機制，以用來發(fā)現(xiàn)與它通訊服務的地址（包括服務器地址和端口）。傳統(tǒng)的解決問題辦法并不能解決這么復雜的問題。最終，成功部署一個微服務應用需要開發(fā)者有足夠的控制部署方法，并高度自動化。(摘自“Chris Richardson 微服務系列”)
根據(jù)上一點的描述，在微服務架構(gòu)的應用中，往往有很多個微服務實例，并且每個服務都有多個實例，那么服務的自動化部署必然與服務發(fā)現(xiàn)機制同樣要解決。
參考文章
by 劉迎光@螢火蟲工作室
OpenBI交流群：495266201
MicroService 微服務交流群：217722918
mail: liuyg#liuyingguang.cn
博主首頁（==防止爬蟲==）：http://blog.liuyingguang.cn
