Istio流控，服务发现，负载均衡，核心流程是如何实现的？

前情提要：

《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并没有大家想的复杂。

思路比结论重要。

架构师之路-分享技术思路
相关文章：
《ServiceMesh究竟解决什么问题？》
《Istio究竟是什么？》
《Istio分层架构设计？》
《Istio，灰度发布》

标签：标号,负载,服务,流控,SvcB,Istio,Proxy,Pilot
来源： https://blog.51cto.com/jyjstack/2548726