三个问题，回顾前情提要。
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 配合实现流控的，且听下回分解。
思路比结论重要。
调研：
大伙升级一个流控策略，业务服务要升级，要重启么？
