上一篇总结：《ServiceMesh究竟解决什么问题?》《Istio究竟是什么?》《Istio分层架构设计?》在Istio架构体系中，虽然TrafficManagement在数据平面上是由EnvoyProxy实现的，但是整个架构的核心在于控制平面上的Pilot。灰度发布过程已经在文章《Istio，灰度发布》中进行了描述。今天重点介绍Pilot和Envoy的交互流程和内部结构。1.通用交互流程图：灰色圆圈为业务服务，紫色六边形为Envoy代理。两人相互陪伴。首先，上游调用者ServiceA访问下游服务提供者ServiceB的V1版本。V2版本的ServiceB部署后，调用者如何知道“SvcA分流1%给V2版本的SvcB”指令？整个过程主要分为三个步骤：在控制面后台，用户通过Pilot（标签1）的API修改从A到B的路由策略；Pilot将路由策略固化存储，以便以后新注册的呼叫者A可以知道当前*最新的路由策略；对于已有的调用者A，Pilot通过主动通知的方式将对应的Envoy（标签2）通知给调用者A；Envoy作为数据平面，执行最新的路由策略（标签3），在本例中，1%的流量被导向灰度版本Bv2；2、服务发现和负载均衡讲了一般的流控策略实现过程，服务发现和负载均衡只是策略实现的一个特例：在提供服务的SvcB中添加一个Pod（标签1）；在Pilot后台修改SvcB（标号2）的集群配置；调用方SvcA对应的Proxy；将SvcA对应的Proxy加入到SvcB的链路（标签4）中，实现负载均衡；画外音：其实是链接到Sv??cB对应的Proxy。整个过程基本类似于使用配置中心实现服务发现。3.请求入口和出口ServiceMesh的核心是技术基础设施和业务服务的解耦。服务A调用服务B。还是那句话：一个容器Pod中的一个服务，服务进程（SrvA/SrvB）和sidecar进程（Proxy）诞生并伴随，它们之间的交互是本地交互（标签1）。跨容器Pod之间的远程调用必须通过Proxy（标签2）进行。言外之意是服务A调用服务B，请求的过程是：SvcA->SvcAProxy->SvcBProxy->SvcB响应过程是相反的：SvcB->SvcBProxy->SvcAProxy->SvcA在网络之间被调用，而请求的进入和退出都是Proxy。4.Pilot内部结构Pilot内部结构并不复杂：Pilot的核心是维护各种流量控制策略，AbstractModel；Pilot不可避免地需要提供接口供用户增删改查这些策略，RulesAPI；一方面，Pilot需要维护各种底层基础设施的兼容性，PlatformAdapter；另一方面，Pilot需要保持不同Proxy真实接口、EnvoyAPI的兼容性；这样设计的好处是：Istio已经设计了异构的基础设施，不管底层系统是K8s还是其他系统，都兼容任何可以实现自己代理的第三方。只要符合相关API标准，就可以与Pilot集成。Pilot和Envoy的配合是Istio的核心。这样：服务发现（discovery）负载均衡（loadbalancing）故障恢复（failurerecovery）服务指标（metrics）服务监控（monitoring）A/B测试（A/BtestingCanaryrolloutslimiting）等很多能力都可以得以实现。ServiceMesh并没有大家想象的那么复杂。想法比结论更重要。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
