什么是全链路灰度
微服务体系架构中,服务之间的依赖关系错综复杂,有时某个功能发版依赖多个服务同时升级上线。我们希望可以对这些服务的新版本同时进行小流量灰度验证,这就是微服务架构中特有的全链路灰度场景,通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证。
在发布过程中,我们只需部署服务的灰度版本,流量在调用链路上流转时,由流经的网关、各个中间件以及各个微服务来识别灰度流量,并动态转发至对应服务的灰度版本。如下图:
上图可以很好展示这种方案的效果,我们用不同的颜色来表示不同版本的灰度流量,可以看出无论是微服务网关还是微服务本身都需要识别流量,根据治理规则做出动态决策。当服务版本发生变化时,这个调用链路的转发也会实时改变。相比于利用机器搭建的灰度环境,这种方案不仅可以节省大量的机器成本和我们希望可以对这些服务的新版本同时进行小流量灰度验证,这就是微服务架构中特有的全链路灰度场景,通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证。运维人力,而且可以帮助开发者实时快速的对线上流量进行精细化的全链路控制。
基本概念
- 泳道:一条虚拟的流量路径,比如上图中标签 1 的流量,就属于一个泳道
- 基线环境:承载所有流量,比如某个服务,没有标签 1 节点,那么就会回退到基线环境
- 流量回退:某个服务,没有标签 1 节点,那么就会回退到基线环境,这个行为叫流量回退
- 泳道组:为便于理解,流量涉及应用以及其泳道,称为泳道组。
全链路灰度的应用场景
日常/开发/项目/测试环境隔离
构造日常、开发、项目、测试等多套环境的“泳道”,每个项目环境都有唯一的一个项目标签,流量带上这个项目标签后会路由到该项目环境,否则会去主干环境。如果没有这套机制,开发环境要进行物理隔离,这就需要部署整套微服务架构,成本非常高。
全链路灰度发布
线上所有应用部署灰度版本,灰度流量全部进入灰度版本,正常流量进入生产版本。灰度版本只针对灰度流量验证,有效减少风险。云上客户安 x 就有这样的场景,要灰度发布 N 个应用,想灰度流量在这 N 个应用的灰度版本之间路由。
高可用/临近路由
业务高可用部署后,服务调用如果跨机房,会带来额外的调用延迟。开启同机房优先路由后, 让 Consumer 服务调用优先选择相同机房的 Pr