前情提要：

• 《ServiceMesh究竟解決什么問題?》
• 《Istio究竟是什么?》
• 《Istio分層架構設計?》

Istio架構體系中，流控(Traffic Management)雖然是數據平面的Envoy Proxy實施的，但整個架構的核心其實在于控制平面的Pilot。

灰度發布的過程在《Istio，灰度發布》一文中已經有過描述，今天重點說說Pilot和Envoy的交互流程與內部結構。

[[267516]]

一、通用交互流程

圖示：

• 灰色圓形，為業務服務
• 紫色六邊形，為Envoy代理

二者相生相伴。

起初，上游調用方ServiceA訪問下游服務提供方ServiceB的V1版本，在ServiceB的V2版本部署好之后，調用方如何知道“SvcA切分1%的流量至SvcB的V2版本”這個指令的呢?

整個過程主要分為三大步驟：

• 用戶在控制平面的后臺，通過Pilot的API，修改A到B的路由策略(標號1);
• Pilot將路由策略固化存儲，以便未來新注冊的調用方A能夠知道當前***的路由策略;對于已經存在的調用方A，Pilot則通過主動通知的方式告之調用方A對應的Envoy(標號2);
• Envoy作為數據平面，實施***的路由策略(標號3)，在本例中，即將1%的流量導給灰度版本Bv2;

二、服務發現與負載均衡

講了通用的流控策略實施通用流程，而服務發現與負載均衡，只是一個種策略實施的特例：

• 提供服務的SvcB新增一個Pod(標號1);
• 在Pilot后臺修改SvcB的集群配置(標號2);
• Pilot將SvcB的***信息同步給該配置的訂閱方(標號3)，即SvcB的調用方SvcA對應的Proxy;
• SvcA對應的Proxy增加到SvcB的鏈接(標號4)，并實施負載均衡;

畫外音：實際是鏈接到SvcB對應的Proxy。

整個過程，與使用配置中心來實施服務發現基本類似。

三、請求的入口及出口

ServiceMesh的核心，是技術基礎設施與業務服務的解耦，服務A調用服務B，再次強調：

• 一個容器Pod內的一個服務，服務進程(SrvA/SrvB)和邊車進程(Proxy)是相生相伴的，他們之間的交互是本地交互(標號1)
• 跨容器Pod之間的遠程調用，必須通過Proxy進行(標號2)

言下之意，服務A調用服務B，請求的流程是：

SvcA -> SvcA Proxy -> SvcB Proxy -> SvcB 

響應的流程則反過來：

SvcB -> SvcB Proxy -> SvcA Proxy -> SvcA 

跨網之間調用，請求的入口和出口，都是Proxy。

四、Pilot內部結構

Pilot它的內部結構并不復雜：

• Pilot的核心，是各種流控策略的維護，Abstract Model;
• 必然，Pilot需要提供接口給用戶，增刪查改這些策略，Rules API;
• 一方面，Pilot需要保持各類底層基礎設施的兼容性，Platform Adapter;
• 另一方面，Pilot又需要保持不同Proxy實接口的兼容性，Envoy API;

這么設計的好處是：

• Istio設計時已經考慮了異構的基礎設施，不管底層是K8s還是其他體系，都可以兼容
• 任何第三方可以實現自己的proxy，只要符合相關的API標準，都可以和Pilot集成

Pilot與Envoy的配合，是Istio的核心，如此一來：

• 服務發現(discovery)
• 負載均衡(load balancing)
• 故障恢復(failure recovery)
• 服務度量(metrics)
• 服務監控(monitoring)
• A/B測試(A/B testing)
• 灰度發布(canary rollouts)
• 限流限速(rate limiting)

等很多能力都可以實現了。

MerviceMesh并沒有大家想的復雜。

思路比結論重要。

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文