頭條：一文讀懂Service Mesh：邊車模式簡介

來源：活在信息時代時間：2022-10-28 15:52:56

自從2016年Service Mesh（服務網格）的概念被提出以來，短短幾年時間就受到了廣大程序員們的熱烈歡迎？為什么Service Mesh這么容易被接受呢？原因很簡單，那就是它切中了早期微服務架構的痛點。從而極大地解放了生產力。要理解它是如何解決了程序員們的生產力的，我們先從早期微服務框架的痛點開始說起。

(資料圖)

一、微服務架構的產生與問題

早期的很多系統都是單體服務的，就是把所有組件都塞在一個應用內，但是隨著軟件復雜性和并發用戶數的急劇增加，單體應用無論是從開發效率和運維管理方面都已經不能適應時代的發展了。于是把各種服務獨立出來，每個服務只關注自己的業務領域，與其它服務松耦合的微服務就應運而生了。

微服務架構具有以下幾個優點：

1、單?職責：拆分后的單個微服務，通常只負責單個高內聚自閉環功能，因此很易于開發、理解和維護。

2、架構靈活：不同微服務應用之間在技術選型層面幾乎是獨立的，可以?由選擇最適合的技術棧。

3、部署隔離：相比巨無霸單體應用，單個微服務應用的代碼和產物體積大大減少，更容易持續集成和快速部署；同時，通過進程級別的隔離，也不再像單體應用一樣只能同生共死，故障隔離效果顯著提升。

4、獨?擴展：單體應用時代，某個模塊如果存在資源瓶頸（e.g. CPU/內存），只能跟隨整個應用一起擴容，白白浪費很多資源。微服務化后，擴展的粒度細化到了微服務級別，可以更精確地按需獨立擴展。

但是，微服務帶來很多優點的時候，也出現了很多新的問題，最大的問題，就在于服務間通信的問題，具體來講，就是如下幾個問題：

如何找到服務的提供?？如何保證遠程調?的可靠性?如何降低服務調?的延遲？如何保證服務調?的安全性？

于是，為了解決這些問題，微服務技術特有的通信語義就出現了，如熔斷策略、負載均衡、服務發現、認證和授權、quota限制、trace和監控等等，服務根據業務需求來實現一部分所需的通信語義。

但是，這樣做的問題也非常明顯，那就是，在這個過程中，開發人員需要花費大量的時間去編寫與業務功能無關的代碼。雖然框架本身屏蔽了分布式系統通信的一些通用功能實現細節，但開發者卻要花更多精力去掌握和管理復雜的框架本身，在實際應用中，去追蹤和解決框架出現的問題也絕非易事。

另外，開發框架通常只支持一種或幾種特定的語言，沒有框架支持的語言編寫的服務，很難融入面向微服務的架構體系，想因地制宜地用多種語言實現架構體系中的不同模塊也很難做到。同時框架以lib庫的形式和服務聯編，復雜項目依賴時的庫版本兼容問題非常棘手框架庫的升級也無法對服務透明，服務會因為和業務無關的lib庫升級而被迫升級。

于是，為了解決這些問題，Service Mesh誕生了。

二、Service Mesh：微服務時代的TCP/IP協議

Serice Mesh的誕生，就是為了將微服務時代的通信語義剝離出來，從而使得微服務本身更加關注業務邏輯，它為每個微服務提供了一個代理，而這個代理如同TCP/IP協議一樣，把微服務時代所需要的通信語義放在一個層面完成，從而使得業務開發者們從繁重的工作中解放出來。而這個代理，就是大名鼎鼎的Sidecar（邊車)模式了。

Sidecar原意是指從二戰時開始被廣泛使用起來的挎斗摩托車。這個名字也是一種著名的飾以紅櫻桃的混合雞尾酒，同時也指在三人以上多人運動中，在旁邊處于輔助地位或者拍攝的人。

在Service Mesh中，監視、日志、限流、熔斷、服務注冊、協議轉換、冪等……" 這些功能，其實都是大同小異，是完全可以做成標準化的組件和模塊的。在這種情況下，邊車就像一個微服務的 Agent，這個服務所有對外的進出通訊都通過這個 Agent 來完成。這樣，我們就可以在這個 Agent 上做很多文章了。

這樣，所有的微服務通過Sidecar連接起來之后，就像一個網格一樣，這也是Service Mesh名稱的由來。

那么，Sidecar具體的作用是什么呢？我們以Service Mesh概念的提出者Buoyant出品的Linkerd為例，來解析一下邊車模式的服務流程。在Linkerd里面，一個服務請求的處理流程包括以下幾個部分：

1、動態路由：根據上游服務請求參數，確定下游目標服務；除了常規的服務路由策略，Linkerd還可以通過這一層動態路由能力，支持灰度發布、A/B測試、環境隔離等非常有價值的場景。

2、服務發現：確定目標服務后，下一步就是獲取對應的實例的地址列表（e.g. 查詢service registry）。

3、負載均衡：如果列表中有多個地址，Linkerd會通過負載均衡算法（e.g. Least Loaded、Peak EWMA）選擇其中?個合適的低延遲實例。

4、執行請求：發送請求到上一步所選擇的實例，并記錄延遲和響應結果。

5、重試處理：如果請求未響應，則選擇另?個實例重試（前提：Linkerd知道該請求是冪等的）。

6、熔斷處理：如果發往某個實例的請求經常失敗，則主動從地址列表中剔除該實例。

7、超時處理：如果請求超期（在給定的deadline時間點之前仍未返回），則主動返回失敗響應。

8、可觀測性：Linkerd會持續收集和上報上述各種行為數據，包括Metrics和Tracing。

而這些服務，就類似于TCP服務提供的網絡傳輸處理邏輯了，類似于TCP服務解決了網絡傳輸中通用的流量控制問題，將技術棧下移，從服務的實現中抽離出來，成為操作系統網絡層的一部分一樣，Service Mesh也將微服務間通信所需要的通用功能剝離出來，將技術棧單獨抽出一層，從而成為分布式系統的一部分。

三、主流Service Mesh實現