微服務指南走北（一）：微服務是什麼

微服務「Microservices」已經成爲軟件架構最流行的熱詞之一。網絡上看到不少關於微服務的文章，可是感受不少離咱們還很遙遠，而且沒有找到多少真正在企業場景中應用的實例。此處省略一萬字~~~~因而想要將本身最近一段時間使用微服務以及經過看大師們的文章的所思所想梳理出來，分享出來，以供你們參考（熱切歡迎你們拍磚，頭破血流最好）。

1、什麼是微服務

1. 記得剛看到微服務的時候，注意點在微字上，而後纔是服務，初步理解爲：將整塊兒的服務拆分紅多個相似工具類的微小web服務，供其餘服務調用，每一個服務應該是極其微小的，就像各個零件同樣，各司其職，拼裝成一個偉大的服務羣

2. 因爲本身是技術出身，對理論並非很重視，因而基於初期的理解，就向着「微服務」（這裏要打引號，否則會被拍板磚）邁進。先是實現了微服務的多種搭建方式，據說有springboot的、有jersey+jetty的、有Python的、有NodeJS的等等。進而瞭解到，微服務主要是以restful風格架構以提供服務（還有Thrift），rest的實現是HTTP的「請求-響應」，而rest是基於資源的API風格，進而能夠理解微服務是多個可以表現對一個資源及對此資源執行的操做集成的服務。既然是對一個資源的使用及操做，那麼每一個微服務應該是獨立的個體。

3. 基於以上理解，火燒眉毛的使用「微服務」來實現本身手上的業務需求，就拿簡單的客戶信息管理系統爲例：主要有客戶信息管理、用戶管理、組織架構管理等（這裏很少舉例）。根據以前的理解，客戶、用戶、組織架構，應該是三種不一樣的資源，那麼應該分爲三個不一樣的微服務。但是某一層組織架構下，會有多個用戶，而某個用戶又會擁有屬於本身的多個客戶，如此並無辦法將三個服務完全分離（仍是有關聯關係），這不符合以前的理解。然而業務關係上，三者的聯繫必不可少，存在即合理，那麼也理應是三個微服務互相協做而又相互獨立的關係。如同團隊成員之間的協做關係，相互獨立而又相互依賴。

小結：微服務是基於Restful風格的，基於資源及資源操做一組API的集合，能夠實現模塊兒或者說是特定的業務範圍內的一個徹底獨立、細粒度、自包含的一個服務。每一個微服務提供一組API，供其餘微服務或者應用客戶端所用。

---

2、什麼是微服務架構

既然提到微服務架構，那麼單體應用架構以及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 微服務系列」）。

---

3、微服務架構的好處與不足

微服務架構的好處

1. 能夠解決複雜性的問題，在功能不變的狀況下，分解爲多個相互協做的微服務，經過rest API定義邊界，這樣極大易於開發、理解和維護。

2. 微服務架構是的每一個服務能夠由專門的開發團隊或者我的開發者進行開發，開發者能夠自由選擇技術，沒必要受制於規定的技術和框架，只要API服務協議好交互方式便可（如restful）。這樣即便從新技術過期的微服務模塊兒或者重寫之前的代碼，也不是很困難。

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

微服務架構的不足

1. "微服務"強調了服務大小，因此不少人的關注點主要在「微」字上，儘管小服務更容易被採用，可是微服務只是結果，而不是最終目的。微服務的目的是有效拆分應用，實現敏捷開發和部署。

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

3. 關於微服務的數據庫架構，因爲同一事務更新多個業務很廣泛，這種事務操做對於單體應用來講很容易解決，由於只有一個數據庫，而在微服務架構中，因爲每一個微服務使用不一樣的數據庫，使用分佈式事務並不必定是好的選擇。而且如今高擴展性的NoSQL數據庫和消息傳遞中間件並不支持這樣的需求。從而對開發者提出了更高的要求和挑戰。

4. 因爲微服務架構的分佈式特色，測試一個基於微服務架構的應用也是很複雜的任務。測試單個微服務的一套REST API 相對簡單，可是每每要啓動與之相關的全部服務。因此，採用了微服務架構帶來的並不只僅是敏捷開發和部署，還會帶來必定的複雜性。

5. 微服務架構模式下，應用的改變將會波及多個服務。好比，假設你在完成一個需求，須要修改服務A、B、C，而A依賴B，B依賴C。在單體應用中，你只須要改變相關模塊，整合變化，部署就行了。對比之下，微服務架構模式就須要考慮相關改變對不一樣服務的影響。好比，你須要更新服務C，而後是B，最後纔是A。幸運的是，許多改變通常隻影響一個服務，而須要協調多服務的改變不多。

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

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

---

參考文章

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

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

---

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