微服務“Microservices”已經成為軟體架構最流行的熱詞之一。網路上看到很多關於微服務的文章，但是感覺很多離我們還很遙遠，並且沒有找到多少真正在企業場景中應用的例項。此處省略一萬字~~~~於是想要將自己最近一段時間使用微服務以及通過看大師們的文章的所思所想梳理出來，分享出來，以供大家參考（熱切歡迎大家拍磚，頭破血流最好）。
一、什麼是微服務
記得剛看到微服務的時候，注意點在微字上，然後才是服務，初步理解為：將整塊兒的服務拆分成多個類似工具類的微小web服務，供其他服務呼叫，每個服務應該是極其微小的，就像各個零件一樣，各司其職，拼裝成一個偉大的服務群
由於自己是技術出身，對理論並不是很重視，於是基於初期的理解，就向著“微服務”（這裡要打引號，不然會被拍板磚）邁進。先是實現了微服務的多種搭建方式，聽說有springboot的、有jersey+jetty的、有Python的、有NodeJS的等等。進而瞭解到，微服務主要是以restful風格架構以提供服務（還有Thrift），rest的實現是HTTP的“請求-響應”，而rest是基於資源的API風格，進而可以理解微服務是多個能夠表現對一個資源及對此資源執行的操作整合的服務。既然是對一個資源的使用及操作，那麼每個微服務應該是獨立的個體。
基於以上理解，迫不及待的使用“微服務”來實現自己手上的業務需求，就拿簡單的客戶資訊管理系統為例：主要有客戶資訊管理、使用者管理、組織架構管理等（這裡不多舉例）。根據之前的理解，客戶、使用者、組織架構，應該是三種不同的資源，那麼應該分為三個不同的微服務。可是某一層組織架構下，會有多個使用者，而某個使用者又會擁有屬於自己的多個客戶，如此並沒有辦法將三個服務徹底分離（還是有關聯關係），這不符合之前的理解。然而業務關係上，三者的聯絡必不可少，存在即合理，那麼也理應是三個微服務互相協作而又相互獨立的關係。如同團隊成員之間的協作關係，相互獨立而又相互依賴。
小結：微服務是基於Restful風格的，基於資源及資源操作一組API的集合，可以實現模組兒或者說是特定的業務範圍內的一個完全獨立、細粒度、自包含的一個服務。每個微服務提供一組API，供其他微服務或者應用客戶端所用。
二、什麼是微服務架構
既然提到微服務架構，那麼單體應用架構以及SOA架構也必須拿出來聊聊。
1. 什麼是單體應用：
說到單體應用，直接舉例來說吧，典型的單體應用有ERP、CRM、BPM等軟體。對於ERP和大型的CRM應用來說，可能一個軟體就包含有數百個功能點。對於此類軟體的開發、維護、部署、糾錯、擴充套件及升級對於相關人員來說都將是大麻煩（噩夢）。
2. 什麼是SOA架構
SOA是解決單體應用架構的問題的一個解決方案：SOA是面向服務的體系架構，是一個元件模型，它將應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的介面和契約聯絡起來。既然每個服務是有不同的功能單元組成，那麼這個服務的範圍就非常廣了。
SOA架構與微服務架構比較相似，以至於國外不少人範圍微服務的原因是認為微服務只是對SOA的二次包裝。這裡不去討論SOA與微服務的長短，這個要討論估計要三天三夜了吧~~~
3. 什麼是微服務架構
表面上看，微服務架構正規化與 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 微服務系列”)
根據上一點的描述，在微服務架構的應用中，往往有很多個微服務例項，並且每個服務都有多個例項，那麼服務的自動化部署必然與服務發現機制同樣要解決。
參考文章
by 劉迎光@螢火蟲工作室
OpenBI交流群：495266201
MicroService 微服務交流群：217722918
mail: liuyg#liuyingguang.cn
博主首頁（==防止爬蟲==）：http://blog.liuyingguang.cn
OpenBI問答社群：http://www.openbi.tk