企業級服務網格架構之路解讀——Service Mesh在會話層解耦

追本溯源，Service Mesh實際上是一種SDN，等同於OSI模型中的會話層。 每一次技術變革，必然要導致生產力和生產關係的變革，我們看到這種趨勢正在加速。本書中給出了企業上Service Mesh的路徑，可供廣大技術和管理人員參考。

這是一本由Nginx贊助，O’Reilly出版社出品的關於服務網格的書籍，本書標題是

關於作者

本書作者是Lee Calcote，先後在Cisco、Seagate、Solarwind任職負責技術戰略決策，參與DMTF（Distributed Management Task Foundation）、CIS（Center for Internet Security），還是CNCF Ambassador、Docker Captain。

下面看下本書目錄，大體瞭解下本書講了哪些內容。

目錄

第1章 Service Mesh基礎

• 管控多個服務
• 什麼是Service Mesh
• 為什麼需要Service Mesh
• 結論

第2章 技術對比

• 不同的服務網格（還有Gateway）
• 容器編排
• API Gateway
• 客戶端庫
• 總結

第3章 採納和演進

• 漸漸式採納
• 採納步驟
• 改造部署
• 架構演進
• 總結

第4章 定製和整合

• 可定製Sidecar
• 可擴充套件介面卡
• 總結

第5章 總結

• 用還是不用？

下面將對每章解讀。

第1章 Service Mesh基礎

微服務將原先的單體架構中的應用內通訊，轉變為基於RPC的遠端通訊，雖然這樣提高了研發效率，提高了開發語言選擇的多樣性，但是隨著單體應用的解體，原先的巨石散落為石塊變得四處都是，如何管理這些微服務就成了難題。當微服務的個數少的時候還可以通過人工配置的方式去管理，但隨著業務規模的增大，微服務的數量也可能呈指數級增長，如何協調管理成百上千的服務，這就需要有一套設計良好的框架。

一直以來都存在一個謬誤，那就是在分散式系統中網路是可靠的。實際上網路是不可靠的，而且也是不安全的，如何保證應用呼叫和事務的安全性與可靠性，保護微服務的一個專門的基礎設施層Service Mesh就應運而生。

Service Mesh是建立在物理或者虛擬網路層之上的，基於策略的微服務的流量控制，與一般的網路協議不同的是它有以下幾個特點：

• 開發者驅動
• 可配置策略
• 服務優先的網路配置而不是協議

本章主要介紹Service Mesh的定義和組成，為什麼要使用Service Mesh，它可以帶來哪些好處。

Service Mesh與傳統網路的區別就是硬體或者虛擬網路與軟體定義網路（SDN）的區別，我們從上圖中可以看到物理和虛擬網路中比起SDN還多了管理平面。

硬體網路中控制平面與資料平面緊耦合，也就是說是與供應商繫結的，管理平面是獨立出來的。而SDN卻給了我們很多自由度，可以通過軟體的形式自定義網路，例如Kubernetes中的CNI。

物理網路有很多種拓撲型別，如星形拓撲、匯流排拓撲、環形拓撲、樹型拓撲、網狀拓撲等，大家可以去搜尋拓撲網路。不論是那種拓撲結構，總有一條路徑可以從一個節點路由到另一個節點，只是不同的拓撲型別效率不同，管理的複雜度不一樣罷了。

下圖是網狀拓撲，所謂網狀拓撲就是每個節點都可以跟所有其他節點直接互聯，這樣而這也是連結數最多一種拓撲，如果有n個節點的話，連結數就是n(n-1)。

Service Mesh架構

下圖是Conduit 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是什麼。

Service Mesh是在開發和運維之間植入的一個基礎設施層。它將服務通訊的關注點分離出來，在TCP/IP層之上抽象出一層通用功能。Service Mesh的引入直接導致生產關係的改變進而提高生產效率。具體表現在：

• 運維人員在修改服務重試超時時間之前無需再知會開發人員。
• 客戶成功部門在撤銷客戶的訪問許可權前無需再知會運維。
• 產品Owner可以針對特定服務，根據使用者選擇的套餐執行配額管理。
• 開發人員可隨時將新版本功能重定向到beta版本，不需要運維人員干涉。

這種職責的解耦大大加速了軟體的迭代速度，總之你可以把Service Mesh作為OSI模型中的會話層。

第2章 技術對比

這一章主要講解Service Mesh技術之間的區別，Service Mesh與其他相關技術之間的區別，讀者可以直接瀏覽該網站來檢視對比：layer5.io/service-mes…

為什麼有了如Kubernetes這樣的容器編排我們還需要Service Mesh呢，下表是對容器編排排程器的核心功能和缺少的服務級別能力對比。

以上是容器編排中缺少的服務級別的能力，當讓類似Kubernetes這樣的容器編排系統中也有服務管理的能力，如Ingress Controller，但是它僅僅負責叢集內的服務對外暴露的反向代理，每個Ingress Controller的能力受限於Kubernetes的程式設計模型。對服務進行管理還可以通過例如Kong、基於雲的負載均衡器、API Gateway和API管理來實現，在沒有Service Mesh的時候還需要如Finagle、Hystrix、Ribbon客戶端庫的加持。

下圖是一個使用客戶端庫將應用與服務治理緊耦合的示意圖。

從圖中我們可以看到，應用程式程式碼與客戶端度庫緊耦合在一起，不同的服務團隊需要一起協調超時和重試機制等。容器編排更適用於分散式應用，API Gateway通常只需要部署在系統邊緣即可，不需要在每個應用中都部署，而Service Mesh卻需要在每個服務或者說節點中部署。

第3章 採納和演進

沒有人會一下子採納Service Mesh架構的所有元件，或者一次性將所有的應用都改造成Service Mesh的，都是漸漸式採納，從非核心繫統開始改造。採納Service Mesh就兩種路徑：

• 全盤採納：通常對於新應用來說才會這樣做，也叫做Greenfiled專案
• 漸進式採納：舊系統改造，也叫做Brownfiled專案

通過價值驅動、開發人員的接受程度、自底向上的選擇你最急切需要的功能，可能是可觀察性或RPC的負載均衡等等，先採納部分功能，然後通過漸漸式的方式來演進。

架構演進

我們在前面看到了通過客戶端庫來治理服務的架構圖，那是我們在改造成Service Mesh架構前使用微服務架構通常的形式，下圖是使用Service Mesh架構的最終形式。

當然在達到這一最終形態之前我們需要將架構一步步演進，下面給出的是參考的演進路線。

Ingress或邊緣代理

如果你使用的是Kubernetes做容器編排排程，那麼在進化到Service Mesh架構之前，通常會使用Ingress Controller，做叢集內外流量的反向代理，如使用Traefik或Nginx Ingress Controller。

這樣只要利用Kubernetes的原有能力，當你的應用微服務化並容器化需要開放外部訪問且只需要L7代理的話這種改造十分簡單，但問題是無法管理服務間流量。

路由器網格

Ingress或者邊緣代理可以處理進出叢集的流量，為了應對叢集內的服務間流量管理，我們可以在叢集內加一個Router層，即路由器層，讓叢集內所有服務間的流量都通過該路由器。

這個架構無需對原有的單體應用和新的微服務應用做什麼改造，可以很輕易的遷移進來，但是當服務多了管理起來就很麻煩。

Proxy per Node

這種架構是在每個節點上都部署一個代理，如果使用Kubernetes來部署的話就是使用DaemonSet物件，Linkerd第一代就是使用這種方式部署的，一代的Linkerd使用Scala開發，基於JVM比較消耗資源，二代的Linkerd使用Go開發。

這種架構有個好處是每個節點只需要部署一個代理即可，比起在每個應用中都注入一個sidecar的方式更節省資源，而且更適合基於物理機/虛擬機器的大型單體應用，但是也有一些副作用，比如粒度還是不夠細，如果一個節點出問題，該節點上的所有服務就都會無法訪問，對於服務來說不是完全透明的。

Sidecar代理/Fabric模型

這個一般不會成為典型部署型別，當企業的服務網格架構演進到這一步時通常只會持續很短時間，然後就會增加控制平面。跟前幾個階段最大的不同就是，應用程式和代理被放在了同一個部署單元裡，可以對應用程式的流量做更細粒度的控制。

這已經是最接近Service Mesh架構的一種形態了，唯一缺的就是控制平面了。所有的sidecar都支援熱載入，配置的變更可以很容易的在流量控制中反應出來，但是如何操作這麼多sidecar就需要一個統一的控制平面了。

Sidecar代理/控制平面

下面的示意圖是目前大多數Service Mesh的架構圖，也可以說是整個Service Mesh架構演進的最終形態。

這種架構將代理作為整個服務網格中的一部分，使用Kubernetes部署的話，可以通過以sidecar的形式注入，減輕了部署的負擔，可以對每個服務的做細粒度許可權與流量控制。但有一點不好就是為每個服務都注入一個代理會佔用很多資源，因此要想方設法降低每個代理的資源消耗。

多叢集部署和擴充套件

以上都是單個服務網格叢集的架構，所有的服務都位於同一個叢集中，服務網格管理進出叢集和叢集內部的流量，當我們需要管理多個叢集或者是引入外部的服務時就需要網格擴充套件和多叢集配置。

第4章 定製和整合

例如Istio這樣的Service Mesh中有很多地方可以給大家定製，例如作為資料平面的sidecar，雖然預設使用的是Envoy，但是你可以開發自己的sidecar代理；還有Mixer中的各種adpater，你也可以開發自己的adapter來擴充套件遙測和鑑權功能，Consul Connect就是個例子。

當前可選擇的開源的代理可以在landscape裡找到，例如使用nginMesh替代Envoy作為資料平面。下圖是使用nginMesh作為sidecar的架構圖。

nginMesh

通過擴充套件Istio Mixer adapter來對接不同的監控後端。

SOFAMosn

還有螞蟻金服開源的Go語言版的資料平面SOFAMosn，這是也相容Istio的SOFAMesh的一部分，也可以單獨作為代理使用，詳見：SOFAMesh & SOFA MOSN—基於Istio構建的用於應對大規模流量的Service Mesh解決方案。

SOFAMosn的模組架構圖。

在未來我們會看到更多定製的資料平面和Mixer介面卡出現。

總結

最後一章是對全書的總結，2018年必然是一場服務網格或者說Proxy的戰爭。

用還是不用

既然Service Mesh這麼好，那到底用還是不用，如果用的話應該什麼時候用，應該怎麼用？這取決於您的公司的雲原生技術的成熟度曲線的位置，服務的規模，業務核心和底層基礎設施管理是否適應等。

技術總是在不斷向前發展，容器出現後，解決的軟體環境和分發的問題；但是如何管理分散式的應用呢，又出現了容器編排軟體；容器編排軟體解決的微服務的部署問題，但是對於微服務的治理的功能太弱，這才出現了Service Mesh，當然Service Mesh也不是萬能的，下一步會走向何方呢？會是Serverless嗎？我們拭目以待。

Service Mesh還有一些遺留的問題沒有解決或者說比較薄弱的功能：

• 分散式應用的除錯，可以參考squash
• 服務拓撲和狀態圖，可以參考kiali和vistio
• 多租戶和多叢集的支援
• 白盒監控、支援APM
• 加強負載測試工具slow_cooker、fortio、lago等
• 更高階的fallback路徑支援
• 可拔插的證書授權組建，支援外部的CA

下面是採納Service Mesh之前需要考慮的因素。

在考慮完上述因素後，儘量選擇開源的平臺和解決方案，還要想好開源軟體的邊界在哪裡，哪些能力將是企業版才會提供的。

本文轉載自：jimmysong.io/posts/the-e…