共计 3615 个字符,预计需要花费 10 分钟才能阅读完成。
作者:卜比
什么是全链路灰度
微服务体系架构中,服务之间的依赖关系盘根错节,有时某个性能发版依赖多个服务同时降级上线。咱们心愿能够对这些服务的新版本同时进行小流量灰度验证,这就是微服务架构中特有的全链路灰度场景,通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证。
在公布过程中,咱们只需部署服务的灰度版本,流量在调用链路上流转时,由流经的网关、各个中间件以及各个微服务来辨认灰度流量,并动静转发至对应服务的灰度版本。如下图:
上图能够很好展现这种计划的成果,咱们用不同的色彩来示意不同版本的灰度流量,能够看出无论是微服务网关还是微服务自身都须要辨认流量,依据治理规定做出动静决策。当服务版本发生变化时,这个调用链路的转发也会实时扭转。相比于利用机器搭建的灰度环境,这种计划不仅能够节俭大量的机器老本和运维人力,而且能够帮忙开发者实时疾速的对线上流量进行精细化的全链路管制。
基本概念
- 泳道:一条虚构的流量门路,比方上图中标签 1 的流量,就属于一个泳道
- 基线环境:承载所有流量,比方某个服务,没有标签 1 节点,那么就会回退到基线环境
- 流量回退:某个服务,没有标签 1 节点,那么就会回退到基线环境,这个行为叫流量回退
- 泳道组:为便于了解,流量波及利用以及其泳道,称为泳道组。
全链路灰度的利用场景
日常 / 开发 / 我的项目 / 测试环境隔离
结构日常、开发、我的项目、测试等多套环境的“泳道”,每个我的项目环境都有惟一的一个我的项目标签,流量带上这个我的项目标签后会路由到该我的项目环境,否则会去骨干环境。如果没有这套机制,开发环境要进行物理隔离,这就须要部署整套微服务架构,老本十分高。
全链路灰度公布
线上所有利用部署灰度版本,灰度流量全副进入灰度版本,失常流量进入生产版本。灰度版本只针对灰度流量验证,无效缩小危险。云上客户安 x 就有这样的场景,要灰度公布 N 个利用,想灰度流量在这 N 个利用的灰度版本之间路由。
高可用 / 邻近路由
业务高可用部署后,服务调用如果跨机房,会带来额定的调用提早。开启同机房优先路由后,让 Consumer 服务调用优先选择雷同机房的 Provider,升高 rt。
全链路压测
间接应用线上环境压测,让压测流量的 DB 操作落库到影子表,Redis 落到影子 KEY,MQ 落到影子 TOPIC。如果没有路由能力,须要搭建一套仿真的线上环境用于压测,老本直线回升。用线上环境配合流量控制能力能够实现 0 机器老本,0 保护老本实现全链路压测。
波及技术
那么全链路灰度具体是如何实现呢?咱们须要解决以下问题:
1. 链路上各个组件和服务可能依据申请流量特色进行动静路由(标签路由)
2. 须要对服务下的所有节点依照标签分组,可能辨别版本(节点打标)
3. 须要对流量进行灰度标识、版本标识,并向下传递(标签传递)
- 除了对 RPC/HTTP 调用须要依照标签灰度,对 DB、音讯、分布式工作也须要依照标签灰度(音讯灰度、数据库灰度)
标签路由
在云原生环境下,因为节点的生命周期缩短,IP 变动,导致原来依照 IP 来设置路由规定的形式不再实用。所以, 标签是云原生环境下的一等公民。
不管节点、流量、还是音讯,都不再通过 IP、节点来标记,运维开发同学只须要关注标签就能够。
在不同的上下文中,有不同的标签值,能够带来不同的业务场景。
比方当标签值是可用区的时候,就能够实现邻近路由;当标签值是版本的时候,就能够据此实现金丝雀公布、全链路灰度等。
节点打标
在云原生环境下,尤其是典型的 K8s 部署模式下,咱们能够通过 labels 来给一组 pod/workload 打标,这样就能通过标签来标记、查找节点。比方 K8s 的 service 就依赖了 label;阿里云微服务引擎(MSE)也应用 label alicloud.service.tag 来设置节点标签。
当然,业务上必定也有一些利用不是 K8s 部署的,所以节点打标也须要反对非 K8s 环境。
在非 K8s 环境中,能够通过环境变量、零碎参数、文件等形式标记节点的标签,而后把这些标签注册到注册核心,consumer 在调用的时候,能够依据这些标签来实现路由逻辑。
标签传递
在整个的微服务调用中,咱们心愿流量上的标可能始终传递上来,其一是回溯流量起源,其二是能够在任意节点上根据流量做灰度。
在 OpenTelemetry 之前,能够通过自定义 Header 来实现流量标签透传,比方 MSE 就应用了 x-mse-tag header。
OpenTelemetry 引入了 Baggage 概念,能够通过规范形式来增加 Header。
上述两种技术,都实现了流量标签的传递。
音讯灰度、数据库灰度
比方在上图中,以 RocketMQ 为例,C 利用生产音讯,A 利用生产音讯,那么如何做到 C 利用的 gray 节点的音讯,只能被 A 利用的 gray 节点生产。
首先, 要给音讯打标 。gray 节点生产的音讯,能够通过 userProperty 个性,增加额定 property 来给音讯打标。
其次, 要依照标签生产音讯 。gray 节点生产音讯的时候,能够通过 SQL92 Filter 个性,只筛选特定标签的音讯。
应用 Shenyu 网关,实现全链路灰度
部署 Apache Shenyu 网关
Apache Shenyu 网关分为 shenyu-admin(用于规定管控)和 shenyu-bootstrap(用于解决流量)。
- 依照 Apache Shenyu 的阐明文档 [ 1],顺次创立 shenyu 命名空间、shenyu-cm ConfigMap。
- 依照 Apache Shenyu 阐明文档,顺次创立 shenyu-admin-svc Service 和 shenyu-admin Deployment。
- 因为咱们须要再装置 Spring Cloud 插件,所以采纳手动部署模式:
- 创立 spring-boot 我的项目,名字叫 shenyu-bootstrap [ 2],增加 shenyu-spring-boot-starter-plugin-springcloud 等相干依赖。
- 在 application.yaml 中配置,shenyu.sync.websocket.urls 为 ws://shenyu-admin-svc:9095/websocket,接管 shenyu-admin 的配置。
- 拜访 shenyu-admin,关上 Spring Cloud 插件。
部署微服务 demo
mse-simple-demo 分为 A、B、C 三个利用,顺次调用各自目录下的 build.sh 构建镜像。
而后创立 values.example.yaml,在其中配置好镜像地址、注册核心地址后,执行 helm 命令装置部署:
helm3 upgrade mse-simple-demo1 helm/mse-simple-demo \
--namespace shenyu --create-namespace \
--install \
--values helm/mse-simple-demo/values.example.yaml
依照 demo 部署好后,能够在 shenyu-admin 上,看到 sc-A 曾经注册到网关了:
此时默认没有任何流量规定,A->B->C 调用链路默认都走基线环境:
设置规定
首先,创立 shenyu-demo 泳道组,抉择 shenyu-bootstrap 作为流量入口,A、B、C 作为泳道组利用。
接下来配置规定,例如有参数 name=xiaoming 的,咱们认为是灰度流量,走 gray 标签的泳道:
验证
而后咱们拜访网关,带上 name=xiaoming,发现 A 利用和 B 利用都走到了 gray 节点,C 利用因为没有 gray 节点,走到了基线节点:
OpenSergo 开源微服务治理规范
随着微服务架构的遍及,微服务治理的概念也越来越被更多人认知,微服务治理的标准化、治理数据面的多样性、多语言反对等也越来越迫切。
咱们察看到了这个趋势,发动了 OpenSergo [ 3] 我的项目,致力于制订微服务治理的规范及参考实现。
其中,全链路灰度作为根本能力,目前 OpenSergo 也在制订相干规范,包含如何给机器打标、给流量打标、如何路由等。
总结
MSE 全链路灰度能力,提供了全链路隔离流量泳道能力,企业和开发这能够通过全链路灰度能力,提供端到端的稳固基线环境、流量一键动静切流、全链路的可观测能力。
此外,MSE 微服务治理具备无倾入接入能力,基于 Java Agent 技术,实现无需批改一行业务代码就能接入。具备无损高低线能力,使得业务公布更加丝滑。
接下来,MSE 全链路灰度,将会反对更多基础设施(数据库、音讯等),反对更多语言、更多接入模式,为企业和开发者晋升开发、运维效率。
相干链接
[ 1] Apache Shenyu 的阐明文档:
https://shenyu.apache.org/zh/…
[2] shenyu-bootstrap 的源码链接:
https://github.com/aliyun/ali…
[3] OpenSergo:
https://github.com/opensergo/…