Istio，灰度发布从未如此轻松！！！

三个问题，回顾前情提要。

ServiceMesh 解决什么问题？

SM 本质是 业务服务与 底层技术体系的 解耦：

• 一个进程实现业务逻辑（不管是调用方，还是服务提供方）， biz，即上图白色方块

• 一个进程实现底层技术体系， proxy，即上图蓝色方块

画外音：负载均衡、监控告警、服务发现与治理、调用链… 等诸多基础设施，都放到这一层实现。

什么是 Istio？

Istio 是 ServiceMesh 的产品化落地。

Istio 的分层架构设计如何？

Istio 采用 实施与控制分离的数据平面与控制平面两层架构。

数据平面

• envoy(proxy)：负责高效转发与策略落地 [核心]

控制平面

• mixer：适配组件，数据平面与控制平面通过它交互

• pilot：策略配置组件 [核心]

• citadel：安全组件

• galley：底层平台（例如：K8S）解耦组件

整个架构的核心是 envoy 与 pilot。

今天起，聊聊 Istio 的 流控，典型如灰度发布。

就如同 ServiceMesh 的设计初衷，是技术体系与业务服务解耦一样， Istio 流控模型的本质，是流量控制与服务实例扩展的解耦，更具体的：

• 用户只需要通过控制平面中的 Pilot 设定期望流量要以什么规则进行路由

• 不需要规定服务实例 (service pods) 如何接收

• 数据平面 Envoy 将从 Pilot 中获取规则和命令，然后落地各类分流策略

如上图所示，最开始时，ServiceA 访问旧版的 ServiceB。

画外音，业务与底层解耦：

（1）灰色圆形为业务 Svc 服务；

（2）紫色六边形为 Envoy 代理；

（3）服务与代理之间都是本地访问；

（4）跨网段之间都是 Envoy 代理交互（蓝色箭头）；

如何进行灰度发布呢？

如上图所示，服务 A 调用服务 B，服务 B 要发布一个灰度版本，需要 5% 的流量打到服务 B 的新版本，只需要：

（1）部署服务 B 的新版本；

（2）控制平面 Pilot 上进行策略配置，策略同步到 Envoy；

（3）数据平面 Envoy 接收到策略配置，实时分流策略；

画外音：图形上没有画出 Pilot 和 Envoy 的交互。

搞定，这个过程 业务服务与流量控制策略完全解耦，完美！

除了基于按流量比例分流的灰度发布，基于应用层的灰度发布通过 Istio 也非常容易实现。

如上图所示，服务 B 要发布一个灰度版本，需要把 iPhone 的流量打到 B 的新版本，操作流程完全一样（部署服务，Pilot 控制，Envoy 实施），非常方便。

如果 Envoy 原来只支持按照流量比例分流，不支持基于应用层协议分流，此时只需要：

（1）升级 Envoy 的分流策略，以及策略控制端 Pilot；

（2）调用方服务 A 不需要升级；

（3）服务方服务 B 也不需要升级；

业务与底层基础设施完全解耦，完美！

画外音：这是 Service Mesh 的核心理念之一，详见《__ ServiceMesh 究竟解决什么问题》。

如果是用传统微服务框架的方式，需要框架升级，调用方与服务方均需要配合升级与重启。

最近下班都比较晚，今天先写到这里。Pilot 的分层架构如何，它又是如何与 Envoy 配合实现流控的，且听下回分解。

思路比结论重要。

调研：

大伙升级一个流控策略，业务服务要升级，要重启么？