什么是全链接灰度？在微服务架构中，服务之间的依赖关系错综复杂，有时一个功能的发布依赖于多个服务同时升级上线。我们希望这些服务的新版本能够同时在小流量灰度上进行验证。这是微服务架构中独有的全链路灰度场景。通过构建从网关到整个后端服务的环境隔离，可以验证多个不同的版本。灰度验证服务。查看直播教程：https://yqh.aliyun.com/live/detail/29004在发布过程中，我们只需要部署灰度版本的服务即可。当流量在调用链路上流动时，流经的网关、各个中间件、各个微服务识别灰度流量，动态转发到对应服务的灰度版本。如下图所示：上图可以很好的展示这个方案的效果。我们使用不同的颜色来表示不同版本的灰度流量。可以看出，无论是微服务网关还是微服务本身，都需要对流量进行识别，并按照治理规则进行。做出动态决策。当服务版本发生变化时，该调用链接的转发也会实时变化。与机器搭建的灰度环境相比，该方案不仅可以节省大量的机器成本和运维人力，还可以帮助开发者实时快速地对线上流量进行细粒度的全链路管控。OpenSergo[1]流量路由标准问：OpenSergo是什么？A：OpenSergo是一套开放的、通用的、面向分布式服务架构的服务治理标准，覆盖全链路异构生态。它基于行业服务治理场景和实践，形成了服务治理的通用标准。OpenSergo最大的特点是以一套统一的配置/DSL/协议定义服务治理规则，面向多语言异构架构，实现全链路生态覆盖。无论微服务的语言是Java、Go、Node.js还是其他语言，无论是标准微服务还是Mesh接入，从网关到微服务，从数据库到缓存，从服务注册发现到配置，开发者都可以使用同一套OpenSergoCRD标准配置对每一层进行统一治理和控制，不关注框架和语言的差异，降低异构化和全链路服务治理和控制的复杂度问：为什么理解全链路灰度介绍我先到OpenSergo？A：OpenSergo为分布式架构的全链路服务治理规范定义了一套统一的YAML配置方式。在介绍规范和标准的同时，我们可以了解技术细节的实现，也可以将新的组件用OpenSergo标准实现。流量路由，顾名思义，就是将具有一定属性特征的流量路由到指定的目标。流量路由是流量治理的重要组成部分。开发者可以基于流量路由标准实现各种场景，如金丝雀发布、金丝雀发布、容灾路由、标签路由等。全链路灰度示例：流量路由规则（v1alpha1）主要分为三部分：工作负载标签规则（WorkloadLabelRule）：给某组工作负载打上相应的标签，可以理解为应用层或相应的存储层。用相应的标签标注数据库负载（数据库、表）。流量标签规则（TrafficLabelRule）：根据用于匹配路由的Workload标签和流量标签，给流量打上一定的属性和特征，并根据指定的标签对流量进行路由标记匹配工作负载中的流量：需要标记的流量具有一定属性和特征的带有相应的标签。假设深圳地区用户需要灰度到新首页，测试用户locatinotallow=cn-shenzhen，cn-shenzhen位于locationheader:apiVersion:traffic.opensergo.io/v1alpha1kind:TrafficLabelRulemetadata:name:my-traffic-label-rulelabels:app:spring-cloud-zuulspec:selector:app:spring-cloud-zuultrafficLabel:graymatch:-condition:"=="#匹配表达式类型:header#匹配属性类型key:'location'#parameterNamevalue:cn-shenzhen#Parametervalue通过上面的配置，locationheader是cn-shenzhen的HTTP流量，用灰色标记，表示该流量为灰度流量。标记工作负载：在使用Nacos作为服务发现的业务系统中，一般需要业务根据自己使用的微服务框架来决定标记方式。如果Java应用使用了SpringCloud微服务开发框架，我们可以在业务容器中添加相应的环境变量来完成标签的添加操作。比如我们要给节点添加版本灰度标签，那么在业务容器中添加http://traffic.opensergo.io/label:gray，这样框架在向Nacos注册节点时，会添加一个灰色的标签。对于一些复杂的工作负载标注场景（比如数据库实例、缓存实例标签），我们可以使用WorkloadLabelRuleCRD进行标注。例子：apiVersion:traffic.opensergo.io/v1alpha1kind:WorkloadLabelRulemetadata:name:gray-sts-label-rulespec:workloadLabels:['gray']selector:db:mse-demotable:mse_demo_table_grayfulllinkgrayscaleonthedatabase常见方案一：每个影子库都维护着一套独立的库。假设基线环境下的库名为mse-demo，那么灰色环境下的流量可以映射到mse-demo-gray的库上。我们在同一个实例上创建对应环境流量的影子库。我们在业务中维护每个库连接的连接池，根据不同的流量指标选择对应的影子库连接访问，从而达到与基线环境库数据隔离的效果。这样可以避免灰度环境流产生的数据污染基线环境数据库。方案二：影子表与影子库方案类似。对于影子表方案，对应的影子表是在同一个实例的同一个数据库上创建的。在执行SQL的过程中，我们对灰色流量的SQL进行分析修改，使得不同环境流量的SQL可以分别访问对应的表。假设baseline环境的表名为mse_demo_table，那么灰色环境的流量可以映射到表中的mse_demo_table_gray。从而达到将灰度数据与基线环境数据表隔离的效果。MSE[2]数据库全链路灰度能力MSE提供数据隔离方案，无需修改任何业务代码，即可实现数据库层面的全链路灰度。下面介绍MSE基于Mysql数据存储通过影子表方案实现全链路灰度的能力。先决条件应用程序已连接到MSE以部署演示应用程序。在阿里云容器服务中部署三个应用A、B、C。每个应用部署一个基础版本和一个灰色版本；并部署一个NacosServer应用来实现服务发现。详情请参考完成应用部署教程：DeployingDemoApplications[3]。Demo应用介绍，本Demo中的C应用会对数据库执行如下语句：CREATETABLE`mse_demo_table`(`id`intNOTNULLAUTO_INCREMENT,`location`varchar(255)DEFAULTNULL,PRIMARYKEY(`id`))ENGINE=InnoDBAUTO_INCREMENT=3DEFAULTCHARSET=utf8mb3涉及的建表语句：CREATETABLE`mse_demo_table`(`id`intNOTNULLAUTO_INCREMENT,`location`varchar(255)DEFAULTNULL,PRIMARYKEY(`id`))ENGINE=InnoDBAUTO_INCREMENT=3DEFAULTCHARSET=utf8mb3创建影子表。我们Demo中涉及到的数据库表是mse_demo_table，因为我们需要创建灰度灰色环境，所以需要提前创建mse_demo_table_gray表。CREATETABLE`mse_demo_table_gray`(`id`intNOTNULLAUTO_INCREMENT,`location`varchar(255)DEFAULTNULL,PRIMARYKEY(`id`))ENGINE=InnoDBAUTO_INCREMENT=3DEFAULTCHARSET=utf8mb3;第一步：配置全链条道路灰度规则需要配置MSE的全链条发布。具体操作详见教程：配置全链路灰度[4]。创建如下通道规则：步骤2：配置数据库全链路灰度。我们需要配置以下环境变量来额外启用/配置数据库的全链路灰度能力。第3步：验证结果。我们发起灰度请求，发现流量请求都访问灰度环境：curl-H"location:cn-shenzhen"http://106.14.XX.XX/aAgray[172.18.XX.XX]->Bgray[172.18.XX.XX]->Cgray[172.18.XX.XX]%我们通过如下SQL查询影子表：SELECT*FROM`mse_demo_table_gray`发现灰度环境下的数据插入到影子表中。不只是全链路灰度目前，MSE服务治理的全链路灰度能力已经支持云原生网关、ALB、APISIX、ApacheDubbo、SpringCloud、RocketMQ、数据库。在数据库层面，我们通过影子表实现了数据层面的流量隔离。下一步，我们会将这个能力进一步产品化，全链路灰度也会支持缓存层面的能力。服务治理是微服务转型深入到一定阶段的必由之路。在这个过程中，我们不断遇到新的问题。除了全链路灰度，服务治理还有其他能力吗？服务治理能力有没有标准的定义，服务治理能力包括什么？在多语言场景下，全链接是否有最佳实践或标准？如何统一管理异构微服务？我们在探索服务治理的时候，在对接其他微服务的时候，发现不同的治理体系带来的麻烦是巨大的，打通两个甚至多个治理体系的代价是巨大的。为此，我们提出了OpenSergo项目。OpenSergo需要解决的是微服务治理在不同框架和语言中的概念碎片化和不兼容问题。
