下一代微服務 ~ Service Mesh

微服務（Microservices）

微服務（Microservices）是一種架構風格，一個大型複雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每一個微服務僅關注於完成一件任務並很好地完成該任務。在全部狀況下，每一個任務表明着一個小的業務能力

 

形像一點來講，微服務架構就像搭積木，每一個微服務都是一個零件，並使用這些零件組裝出不一樣的形狀。通俗來講，微服務架構就是把一個大系統按業務功能分解成多個職責單一的小系統，並利用簡單的方法使多個小系統相互協做，組合成一個大系統。

若是學科派一點，微服務架構就是把因相同緣由而變化的功能聚合到一塊兒，而把因不一樣緣由而變化的功能分離開，並利用輕量化機制（一般爲 HTTP RESTful API）實現通訊。

 

常見的微服務組件及概念：

• 服務註冊：服務提供方將本身調用地址註冊到服務註冊中心，讓服務調用方可以方便地找到本身。
• 服務發現：服務調用方從服務註冊中心找到本身須要調用的服務的地址。
• 負載均衡：服務提供方通常以多實例的形式提供服務，負載均衡功能可以讓服務調用方鏈接到合適的服務節點。而且，節點選擇的工做對服務調用方來講是透明的。
• 服務網關：服務網關是服務調用的惟一入口，能夠在這個組件是實現用戶鑑權、動態路由、灰度發佈、A/B 測試、負載限流等功能。
• 配置中心：將本地化的配置信息（properties, xml, yaml 等）註冊到配置中心，實現程序包在開發、測試、生產環境的無差異性，方便程序包的遷移。
• API 管理：以方便的形式編寫及更新 API 文檔，並以方便的形式供調用者查看和測試。
• 集成框架：微服務組件都以職責單一的程序包對外提供服務，集成框架以配置的形式將全部微服務組件（特別是管理端組件）集成到統一的界面框架下，讓用戶可以在統一的界面中使用系統。
• 分佈式事務：對於重要的業務，須要經過分佈式事務技術（TCC、高可用消息服務、最大努力通知）保證數據的一致性。
• 調用鏈：記錄完成一個業務邏輯時調用到的微服務，並將這種串行或並行的調用關係展現出來。在系統出錯時，能夠方便地找到出錯點。
• 支撐平臺：系統微服務化後，系統變得更加碎片化，系統的部署、運維、監控等都比單體架構更加複雜，那麼，就須要將大部分的工做自動化。如今，能夠經過 Docker 等工具來中和這些微服務架構帶來的弊端。 例如持續集成、藍綠髮布、健康檢查、性能健康等等。嚴重點，以咱們兩年的實踐經驗，能夠這麼說，若是沒有合適的支撐平臺或工具，就不要使用微服務架構。

微服務架構的優勢：

• 下降系統複雜度：每一個服務都比較簡單，只關注於一個業務功能。
• 鬆耦合：微服務架構方式是鬆耦合的，每一個微服務可由不一樣團隊獨立開發，互不影響。
• 跨語言：只要符合服務 API 契約，開發人員能夠自由選擇開發技術。這就意味着開發人員能夠採用新技術編寫或重構服務，因爲服務相對較小，因此這並不會對總體應用形成太大影響。
• 獨立部署：微服務架構可使每一個微服務獨立部署。開發人員無需協調對服務升級或更改的部署。這些更改能夠在測試經過後當即部署。因此微服務架構也使得 CI／CD 成爲可能。
• Docker 容器：和 Docker 容器結合的更好。
• DDD 領域驅動設計：和 DDD 的概念契合，結合開發會更好。

 

微服務架構的缺點：

• 微服務強調了服務大小，但實際上這並無一個統一的標準：業務邏輯應該按照什麼規則劃分爲微服務，這自己就是一個經驗工程。有些開發者主張 10-100 行代碼就應該創建一個微服務。雖然創建小型服務是微服務架構崇尚的，但要記住，微服務是達到目的的手段，而不是目標。微服務的目標是充分分解應用程序，以促進敏捷開發和持續集成部署。
• 微服務的分佈式特色帶來的複雜性：開發人員須要基於 RPC 或者消息實現微服務之間的調用和通訊，而這就使得服務之間的發現、服務調用鏈的跟蹤和質量問題變得的至關棘手。
• 分區的數據庫體系和分佈式事務：更新多個業務實體的業務交易至關廣泛，不一樣服務可能擁有不一樣的數據庫。CAP 原理的約束，使得咱們不得不放棄傳統的強一致性，而轉而追求最終一致性，這個對開發人員來講是一個挑戰。
• 測試挑戰：傳統的單體WEB應用只需測試單一的 REST API 便可，而對微服務進行測試，須要啓動它依賴的全部其餘服務。這種複雜性不可低估。
• 跨多個服務的更改：好比在傳統單體應用中，如有 A、B、C 三個服務須要更改，A 依賴 B，B 依賴 C。咱們只需更改相應的模塊，而後一次性部署便可。可是在微服務架構中，咱們須要仔細規劃和協調每一個服務的變動部署。咱們須要先更新 C，而後更新 B，最後更新 A。
• 部署複雜：微服務由不一樣的大量服務構成。每種服務可能擁有本身的配置、應用實例數量以及基礎服務地址。這裏就須要不一樣的配置、部署、擴展和監控組件。此外，咱們還須要服務發現機制，以便服務能夠發現與其通訊的其餘服務的地址。所以，成功部署微服務應用須要開發人員有更好地部署策略和高度自動化的水平。
• 總的來講（問題和挑戰）：API Gateway、服務間調用、服務發現、服務容錯、服務部署、數據調用。

網格服務（Service Mesh）

    若是用一句話來解釋什麼是 Service Mesh，能夠將它比做是應用程序或者說微服務間的 TCP/IP，負責服務之間的網絡調用、限流、熔斷和監控。對於編寫應用程序來講通常無須關心 TCP/IP 這一層（好比經過 HTTP 協議的 RESTful 應用），一樣使用 Service Mesh 也就無須關係服務之間的那些原來是經過應用程序或者其餘框架實現的事情，好比大名鼎鼎的apach Dubbo

 

Service Mesh 的前因後果：

1. 從最原始的主機之間直接使用網線相連
2. 網絡層的出現
3. 集成到應用程序內部的控制流
4. 分解到應用程序外部的控制流
5. 應用程序的中集成服務發現和斷路器
6. 出現了專門用於服務發現和斷路器的軟件包/庫，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，這時候仍是集成在應用程序內部
7. 出現了專門用於服務發現和斷路器的開源軟件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
8. 最後做爲微服務的中間層 Service Mesh 出現

Service Mesh 有以下幾個特色：

• 應用程序間通信的中間層
• 輕量級網絡代理
• 應用程序無感知
• 解耦應用程序的重試/超時、監控、追蹤和服務發現