# Service Mesh基礎 **注意：本書中的 Service Mesh 章節已不再維護，請轉到 [istio-handbook](https://jimmysong.io/istio-handbook) 中瀏覽。** > 本文是對[The Enterprise Path to Service Mesh Architecutures](https://www.nginx.com/resources/library/the-enterprise-path-to-service-mesh-architectures/)一書的解讀。 微服務將原先的單體架構中的應用內通信，轉變為基于RPC的遠程通信，雖然這樣提高了研發效率，提高了開發語言選擇的多樣性，但是隨著單體應用的解體，原先的巨石散落為石塊變得四處都是，如何管理這些微服務就成了難題。當微服務的個數少的時候還可以通過人工配置的方式去管理，但隨著業務規模的增大，微服務的數量也可能呈指數級增長，如何協調管理成百上千的服務，這就需要有一套設計良好的框架。 一直以來都存在一個[謬誤](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)，那就是在分布式系統中網絡是可靠的。實際上網絡是不可靠的，而且也是不安全的，如何保證應用調用和事務的安全性與可靠性，保護微服務的一個專門的基礎設施層Service Mesh就應運而生。 Service Mesh是建立在物理或者虛擬網絡層之上的，基于策略的微服務的流量控制，與一般的網絡協議不同的是它有以下幾個特點： - 開發者驅動 - 可配置策略 - 服務優先的網絡配置而不是協議 本章主要介紹Service Mesh的定義和組成，為什么要使用Service Mesh，它可以帶來哪些好處。  Service Mesh與傳統網絡的區別就是**硬件或者虛擬網絡**與**軟件定義網絡（SDN）**的區別，我們從上圖中可以看到物理和虛擬網絡中比起SDN還多了**管理平面**。 硬件網絡中控制平面與數據平面緊耦合，也就是說是與供應商綁定的，管理平面是獨立出來的。而SDN卻給了我們很多自由度，可以通過軟件的形式自定義網絡，例如Kubernetes中的[CNI](https://jimmysong.io/kubernetes-handbook/concepts/cni.html)。 物理網絡有很多種拓撲類型，如星形拓撲、總線拓撲、環形拓撲、樹型拓撲、網狀拓撲等，大家可以去搜索拓撲網絡。不論是那種拓撲結構，總有一條路徑可以從一個節點路由到另一個節點，只是不同的拓撲類型效率不同，管理的復雜度不一樣罷了。 下圖是網狀拓撲，所謂網狀拓撲就是每個節點都可以跟所有其他節點直接互聯，這樣而這也是鏈接數最多一種拓撲，如果有n個節點的話，鏈接數就是n(n-1)。  ### Service Mesh架構 下圖是[Conduit](https://condiut.io) Service Mesh（現在已合并到Linkerd2中了）的架構圖，這是Service Mesh的一種典型的架構。  Service Mesh中分為**控制平面**和**數據平面**，當前流行的兩款開源的Service Mesh Istio和Linkerd實際上都是這種構造，只不過Istio的劃分更清晰，而且部署更零散，很多組件都被拆分，控制平面中包括Mixer、Pilot、Citadel，數據平面默認是用Envoy；而Linkerd中只分為linkerd做數據平面，namerd作為控制平面。 **控制平面** 控制平面的特點： - 不直接解析數據包 - 與控制平面中的代理通信，下發策略和配置 - 負責網絡行為的可視化 - 通常提供API或者命令行工具可用于配置版本化管理，便于持續集成和部署 **數據平面** 數據平面的特點： - 通常是按照無狀態目標設計的，但實際上為了提高流量轉發性能，需要緩存一些數據，因此無狀態也是有爭議的 - 直接處理入站和出站數據包，轉發、路由、健康檢查、負載均衡、認證、鑒權、產生監控數據等 - 對應用來說透明，即可以做到無感知部署 ### Service Mesh的價值所在 Service Mesh中服務是一等公民，它提供L5的網絡流量管理，并提供以下功能： **可觀察性** 還是拿Istio做例子，Mixer通過適配器將應用的遙測數據發送給后端監控、日志、認證和份額管理系統。  從上圖可以看到Mixer適配器可以對接多種監控和日志后端。 **流量控制** 文中給出的例子是超時、重試、截止時間和速率限制。 **安全性** 下圖是Istio中安全通信路徑的示意圖。  一般的安全性都是通過證書的方式實現的。Sidecar代理負責證書生命周期的管理，包括證書的生成、分發、刷新和注銷。從圖中還可以看到，在Pod內部sidecar會與應用容器之間建立本地TCP連接，其中使用mTLS（雙向傳輸層加密）。這一點是非常重要的，因為一個節點上甚至一個Pod內都不一定運行一個容器，容器可能會被暴露到外部訪問，保證傳輸層的雙向加密，可以保證流量傳輸的安全。 **延遲和故障注入** 這個功能對于榮宰容災和故障演練特別有用。通過人為的向系統中注入故障，如HTTP 500錯誤，通過分析分布式應用的行為，檢驗系統的健壯性。 ### 在L5解耦 這是本書最有重要的一個觀點，重要到要放到副標題，熟悉OSI模型的人都知道L5是什么。  *OSI模型（圖片來自[CSDN](https://blog.csdn.net/yaopeng_2005/article/details/7064869)）* Service Mesh是在開發和運維之間植入的一個基礎設施層。它將服務通信的關注點分離出來，在TCP/IP層之上抽象出一層通用功能。Service Mesh的引入直接導致生產關系的改變進而提高生產效率。具體表現在： - **運維人員**在修改服務重試超時時間之前無需再知會**開發人員**。 - **客戶成功**部門在撤銷客戶的訪問權限前無需再知會**運維**。 - **產品Owner**可以針對特定服務，根據用戶選擇的套餐執行配額管理。 - **開發人員**可隨時將新版本功能重定向到beta版本，不需要**運維人員**干涉。  這種職責的解耦大大加速了軟件的迭代速度，總之你可以把Service Mesh作為OSI模型中的會話層。