前情提要： 《ServiceMesh究竟解决什么问题?控服》 《Istio究竟是什么?》 《Istio分层架构设计?》 Istio架构体系中，流控(Traffic Management)虽然是现负心流数据平面的Envoy Proxy实施的，但整个架构的载均核心其实在于控制平面的Pilot。 灰度发布的衡核过程在《Istio，灰度发布》一文中已经有过描述，程何今天重点说说Pilot和Envoy的实现交互流程与内部结构。 
一、控服通用交互流程 
图示： 灰色圆形，现负心流为业务服务 紫色六边形，载均为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并没有大家想的复杂。 思路比结论重要。 【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】 
戳这里，看该作者更多好文 | 
喜欢
讨厌