三题，复习前情总结。ServiceMesh解决什么问题？SM的本质是业务服务与底层技术体系的解耦：一个流程实现业务逻辑（无论是调用者还是服务提供者），biz，也就是上图中的白色方块，一个流程实现底层技术体系，proxy，也就是上图中蓝色方块的画外音：负载均衡、监控告警、服务发现与治理、调用链……等等很多基础设施都在这一层实现。什么是Istio？Istio是ServiceMesh的产品化。Istio的分层架构是如何设计的？Istio采用数据平面和控制平面的两层架构，实现和控制分离。(1)Dataplane:envoy(proxy):负责高效转发和策略执行[核心](2)Controlplane:mixer:数据平面和控制平面交互的适配器组件pilot:策略配置组件[核心]citadel:安全组件厨房：底层平台（eg：K8S）解耦组件整个架构的核心是envoy和pilot。今天开始说说Istio的流控，典型的就是灰度发布。正如ServiceMesh的设计初衷是技术体系与业务服务的解耦，Istio流控模型的本质是流控与服务实例扩展的解耦。没有必要指定服务实例（服务pod）如何接收数据平面。Envoy会从Pilot获取规则和命令，然后执行各种分发策略。如上图所示，一开始，ServiceA访问的是老版本的ServiceB。画外音，业务与底层解耦：灰色圆圈为业务Svc服务；紫色六边形是Envoy代理；服务和代理都在本地访问；跨网段都是Envoy代理交互（蓝色箭头）；如何进行灰度发布？如上图所示，服务A调用服务B，服务B需要发布一个灰度版本。需要5%的流量来打新版本的服务B，只需要：部署新版本的服务B；策略配置在控制面Pilot上进行，策略同步到Envoy；数据面Envoy接收策略配置，实时分发策略；画外音：Pilot和Envoy的交互没有画在图上。大功告成，这个流程业务服务和流控策略完全解耦，完美！除了基于流量比例分布的灰度发布，基于应用层的灰度发布也很容易通过Istio实现。如上图，服务B如果要发布一个灰度版本，需要将iPhone流量转移到新版本的B，操作流程完全一样（部署服务，Pilot控制，Envoy实现），其中很方便。如果Envoy原本只支持按流量比例分流，不支持按应用层协议分流，则只需要：升级Envoy的分流策略和策略控制端Pilot；呼叫者服务A不需要升级；服务器服务B也不需要升级；业务和底层基础设施完全解耦，完美！画外音：这是ServiceMesh的核心概念之一，详见《ServiceMesh究竟解决什么问题》。如果使用传统的微服务框架，需要对框架进行升级，调用者和服务端都需要配合升级重启。最近下班比较晚，今天先写到这里。Pilot的分层架构是怎样的，它是如何配合Envoy实现流控的？且听下一章。想法比结论更重要。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
