前情提要：
《ServiceMesh 究竟解决什么问题》
《Istio 究竟是什么？》
《Istio 分层架构设计？》
Istio 架构体系中，流控 (Traffic Management) 虽然是数据平面的 Envoy Proxy 实施的，但整个架构的核心其实在于控制平面的 Pilot。
灰度发布的过程在《Istio，灰度发布》一文中已经有过描述，今天重点说说 Pilot 和 Envoy 的交互流程与内部结构。
一、通用交互流程
图示：
-
灰色圆形，为业务服务
-
紫色六边形，为 Envoy 代理
二者相生相伴。
起初，上游调用方 ServiceA 访问下游服务提供方 ServiceB 的 V1 版本，在 ServiceB 的 V2 版本部署好之后，调用方如何知道 “SvcA 切分 1% 的流量至 SvcB 的 V2 版本” 这个指令的呢？
整个过程主要分为三大步骤：
（1）用户在控制平面的后台，通过 Pilot 的 API，修改 A 到 B 的路由策略（标号 1）；
（2）Pilot 将路由策略固化存储，以便未来新注册的调用方 A 能够知道当前最新的路由策略；对于已经存在的调用方 A，Pilot 则通过主动通知的方式告之调用方 A 对应的 Envoy（标号 2）；
（3）Envoy 作为数据平面，实施最新的路由策略（标号 3），在本例中，即将 1% 的流量导给灰度版本 Bv2；
二、服务发现与负载均衡
讲了通用的流控策略实施通用流程，而服务发现与负载均衡，只是一个种策略实施的特例：
（1）提供服务的 SvcB 新增一个 Pod（标号 1）；
（2）在 Pilot 后台修改 SvcB 的集群配置（标号 2）；
（3）Pilot 将 SvcB 的最新信息同步给该配置的订阅方（标号 3），即 SvcB 的调用方 SvcA 对应的 Proxy；
（4）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 它的内部结构并不复杂：
（1）Pilot 的核心，是各种流控策略的维护，Abstract Model；
（2）必然，Pilot 需要提供接口给用户，增删查改这些策略，Rules API；
（3）一方面，Pilot 需要保持各类底层基础设施的兼容性，Platform Adapter；
（4）另一方面，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 并没有大家想的复杂。
思路比结论重要。
架构师之路 - 分享技术思路
