三个问题，回顾一下之前的情况。
ServiceMesh解决了什么问题？
SM的本质是业务服务与底层技术体系的解耦：
画外音：负载均衡、监控与报警、服务发现与治理、调用链等很多基础设施都是在这一层实现的。
Istio 是什么？
Istio是ServiceMesh的产品实现。
Istio的分层架构设计是怎样的？
Istio采用数据平面和控制平面的两层架构，实现和控制分离。
数据平面
控制平面
整个架构的核心是envoy和pilot。
今天开始我们来聊聊Istio的流量控制，一个典型的例子就是灰度发布。
正如 ServiceMesh 的初衷是将技术体系与业务服务解耦一样，Istio 流控模型的本质也是将流量控制与服务实例扩展解耦。更具体地说：
如上图，一开始，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的核心概念之一，具体内容见“。”。
如果采用传统的微服务框架，框架需要升级，需要调用方和服务提供方双方配合进行升级重启。
最近要下班了，今天就先写到这里，下次再和大家讨论 Pilot 的分层架构以及如何和 Envoy 配合实现流量控制。
想法比结论更重要。
