Service Mesh 瞭解嗎？

Service Mesh 瞭解嗎

簡書 滌生。
轉載請註明原創出處，謝謝！
如果讀完覺得有收穫的話，歡迎點贊加關注。

目錄

1. 背景
2. 是什麼
3. 能做什麼
4. 如何?
5. 優勢
6. 問題
7. 展望

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 的控制邏輯，稱之為控制面。

Service Mesh 架構圖

圖中應用作為服務的發起方，只需要用最簡單的方式將請求發送給本地的服務網格代理，然後網格代理會進行後續的操作，如服務發現，負載平衡，最後將請求轉寄給目標服務。當有大量服務相互調用時，它們之間的服務調用關係就會形成網格。

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 更好的發展，給業務提升更多的便利，降低開發成本，提供更好的技術服務。