服務網格模式(Server Mesh)

服務網格模式(Server Mesh)

服務網格模式可以看作是邊車模式的集羣方式，當多個邊車相互連接在一起就形成了一個一個的服務網格，網格其實就是相互關聯的服務

Server Mesh(去中心化)：

在網絡協議棧中，爲了避免應用程序加入一些流量控制、擁塞的邏輯，從而將一些保證數據可靠到達對端的基本邏輯封裝到一個組件中也就是TCP協議，然而應用程序只關心業務邏輯，已經需要發送什麼格式數據到對方就可以，將流控和擁塞控制交給TCP。 其實這裏的Server Mesh 就類似於TCP協議。

服務容錯和保護：
限流、熔斷(斷路器會記錄服務返回的異常次數，例如服務不可用錯誤，當異常次數達到閾值時，就會對斷路器進行熔斷對後面的請求直接返回錯誤或特定值)、流量監控、日誌記錄、權限控制、服務發現和路由

以上功能都是對服務進行控制，如果把這些功能做成一個組件或作爲一個服務提供給應用進行使用，那麼應用就只關心其業務邏輯就行。如果把Server Mesh做成一個向外提供的集羣服務(例如Pass服務)，只要業務服務往這個集羣服務加入，由Server Mesh幫你完成一些控制邏輯(服務容錯和保護)

應用和邊車是如何工作？

應用和邊車部署在同個機器上(不同的進程，通過本地RPC進行通訊)也可以在不同機器進行數據通訊， 邊車你可以看作成應用的網絡代理(邊車能夠實現服務發現和路由、限流和熔斷等邏輯處理)，同時還需要有個控制中心，對當前服務流量進行收集、分發各種策略到邊車上。

Dubbo和服務網格區別

Dubbo僅僅是RPC框架，實現服務發現和路由進行兩臺計算機數據傳遞，並不提供限流和熔斷等一些其他功能，要實現這種功能就需要引入 Hystrix或Sentinel 第三方jar來實現限流和熔斷功能，實際上就是一個代理，完成請求、或錯誤的統計，當達到閾值時返回一個固定值或拒絕請求。

Dubbo在消費端獲取到服務提供端的地址，然後直接調用服務端接口，而服務網格是消費端將請求交給一個邊車服務(網絡代理服務)，由這個邊車實現服務路由和其他控制邏輯，最終會將請求交給服務提供者邊車，最終再傳給服務提供者，處理完後返回結果。

爲什麼要用服務網格

爲服務於服務之間通訊提供了通訊的基礎設施，更好的管理分佈式服務，同時爲了保證分佈式服務高可用性，需要對流量實時監控，必要時爲了保證服務穩定運行下去需要進行限流和熔斷處理。

服務網格模式和網關模式區別

使用服務網格是去中心化的一種實現，不像網關模式那樣中心化。當網關前面一層負載均衡器down機了就會導致所有服務不可用，負載均衡器實現高可用成本較大(負載均衡器的高可用使用虛擬IP技術實現)。從用戶請求發起會經過nginx->網關->服務鏈路太長，網絡時延大。服務網格把負載均衡邏輯放在了調用端。由於每個服務邊上都有個邊車，所以服務網格架構部署更復雜。

將原來每個服務邊上的邊車換成了集中式的網關模式
網關模式不必管理所有服務節點，根據需要可以針對某幾個應用服務進行管理。當後端服務很多時，可以給每組服務設定一個子網關，由總網關進行分發請求到子網關上，最後打到各個服務上。

網關和服務網格使用場景

一般網關代理用戶請求到應用服務，因爲客戶端不易支持一些複雜的協議和一些複雜的邏輯，因此更合適發送http請求。 但是服務之間調用非常頻繁，一個http請求接口可能導致後端多個服務之間進行調用，所以在服務內部之間更合適使用服務網格方式調用，減少了網絡時延並且在調用端實現負載均衡邏輯，是一種去中心化的實現