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，灰度发布 》