Istio流控，服務發(fā)現(xiàn)，負載均衡，核心流程是如何實現(xiàn)的？
前情提要：
Istio架構(gòu)體系中，流控(Traffic Management)雖然是數(shù)據(jù)平面的Envoy Proxy實施的，但整個架構(gòu)的核心其實在于控制平面的Pilot。
灰度發(fā)布的過程在《Istio，灰度發(fā)布》一文中已經(jīng)有過描述，今天重點說說Pilot和Envoy的交互流程與內(nèi)部結(jié)構(gòu)。
一、通用交互流程
圖示：
- 灰色圓形，為業(yè)務服務
- 紫色六邊形，為Envoy代理
二者相生相伴。
起初，上游調(diào)用方ServiceA訪問下游服務提供方ServiceB的V1版本，在ServiceB的V2版本部署好之后，調(diào)用方如何知道“SvcA切分1%的流量至SvcB的V2版本”這個指令的呢?
整個過程主要分為三大步驟：
- 用戶在控制平面的后臺，通過Pilot的API，修改A到B的路由策略(標號1);
- Pilot將路由策略固化存儲，以便未來新注冊的調(diào)用方A能夠知道當前***的路由策略;對于已經(jīng)存在的調(diào)用方A，Pilot則通過主動通知的方式告之調(diào)用方A對應的Envoy(標號2);
- Envoy作為數(shù)據(jù)平面，實施***的路由策略(標號3)，在本例中，即將1%的流量導給灰度版本Bv2;
二、服務發(fā)現(xiàn)與負載均衡
講了通用的流控策略實施通用流程，而服務發(fā)現(xiàn)與負載均衡，只是一個種策略實施的特例：
- 提供服務的SvcB新增一個Pod(標號1);
- 在Pilot后臺修改SvcB的集群配置(標號2);
- Pilot將SvcB的***信息同步給該配置的訂閱方(標號3)，即SvcB的調(diào)用方SvcA對應的Proxy;
- SvcA對應的Proxy增加到SvcB的鏈接(標號4)，并實施負載均衡;
畫外音：實際是鏈接到SvcB對應的Proxy。
整個過程，與使用配置中心來實施服務發(fā)現(xiàn)基本類似。
三、請求的入口及出口
ServiceMesh的核心，是技術基礎設施與業(yè)務服務的解耦，服務A調(diào)用服務B，再次強調(diào)：
- 一個容器Pod內(nèi)的一個服務，服務進程(SrvA/SrvB)和邊車進程(Proxy)是相生相伴的，他們之間的交互是本地交互(標號1)
- 跨容器Pod之間的遠程調(diào)用，必須通過Proxy進行(標號2)
言下之意，服務A調(diào)用服務B，請求的流程是：
- SvcA -> SvcA Proxy -> SvcB Proxy -> SvcB
響應的流程則反過來：
- SvcB -> SvcB Proxy -> SvcA Proxy -> SvcA
跨網(wǎng)之間調(diào)用，請求的入口和出口，都是Proxy。
四、Pilot內(nèi)部結(jié)構(gòu)
Pilot它的內(nèi)部結(jié)構(gòu)并不復雜：
- Pilot的核心，是各種流控策略的維護，Abstract Model;
- 必然，Pilot需要提供接口給用戶，增刪查改這些策略，Rules API;
- 一方面，Pilot需要保持各類底層基礎設施的兼容性，Platform Adapter;
- 另一方面，Pilot又需要保持不同Proxy實接口的兼容性，Envoy API;
這么設計的好處是：
- Istio設計時已經(jīng)考慮了異構(gòu)的基礎設施，不管底層是K8s還是其他體系，都可以兼容
- 任何第三方可以實現(xiàn)自己的proxy，只要符合相關的API標準，都可以和Pilot集成
Pilot與Envoy的配合，是Istio的核心，如此一來：
- 服務發(fā)現(xiàn)(discovery)
- 負載均衡(load balancing)
- 故障恢復(failure recovery)
- 服務度量(metrics)
- 服務監(jiān)控(monitoring)
- A/B測試(A/B testing)
- 灰度發(fā)布(canary rollouts)
- 限流限速(rate limiting)
等很多能力都可以實現(xiàn)了。
MerviceMesh并沒有大家想的復雜。
思路比結(jié)論重要。
【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
