共计 4415 个字符，预计需要花费 12 分钟才能阅读完成。
作者：十眠
什么是全链路灰度？
微服务体系架构中，服务之间的依赖关系盘根错节，有时某个性能发版依赖多个服务同时降级上线。咱们心愿能够对这些服务的新版本同时进行小流量灰度验证，这就是微服务架构中特有的全链路灰度场景，通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证。
点击下方链接，查看直播教程：
https://yqh.aliyun.com/live/d…
在公布过程中，咱们只需部署服务的灰度版本，流量在调用链路上流转时，由流经的网关、各个中间件以及各个微服务来辨认灰度流量，并动静转发至对应服务的灰度版本。如下图：
上图能够很好展现这种计划的成果，咱们用不同的色彩来示意不同版本的灰度流量，能够看出无论是微服务网关还是微服务自身都须要辨认流量，依据治理规定做出动静决策。当服务版本发生变化时，这个调用链路的转发也会实时扭转。相比于利用机器搭建的灰度环境，这种计划不仅能够节俭大量的机器老本和运维人力，而且能够帮忙开发者实时疾速的对线上流量进行精细化的全链路管制。
OpenSergo[1] 流量路由规范
Q：OpenSergo 是什么？
A：OpenSergo 是一套凋谢、通用的、面向分布式服务架构、笼罩全链路异构化生态的服务治理规范，基于业界服务治理场景与实际造成服务治理通用规范。OpenSergo 的最大特点是 以对立的一套配置 /DSL/ 协定定义服务治理规定，面向多语言异构化架构，做到全链路生态笼罩。无论微服务的语言是 Java, Go, Node.js 还是其它语言，无论是规范微服务还是 Mesh 接入，从网关到微服务，从数据库到缓存，从服务注册发现到配置，开发者都能够通过同一套 OpenSergo CRD 标准配置针对每一层进行对立的治理管控，而无需关注各框架、语言的差别点，升高异构化、全链路服务治理管控的复杂度
Q：为什么理解全链路灰度之前先给我介绍 OpenSergo？
A：OpenSergo 定义了一套对立的 YAML 配置形式来针对分布式架构进行全链路的服务治理的标准，介绍标准与规范的同时，咱们能够理解其中的技术细节的实现，同时咱们还能够将新的组件与 OpenSergo 的规范进行实现。
流量路由，顾名思义就是将具备某些属性特色的流量，路由到指定的指标。流量路由是流量治理中重要的一环，开发者能够基于流量路由规范来实现各种场景，如灰度公布、金丝雀公布、容灾路由、标签路由等。
全链路灰度示例：
流量路由规定(v1alpha1) 次要分为三局部：
- Workload 标签规定 (WorkloadLabelRule)：将某一组 workload 打上对应的标签，这一块能够了解为是为利用或者对应存储层的话就是数据库负载（数据库、表）打上对应的标签
- 流量标签规定 (TrafficLabelRule)：将具备某些属性特色的流量，打上对应的标签
- 依照 Workload 标签和流量标签来做匹配路由，将带有指定标签的流量路由到匹配的 workload 中
给流量打标：
须要将具备某些属性特色的流量，打上对应的标签。
假如当初须要将深圳地区的用户灰度到新版主页，测试用户 location=cn-shenzhen，cn-shenzhen 位于 location header 中：
apiVersion: traffic.opensergo.io/v1alpha1
kind: TrafficLabelRule
metadata:
name: my-traffic-label-rule
labels:
app: spring-cloud-zuul
spec:
selector:
app: spring-cloud-zuul
trafficLabel: gray
match:
- condition: "==" # 匹配表达式
type: header # 匹配属性类型
key: 'location' # 参数名
value: cn-shenzhen # 参数值通过上述配置，location header 为 cn-shenzhen 的 HTTP 流量，打上 gray 标，代表这个流量为灰度流量。
给 Workload 打标签：
在应用 Nacos 作为服务发现的业务零碎中，个别是须要业务依据其应用的微服务框架来决定打标形式。如果 Java 利用应用的 Spring Cloud 微服务开发框架，咱们能够为业务容器增加对应的环境变量来实现标签的增加操作。比方咱们心愿为节点增加版本灰度标，那么为业务容器增加 traffic.opensergo.io/label: gray，这样框架向 Nacos 注册该节点时会为其增加一个 gray 标签。
对于一些简单的 workload 打标场景（如数据库实例、缓存实例标签），咱们能够利用 WorkloadLabelRule CRD 进行打标。示例：
apiVersion: traffic.opensergo.io/v1alpha1
kind: WorkloadLabelRule
metadata:
name: gray-sts-label-rule
spec:
workloadLabels: ['gray']
selector:
db: mse-demo
table: mse_demo_table_gray全链路灰度在数据库上的常见计划
计划一：影子库
每个独自保护一套独立的库，假如基线环境的库的名称为 mse-demo，那么 gray 环境的流量能够映射到 mse-demo-gray 的库中，咱们在同一个实例上建设对应环境流量的影子库，咱们在业务中保护着各个库连贯的连接池，依据不同的流量标抉择对应的影子库的连贯去拜访，以此达到数据和基线环境库隔离的成果，从而防止了灰度环境流量产生的数据对基线环境库造成净化。
计划二：影子表
相似影子库计划，针对影子表计划，是在同一个实例上的同一个数据库上建设对应的影子表。咱们在执行 SQL 的过程中，对灰度流量的 SQL 进行解析与批改，实现不同环境流量的 SQL 别离拜访对应的表，假如基线环境的表的名称为 mse_demo_table，那么 gray 环境的流量能够映射到 mse_demo_table_gray 的表中。从而实现灰度数据和基线环境数据表隔离的成果。
MSE[2] 数据库全链路灰度能力
MSE 提供了一种数据隔离的计划，您能够在不须要批改任何业务代码的状况下，实现数据库层面全链路灰度。上面介绍 MSE 基于 Mysql 数据存储通过影子表的计划实现全链路灰度的能力。
前提条件
- 利用接入 MSE
- 部署 Demo 利用
在阿里云容器服务中部署 A、B、C 三个利用，每个利用别离部署⼀个 base 版本和⼀个 gray 版本；并部署⼀个 Nacos Server 利用，用于实现服务发现。具体可参考教程实现利用部署：部署 Demo 应用程序 [3 ]。
Demo 利用介绍，本 Demo 中的 C 利用会向数据库执行如下语句：
CREATE TABLE `mse_demo_table` (
`id` int NOT NULL AUTO_INCREMENT,
`location` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb3其中波及到的数据库建表语句：
CREATE TABLE `mse_demo_table` (
`id` int NOT NULL AUTO_INCREMENT,
`location` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb3- 创立影子表，咱们 Demo 波及到的数据库表有 mse_demo_table，因为咱们须要创立灰度 gray 环境，因而咱们须要提前创立 mse_demo_table_gray 表。
CREATE TABLE `mse_demo_table_gray` (
`id` int NOT NULL AUTO_INCREMENT,
`location` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb3
;第一步：配置全链路灰度规定
您须要配置实现 MSE 的全链路公布，具体操作细节可参考教程：配置全链路灰度 [ 4]。
创立如下泳道规定：
第二步：配置数据库全链路灰度
- 咱们须要配置以下环境变量来额定开启 / 配置数据库的全链路灰度能力
第三步：后果验证
咱们发动灰度申请，发现流量申请均拜访灰度环境：
curl -H "location: cn-shenzhen" http://106.14.XX.XX/a
Agray[172.18.XX.XX] -> Bgray[172.18.XX.XX] -> Cgray[172.18.XX.XX]%咱们通过如下 SQL 查问影子表：
SELECT * FROM `mse_demo_table_gray`发现灰度环境的数据都插入至影子表。
不仅仅是全链路灰度
目前为止 MSE 服务治理全链路灰度能力曾经反对了云原生网关、ALB、APISIX、Apache Dubbo、Spring Cloud、RocketMQ 以及数据库。在数据库层面咱们通过影子表的形式实现了数据层面的流量隔离，下一步咱们会将该能力进行进一步产品化，全链路灰度也会反对缓存层面的能力。
服务治理是微服务革新深刻到肯定阶段之后的必经之路，在这个过程中咱们一直有新的问题呈现。
- 除了全链路灰度，服务治理还有没其余能力？
- 服务治理能力有没一个规范的定义，服务治理能力蕴含哪些？
- 多语言场景下，有无全链路的最佳实际或者规范？
- 异构微服务如何能够对立治理？
当咱们在摸索服务治理的过程中，咱们在对接其余微服务的时候，咱们发现治理体系不同造成的困扰是微小的，买通两套甚者是多套治理体系的老本也是微小的。为此咱们提出了 OpenSergo 我的项目。OpenSergo 要解决的是不同框架、不同语言在微服务治理上的概念碎片化、无奈互通的问题。
OpenSergo 社区也在联结各个社区进行进一步的单干，社区来一起探讨与定义对立的服务治理规范。以后社区也在联结 bilibili、字节跳动等企业一起共建规范，也欢送感兴趣的开发者、社区与企业一起退出到 OpenSergo 服务治理规范共建中。欢送大家退出 OpenSergo 社区交换群（钉钉群）进行探讨：34826335
参考链接：
[1] OpenSergo：
https://opensergo.io/zh-cn
[2] MSE 微服务引擎：
https://www.aliyun.com/produc…
[3] 部署 Demo 应用程序：
https://help.aliyun.com/docum…
[4] 配置全链路灰度：
https://help.aliyun.com/docum…
MSE 注册配置核心专业版首购享 9 折优惠，MSE 云原生网关预付费全规格享 9 折优惠。点击此处，即享优惠！
