ServiceMesh解决什么问题？
SM本质是 业务服务 与 底层技术体系 的 解耦 ：
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也不需要升级；
业务与底层基础设施完全解耦 ，完美！