作者:十眠
什么是全链路灰度?
微服务系统架构中,服务之间的依靠联系错综杂乱,有时某个功能发版依靠多个服务同时晋级上线。咱们期望能够对这些服务的新版别同时进行小流量灰度验证,这就是微服务架构中特有的全链路灰度场景,经过构建从网关到整个后端服务的环境阻隔来对多个不同版别的服务进行灰度验证。
点击下方链接,检查直播教程:
yqh.aliyun.com/live/detail…
在发布过程中,咱们只需布置服务的灰度版别,流量在调用链路上流通时,由流经的网关、各个中间件以及各个微服务来辨认灰度流量,并动态转发至对应服务的灰度版别。如下图:
上图能够很好展现这种计划的作用,咱们用不同的色彩来表明不同版别的灰度流量,能够看出不管是微服务网关仍是微服务本身都需求辨认流量,根据管理规矩做出动态决策。当服务版别发生变化时,这个调用链路的转发也会实时改变。比较于使用机器搭建的灰度环境,这种计划不仅能够节约大量的机器本钱和运维人力,而且能够协助开发者实时快速的对线上流量进行精细化的全链路控制。
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:
opensergo.io/zh-cn
[2] MSE 微服务引擎:
www.aliyun.com/product/ali…
[3] 布置Demo 使用程序:
help.aliyun.com/document_de…
[4] 装备全链路灰度:
help.aliyun.com/document_de…
MSE 注册装备中心专业版首购享 9 折优惠,MSE 云原生网关预付费全规格享 9 折优惠。点击此处,即享优惠!