微服務,一種軟件架構新風格

​ 微服務（Microservices）做爲近年來興起的軟件架構，Martinfowler在其多年前就在論文中提出，下面就跟大師一塊兒來領略微服務究竟是什麼？多多指教。

原文連接：https://martinfowler.com/arti...

---

​ 微服務是一種架構風格，相比於傳統單體應用，微服務以服務套件的方式來提供服務，每一個服務有本身的進程，服務間以輕量級通訊機制，一般是http，沒有中心管理機構。單體應用的組成方式則是client，service，database，系統改變須要整個單體應用從新部署，缺點在於隨着版本的更新，很難保持模塊化結構，在模塊內修改,且擴展成集羣模式時須要耗費大量沒必要要資源。

微服務特色

1. 服務組件化：

   • 微服務經過將系統經過服務分割的方式使其組件化，即服務套件，每一個組件可獨立替換和更新，應用改變只須要從新部署對應服務，固然也不絕對，由於要考慮該服務合做的一些服務。
   • 通訊方式：微服務的通訊是輕量級進程間通訊（process-out），一般是http，相比於單體應用進程內（inter-process）通訊，通訊消耗大，因此一個API最好是粗粒度的，減小請求次數；
   • 擁有更顯示的組件接口：大部分語言沒有一個好的機制來定義公開接口，一般只是文檔和一些規則來限制打破組件封裝，達到緊耦合目的，微服務經過顯示RPC使這種操做變得簡單。
   • 當須要修改時，若是跨越服務邊界，則在修改時比單體應用更爲困難。
   • 近似看，一個服務對應一個進程，可是一個服務能夠包含多個進程。

2. 圍繞業務能力組織團隊

   • 1. broad-stack 團隊組織：傳統系統的形式是前端，後端，數據庫的形式，一個小的改變都會須要整個團隊來進行配合。微服務團隊應該根據服務的分割構建團隊，每一個小團隊都有前，後，數據庫，造成broad-stack形式的Team，服務組件分割的越透明，那麼團隊邊界就越透明。

     

3. 產品而非項目

   • 產品心態作服務：大部分人將軟件當作一項功能的集合，功能開發完則團隊就解散掉。微服務提倡避免這種模式，一個團隊應該對一個產品的生命週期負責，you build , you run it ! 不能講交付當作一個功能的完成，應該以進行時的眼光發現如何幫助用戶來提升業務能力，固然會帶來一些維護壓力。

4. 通訊方式：智能端點和啞管道

   • RESTish協議：微服務社區偏好兩類通訊方式，HTTP協議和輕量級通訊總線，如RabiitMQ 和 ZeroMQ，啞是由於基礎設施是啞的，只扮演消息路由角色，smart表如今endpoits生產與消費消息。
   • 通訊模式：從單體應用到微服務應用最大的轉變就是通訊模式的改變，單體應用通訊是經過方法或函數調用，是進程內的，從進程內通訊轉到進程間通訊會致使通訊複雜，因此應該用粗粒度的API替代細粒度的API。

5. 去中心化管理

   • 利用不一樣語言優點：中心化管理的結果是在一個平臺上進行規範，有限制的，並非一個錘子對應一個釘子。所以，將單體分割成組件服務，你能夠用node實現頁面報表，c++作近實時通訊服務，也能夠用不一樣風格的數據庫來更好適應讀行爲。
   • 工具優點：微服務團隊更傾向於用工具來解決廣泛問題，而不是paper上的規範，如NetFlix公司開源的數據存儲、進程內通訊等工具箱，通過良好測試。

6. 去中心化數據管理

   • 數據庫再也不單一：每一個服務有本身的數據庫系統。
   • 數據更新管理：單體應用中數據庫用事務來保證一致性，微服務儘可能避免分佈式事務，很難實現。

     

7. 基礎設施自動化

   • 應儘量的創建自動化測試，部署流程，在這一方面與單體應用是一致的，讓持續交付（CD)變得省時省力。如Netflix的開源工具包。

     

8. 失敗設計

   • 服務監控：用微服務做爲組件，須要考慮的一個重要問題就是容忍失敗，每一個服務都有不可靠性，相比於單體應用的一個缺點，微服務在該方面更復雜，團隊應該對每一個服務創建監控，如狀態、操做、業務相關指標，更細節的如熔斷器，當前吞吐量，延遲等。Netflix'x simian army就是這樣一個工具。

9. 演變設計

   • 如何看待變動：微服務開發者應該講服務的分解當作是進一步控制應用的工具，應控制改變而不是減小改變，能夠更好的控制面對軟件變化。
   • 分解一個組件的原則是什麼？可獨立部署和更新，咱們能夠重寫且不影響到它的合做組件。更進一步，開發者能夠顯示的報廢它，而不是長期改進。
   • 模塊化驅動變動思想：如上述的組件分割原則。一些經驗，不多改變的服務應該與常常改變的服務不在一塊兒；若是兩個服務常常改變，那麼兩個服務應該被合併。衛報例子，從單體應用到微服務改造，核心仍然是單體應用，新功能用微服務構建，一些具備時效性事件，如運動，過時則廢掉。
   • 發佈：將服務做爲組件思想增長了更多粒度性發布組件的機會，單體應用須要從新部署，微服務只須要單獨部署該服務，簡化加快發佈流程，缺點是應該考慮服務對其消費者的影響。傳統繼承方法用版本號來解決這個問題，可是微服務來講這是最後解決方案，應該在服務的總體設計上儘量的容忍改變。

10. 微服務是將來嗎？

    • 微服務有衆多優勢，可是做者也不肯定會是將來軟件架構方向，須要足夠多的時間來證實。
    • 微服務還須要更成熟：好的系統是更好地適應組件，那麼如何精確的肯定組件邊界，演變設計能夠更好地 肯定組件邊界，讓重構變得簡單。可是當組件做爲服務通訊時，重構則超過進程內通訊困難，特別是跨越服務邊界的重構代碼，接口須要其餘組件配合，回退、測試能力你都應該具有。
    • 複雜性轉移：若是組件不夠清晰，那麼本質就是在將組件的複雜度轉移到組件鏈接處，因此你看着組件小簡單，可是組件間鏈接變得複雜。世界歷來都是守恆的。
    • 新技術用不用的跟團隊有很大關係，好的團隊用什麼都好。
    • 建議微服務應用從單體應用開始，再逐漸使其模塊化。但建議不是典範。