service mesh（一）架構發展曆史

文章目錄

• service mesh（一）架構發展曆史
• • 資料面和控制面
  • service mesh架構演變
  • istio
  • • sidecar模式
  • 流量治理
  • • 熔斷
    • 限流

資料面和控制面

圖中proxy節點是service mesh的資料面，是一個單獨的程序，和運作着業務邏輯的service程序部署在同一台機器或者節點上，proxy節點代理流經service程序的所有流量，如執行服務發現，限流，流量治理政策都是通過這個資料面完成的

圖中control plane是service mesh的控制面，proxy節點需要執行的路由流量，治理政策都是通過這個控制面下發的

可以看到，資料面和控制面是對業務程序隔離的，即實作了流量治理和業務邏輯解耦

service mesh架構演變

k8s ingress做流量轉發

• 可以利用k8s的原生能力實作對進出叢集的流量處理，但是無法管理叢集内服務間的流量

k8s ingress+route層

• 由于k8s的ingress隻能實作對進出叢集的流量進行處理，對于叢集内服務間的流量則通過在叢集内增加route層實作，讓叢集内所有服務間的流量都通過該路由器，通過該route層對所有流量進行管理

Proxy per Node

• 在每一個節點上都部署一個proxy節點，節點間服務通信的流量都通過這個proxy節點，這種架構有個好處是每個節點隻需要部署一個代理即可，比起在每個應用中都注入一個sidecar的方式更節省資源，而且更适合基于實體機/虛拟機的大型單體應用，但是也有一些副作用，比如粒度還是不夠細，如果一個節點出問題，該節點上的所有服務就都會無法通路，對于服務來說不是完全透明的。

Sidecar代理/Fabric模型

• 接近service mesh模型，缺少資料面，sidecar需要支援熱更新

service mesh最終形态

istio

Istio 作為控制平面，在每個服務中注入一個 Envoy 代理以 Sidecar 形式運作來攔截所有進出服務的流量，同時對流量加以控制

Istio 的組成

• Pilot：服務發現、流量管理
• Mixer：通路控制、遙測
• Citadel：終端使用者認證、流量加密

sidecar模式

sidecar模式是istio采用的模式

對于service mesh來說，sidecar就是用于處理進出入業務服務流量的代理節點

在 Kubernetes 的 Pod 中，在原有的應用容器旁邊運作一個 Sidecar 容器，可以了解為兩個容器共享存儲、網絡等資源，可以廣義的将這個注入了 Sidecar 容器的 Pod 了解為一台主機，兩個容器共享主機資源。所有進出應用容器的流量都會被sidecar攔截處理

流量治理

熔斷

什麼是服務雪崩？一個服務的不可用導緻這個服務所在的整條鍊路服務不可用，稱之為服務雪崩

上圖是服務雪崩的示例，假設我們的系統由5個服務組成，服務1調用服務2、3，服務3調用服務4、5，但由于某些原因（到達性能極限、未知bug、網絡分區等）服務4通路很慢，這時如果沒有服務的熔斷與降級那麼調用者服務3會因為服務4異常而積累過多請求導緻産生大量等待的線程（BIO模型），進而服務3也會引發通路慢或中止服務的問題，對其調用服務1也會重複服務3的問題，如此一來，由服務4本身的問題而引發依賴服務的整個鍊路都出問題，這就是典型的服務雪崩效應。

是以，服務熔斷就是指當下遊服務因為某種原因變得不可用或者響應過慢或者請求錯誤數達到一定門檻值時，上遊服務為了保證自己整體服務的可用性，在一定時間内不再繼續調用有問題的下遊服務，直接傳回，避免請求阻塞等待導緻服務資源耗盡崩潰，時間過後會嘗試放行部分請求來請求下遊服務，如果還有問題，則繼續熔斷

限流

限流是基于這樣的一個事實：Server 在過載狀态下，其請求處理的成功率會降低。比如一個 Server 節點正常情況下能夠處理 2000 QPS，在過載情況下（假設達到 3000 QPS），這個 Server 就隻能處理 1000 QPS 甚至更低。限流可以主動 drop 一些流量，使得 Server 本身不會過載，防止雪崩效應。