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

時間 2019-11-16

原文原文鏈接

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

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

The Enterprise Path to Service Mesh，還有個副標題Decoupling at Layer 5，初版發行於2018年8月8日。這本書一共61頁，本文是我對該書的一些解讀，讀者能夠在 Nginx的網站上免費下載閱讀完整內容。

關於做者

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

圖書封面

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

第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是什麼。

OSI模型（圖片來自 CSDN）

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

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

這種職責的解耦大大加速了軟件的迭代速度，總之你能夠把Service Mesh做爲OSI模型中的會話層。

第2章技術對比

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

爲何有了如Kubernetes這樣的容器編排咱們還須要Service Mesh呢，下表是對容器編排調度器的核心功能和缺乏的服務級別能力對比。

核心能力	缺乏的服務級別能力
集羣管理	熔斷
調度	L7細粒度的流量控制
編排器和主機維護	混沌測試
服務發現	金絲雀部署
網絡和負載均衡	超時、重試、 budget和deadline
有狀態服務	按請求路由
多租戶、多region	策略
簡單的應用監控檢查和性能監控	傳輸層安全（加密）
應用部署	身份和訪問控制
配置和祕鑰管理	配額管理
/	協議轉換（REST、gRPC）

以上是容器編排中缺乏的服務級別的能力，當讓相似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以前須要考慮的因素。

因素	能夠考慮使用Service Mesh	強烈建議使用Service Mesh
服務通訊	基本無需跨服務間的通信	十分要求服務間通信
可觀察性	只關注邊緣的指標便可	內部服務和邊緣指標都要考慮以更好的瞭解服務的行爲
客戶關注	主要關注外部API的體驗，內外用戶是隔離的	內部外部用戶沒有區別體驗一致
API的界限	API主要是做爲客戶端爲客戶提供，內部的API與外部是分離的	API即產品，API就是你的產品能力
安全模型	經過邊緣、防火牆可信內部網絡的方式控制安全	全部的服務都須要認證和鑑權、服務間要加密、zero-trust安全觀念