知識星球點選上方“芋道原始碼”，選擇“置頂公眾號”
技術文章第一時間送達！
原始碼精品專欄
目錄
背景
是什麼
能做什麼
如何實現
優勢
問題
展望
1 背景
1.1 多語言
微服務理念是提倡不同業務使用最適合它的語言開發，現實情況也確實如此，尤其是AI的興起，一般大型網際網路公司存在 C/C++、Java、Golang、PHP、Python、NodeJs 等語言的專案，這就意味著每種語言都需要實現了相同功能服務框架。然而，服務框架的 SDK 通常實現都比較重，需要實現服務註冊與發現、服務路由、負載均衡、服務鑒權、服務降級、服務限流、網路傳輸等功能，所以這塊的成本不言而喻。
1.2 產品交付
在伴隨著服務元件的功能升級，bug 修複過程中，業務系統需要升級依賴的服務元件包，升級中還可能存在各種版本衝突，而且灰度驗證過程也可能存在 bug，業務升級版本痛苦不堪，往往一個元件包想要全改寫升級，需要耗費相當長的時間，交付效率極其低下。隨著業務的不斷發展，業務的規模和我們交付的效率已經成為主要的矛盾，所以元件團隊期望以更高的效率去研發基礎設施，而不希望基礎設施的迭代受制於這個元件的使用規模。
1.3 雲原生
在雲原生架構裡，單個應用程式可能由數百個服務組成; 每個服務可能有數千個實體; 而且這些實體中的每一個都可能處於不斷變化的狀態，因為它們是動態排程一個像 Kubernetes 一樣的編排器。服務間通訊不僅異常複雜，而且也是執行時行為的基礎。管理好服務間通訊對於保證端到端的效能和可靠性來說是非常重要的。因此，管理好服務間通訊對於保證端到端的效能和可靠性來說是非常重要的。
基於以上背景，Service Mesh 產生了。
2 是什麼
在上述背景下業界也做了一些探索，比如唯品會在服務呼叫方增加了 Proxy 層，將服務元件公共的邏輯功能放在 Proxy 中實現，剩下與業務互動的 API 功能放在 Client 中實現，這樣來降低多語言的成本。另外，新浪微博也使用 Proxy 方案提供小眾語言的服務註冊和呼叫的支援。其實這種 Proxy 結構類似現在的 Service Mesh，只是當時還沒有 Service Mesh 這個名詞。
在 2016 年 Buoyant 的 CEO William 提出了 Service Mesh 的概念。Service Mesh 是一種基礎設施層，主要處理服務間的通訊，在複雜的雲原生服務拓撲中，負責請求的可靠傳遞。一般實現為網路代理，通常與業務服務部署在一起，業務服務不感知。
3 能做什麼
3.1 服務發現
以微服務樣式執行的應用變更非常頻繁，應用實體的頻繁增加減少帶來的問題是如何精確地發現新增實體以及避免將請求傳送給已不存在的實體變得更加複雜。Service Mesh 可以提供簡單、統一、平臺無關的多種服務發現機制，如基於 DNS，K/V 鍵值對儲存的服務發現機制。
3.2 動態路由
隨著服務提供商以提供高穩定性、高可用性以及高 SLA 服務為主要標的，為了實現所述標的，出現各種應用部署策略盡可能從技術手段達到無服務中斷部署，以此避免變更導致服務的中斷和穩定性降低，例如：Blue/Green 部署、Canary 部署，但是實現這些高階部署策略通常非常困難。如果可以輕鬆的將應用流量從一個版本切到另外一個版本，更或者從一個資料中心到另外一個資料中心進行動態切換，甚至可以透過一個中心控制層控制多少比例的流量被切換。那麼 Service Mesh 提供的動態路由機制和特定的部署策略如 Blue/Green 部署結合起來，實現上述標的更加容易。
3.3 負載均衡
執行環境中微服務實體通常處於動態變化狀態，而且經常可能出現個別實體不能正常提供服務、處理能力減弱、卡頓等現象。但由於所有請求對 Service Mesh 來說是可見的，因此可以透過提供高階負載均衡演演算法來實現更加智慧、高效的流量分發，降低延時，提高可靠性。
3.4 請求熔斷
動態的環境中服務實體中斷或者不健康導致服務中斷可能會經常發生，這就要求應用或者其他工具具有快速監測並從負載均衡池中移除不提供服務實體的能力，這種能力也稱熔斷，以此使得應用無需消耗更多不必要的資源不斷地嘗試，而是快速失敗或者降級，甚至這樣可避免一些潛在的關聯性錯誤。而 Service Mesh 可以很容易實現基於請求和連線級別的熔斷機制。
3.5 安全通訊
無論何時，安全在整個公司、業務系統中都有著舉足輕重的位置，也是非常難以實現和控制的部分。而微服務環境中，不同的服務實體間通訊變得更加複雜，那麼如何保證這些通訊是在安全、授權情況下進行非常重要。透過將安全機制如 TLS 加解密和授權實現在 Service Mesh 上，不僅可以避免在不同應用的重覆實現，而且很容易在整個基礎設施層更新安全機制，甚至無需對應用做任何操作。
3.6 多語言支援
由於 Service Mesh 作為獨立執行的透明代理，很容易支援多語言。
3.7 多協議支援
同多語言支援一樣，實現多協議支援也非常容易。
3.8 Metric和鏈路追蹤
Service Mesh 對整個基礎設施層的可見性使得它不僅可以暴露單個服務的執行資料，而且可以暴露整個叢集的執行資料。
3.9 重試
Service Mesh 的重試功能避免將其嵌入到業務程式碼，同時最後期限使得應用允許一個請求的最長生命週期，而不是無休止的重試。
4 如何實現
Service Mesh 最終實現是使用 Sidecar 邊車部署方式，將服務發現，服務路由，負載均衡等功能實現在 Sidecar 內，Sidecar 作為一個單獨的行程與業務服務部署在同一個機器上。
Sidecar 內部的具體實現稱為資料平面，而作為 Sidecar 的控制邏輯，稱之為控制平面。
如上圖中，應用作為服務的發起方，只需要用最簡單的方式將請求傳送給本地的服務網格代理，然後網格代理 Sidecar 會進行後續的操作，如服務發現，負載均衡等，最後將請求轉發給標的服務。當有大量服務相互呼叫時，它們之間的服務呼叫關係就會形成一種類似網格的形式。
Service Mesh 給基礎元件帶來了新的方向，可以透過 Service Mesh 的 Sidecar，將基礎元件的功能下層到 Sidecar 內，對業務透明，方便升級維護，並且解決多語言的問題。
5 優勢
5.1 多語言
由於 Service Mesh 共享了大部分的元件功能，所以在多語言實現上，更加簡單，各自的語言只需實現一些簡單的邏輯，就能提供的服務元件所有功能，從而大大降低多語言服務元件的實現成本。
5.2 產品交付
元件的大部分功能移至 Service Mesh 中，與業務邏輯隔離，可單獨進行升級，運維，對業務透明，提升了元件的交付能力。超越 Spring Cloud 和 Dubbo 等傳統開發框架之處在於不僅僅帶來了遠超這些框架所能提供的功能，更重要的是不需要應用程式為此做大量的改動， 開發人員也不必為上面的功能實現進行大量的知識儲備，降低學習服務元件的使用成本。
5.3 雲原生
在複雜的雲原生架構中，Service Mesh 能更好的管理服務間通訊對於保證端到端的效能和可靠性來說是非常重要的。
6 問題
6.1 效能
Service Mesh 方式的服務呼叫，相比服務框架的直接呼叫，增加了與 Service Mesh 中 Sidecar 的互動，必然會犧牲部分效能，但由於是本地網路通訊，不經過網路層傳輸，其效能損耗應該在可控範圍內。
6.2 可用性
Service Mesh 方式是透過單獨的本地行程來提供為應用程式提供服務，也就在整個服務呼叫鏈上增加了故障點，勢必會導致可用性下降，這就對 Service Mesh 的整體設計提出了更高的要求，來保證服務的可用性。
7 展望
有文章提到 Service Mesh 將是下一代服務架構，我們也期待 Service Mesh 更好的發展，給業務提升更多的便利，降低開發成本，提供更好的技術服務。
如果你對 Dubbo 感興趣，歡迎加入我的知識星球一起交流。
目前在知識星球（https://t.zsxq.com/2VbiaEu）更新瞭如下 Dubbo 原始碼解析如下：
01. 除錯環境搭建
02. 專案結構一覽
03. 配置 Configuration
04. 核心流程一覽
05. 拓展機制 SPI
06. 執行緒池
07. 服務暴露 Export
08. 服務取用 Refer
09. 註冊中心 Registry
10. 動態編譯 Compile
11. 動態代理 Proxy
12. 服務呼叫 Invoke
13. 呼叫特性
14. 過濾器 Filter
15. NIO 伺服器
16. P2P 伺服器
17. HTTP 伺服器
18. 序列化 Serialization
19. 叢集容錯 Cluster
20. 優雅停機
21. 日誌適配
22. 狀態檢查
23. 監控中心 Monitor
24. 管理中心 Admin
25. 運維命令 QOS
26. 鏈路追蹤 Tracing
…
一共 60 篇++