No.184# 蓝绿发布实践回顾-技术圈

缘起

随着蓝绿发布项目落地进入试运行，也对蓝绿发布项目做个简要回顾。早在2022年初的时候效能、交易和中间件的同学就如何提高发布效率做过讨论，蓝绿发布当时也被提出。由于彼时有更重要的事情去落地，蓝绿发布也被搁置未能成行。随着染色环境项目的落地，推进接入工作的基本完成。测试开发环境存在的众多问题（多套环境、运维问题、环境冲突、沟通问题）基本得到根治。测试环境得到根治的同时，生产环境自然就成为接下来的重点。大版本发布时长达7个小时，的确是大家的痛点，我们也希望从根本上提高发布效率。本文主要内容有：

应用发布诉求
发布方案对比
蓝绿发布流程
蓝绿流量调度
组件能力支持

应用发布诉求 微服务应用发布时有以下诉求：

上下游依赖：本服务的发布依赖其他服务，要别的服务先发布才行
小流量灰度：发布时先小流量灰度验证、避免问题被放大
按批次发布：支持节点批次划分、按批次发布

其中上下游依赖问题最为突出，为解决依赖问题需提前填写发布计划，将应用组织成梯队来规避上下游依赖问题。

填写发布计划较为繁琐：每次发布需要去组织填写、比较繁琐
必须按照梯队顺序发布：一个梯队发完才能发布另一个梯队、需要互相等待
应用回滚稳定性需提升：一个应用验证有问题，需要依赖上游联动回滚，回滚过程中有生产流量、稳定性存在优化空间

由此可见，应用发布的痛点聚焦到了破除上下游上，自然解决方案也以此为中心。

发布方案对比

发布方式	基本原理	常见实现
灰度发布	小流量验证	方式一：金丝雀发布，发布时先拉入一台验证，正常后发布剩余节点方式二：流量染色灰度，通过对请求流量染色选择到特定的节点实现灰度方式三：独立灰度环境，上线前先在该环境验证（例如：小得物环境）
滚动发布	分批次发布	在灰度验证的基础上，通过发布系统选择发布批次方式一：按节点比例分批发布方式二：按节点数量分批发布
蓝绿发布	流量调度实现	线上同时蓝绿两个应用组提供服务步骤一：新版本发布时先将流量从蓝色集群A调度到绿色集群B，绿色集群B独立承担流量步骤二：在蓝色集群A发布新版本，从小到大逐步引流到蓝色集群步骤三：蓝色验证正常均衡蓝绿两套流量，异常流量调度走即可
红黑发布	弹性扩缩容、流量调度	线上只运行一个红色集群步骤一：发布时先扩容黑色集群，该集群发布新版本步骤二：在黑色集群发布新版本，按比例引流验证步骤三：一切正常后，流量调度到黑色集群，红色集群下线

熟悉中间件运维的同学怎么运维才是安全的呢？先摘流、运维变更、再逐步引流。

这种方式应用到应用发布系统，即为蓝绿发布。

在生产环境发布时，我们通常有两个版本，线上运行的版本、待发布的版本。

也就是在生产环境区分流量只需要两个颜色即可，蓝绿发布通过两个染色流量来区分线上运行版本和待发布版本。

此外，希望在大版本发布与日常迭代中都能使用蓝绿发布来提效，作为核心应用的首选发布方式。

蓝绿发布流程 在发布系统中集成蓝绿发布，与普通发布有何区别，蓝绿发布流程是怎么样的呢？

3.1 蓝绿架构图示

线上的资源容量需能够容纳业务增量的2倍以上，将线上的运行的服务节点资源一分为二，分成蓝色环境和绿色环境。

3.2 蓝绿发布流程

为了避免混淆将蓝绿环境固定，先部署待发布新版本的环境固定为「蓝色环境」，后部署待发布新版本的环境固定为「绿色环境」，应用发布先发「蓝色环境」，后发「绿色环境」。

发布流程梳理如下：

将蓝色集群摘流，此时流量被染绿进入绿色集群
系统发布时先经过「蓝色环境」，后发布「绿色环境」
应用上下游服务在「蓝色环境」集中完成部署
引入1%流量蓝色流量验证
「蓝色环境」上下游服务验证「不符合预期」，流量切换到绿色环境
「蓝色环境」完成验证「符合预期」，全部流量染成蓝色，流量调度到了蓝色环境
此时绿色环境已无流量，新版本在绿色环境集中完成部署
通过递进式引流到绿色环境【1%~50%】
最后呈现的流量分布，蓝绿流量各50%

纵观整个发布流程，需要众多部门和组件的联动配合才能完成，下到容器、上到网关，中间贯穿众多核心中间件。

蓝绿流量调度

在设计流量调度时分为全局流量调度与局部流量调度，分别应对不同的发布场景。

全局流量调度（单通道发布）：所有蓝绿环境的应用都参与流量调度，适用一次发布上百个应用场景、上下游关系难以梳理。

局部流量调度（多通道发布）：适用于已知应用依赖发布、日常迭代。

在已知应用依赖的情况下，通过局部流量调度即可满足需求。

4.1 全局流量调度

上面提到「全局流量单通道」在蓝绿环境的服务均会参与调度，流量调度变更涉及全部在蓝绿环境的应用，下面以流量全部调度蓝色环境为例观测各个组件的行为。

伴随着绿色环境被摘流，流量全部在蓝色环境运行。

RPC选择本环境对应节点、并提供兜底选择策略
绿色环境应用消息组被下线摘除消费流量、同时在蓝色环境唤醒绿色消费组接管流量
配置中心应用只访问对应蓝绿环境的配置集
分布式调度此时只调度到蓝色环境

4.2 局部流量调度

「局部流量多通道」的流量调度比例，由各通道进行自行管控。如下图所示：

全局流量单通道：蓝绿切流比例 50%:50%
局部流量多通道1 ：蓝绿切流比例 5%:95%
局部流量多通道2 ：蓝绿切流比例 0%:100%
局部流量多通道3 ：蓝绿切流比例 70%:30%

需要注意的是

一个应用只允许在一个发布通道发布，避免流量冲突和干扰
当「全局流量单通道」发布与「局部流量多通道」同时发布时
- 以「局部流量多通道」比例为准
- 「局部流量多通道」发布结束后，会被「全局流量单通道」流量比例接管

4.3 调度实现原理

无论是「全局流量单通道」调度还是「局部流量多通道」调度，实现原理都是一样的，下面以RPC调用为例说明，如下图所示。

工作原理简述如下：

@1 由发布系统即将【通道标识、包含的应用列表、切流比例】写入元数据中心
@2 「局部流量多通道」中的应用收到蓝绿比例。例如：图示中应用A收到自身所属通道的蓝绿流量比例
@3 「局部流量多通道」中的应用将自身的蓝绿比例写入注册中心。例如：应用A将自身蓝绿流量比例写入注册中心
@4 调用应用A的【所有上游应用】通过注册中心均收到应该调用A的蓝绿流量比例。例如：应用B、应用C、应用D均收到应该调用应用A的蓝绿比例
@5 上游应用按流量比例向下游服务发起调用

从流量调度和实现原理来看，流量的调度会与RPC、消费组、分布式调度、发布系统、配置中心、注册中心一起联动。需要把存在的流量出口（例如：网关、消息、分布式调度等）流量管控起来。

组件能力支持

上文中提到流量的调度涉及到众多组件联动与协同，那各个组件需要提供哪些能力呢？下面介绍下这些组件需提供的能力。

5.1 容器逻辑分组

蓝绿发布离不开容器的逻辑分组，应用使用蓝绿发布之前，需要将应用的机器实例分布到蓝绿环境中去。容器需要具备的能力如下：

提供应用蓝绿逻辑分组
蓝绿标识植入环境变量
应用分组发布系统可见

如下图所示，应用通过容器分组，分布到蓝绿集群。

5.2 发布系统支持

发布系统是整个蓝绿发布的入口，用户直接感受的系统。对下与容器交互、对上与元数据中心交互。

提供蓝绿发布多通道能力，将本次发布关联应用拉入同一发布通道
提供蓝绿发布流水线、流量调操作
根据容器平台提供的逻辑分组接口、指定蓝绿集群发布
将通道信息、应用列表、流量调度信息写入元数据中心，供中间件感知

如下图所示，将整个蓝绿发布形成流水线。

5.3 统一框架支持

统一框架包含流量调度SDK、与注册中心和配置中心交互，联动整个RPC、Feign/HTTP流量调度。

优先根据蓝绿标，选择本环境节点调用
根据权重路由策略选择下游节点
提供兜底策略，避免无节点可选

节点选择示意图如下：

如下图所示，框架会将蓝绿环境信息与权重在注册中心注册。

5.4 消息组件支持

消息组件根据流量调度SDK的回调，需要将消费流量摘除和激活。

逻辑实现约定如下：

蓝绿环境各使用三个消费组 melon-consumer、BLUE-melon-consumer、GREEN-melon-consumer
消费组melon-consumer用于消费无（蓝绿）标识的流量，蓝绿标识会在每条消息属性中存储
消费组__BLUE-melon-consumer用于消费「蓝色」标识流量
消费组__GREEN-melon-consumer用于消费「绿色」标识流量

蓝绿两个环境均有流量：

绿色环境melon-consumer 、_GREEN-melon-consumer参与消费；BLUE-melon-consumer下线不参与消费
蓝色环境melon-consumer 、_BLUE-melon-consumer参与消费，GREEN-melon-consumer下线不参与消费

只有绿色环境有流量时：

绿色环境melon-consumer、_GREEN-melon-consumer参与消费，BLUE-melon-consumer被动态唤醒参与消费，未被消费完的蓝色流量被接管
蓝色环境GREEN-melon-consumer、BLUE-melon-consumer、melon-consumer均被动态下线，不参与消费

只有蓝色环境有流量时：

绿色环境_GREEN-melon-consumer、BLUE-melon-consumer、melon-consumer均被动态下线，不参与消费
蓝色环境_GREEN-melon-consumer、BLUE-melon-consumer、melon-consumer均参与消费，其中__GREEN-melon-consumer被动态唤醒，接管未被消费的绿色流量

如下图所示，蓝绿消费组消费各自对应的消息：