RocketMQ 全链路灰度探索与实践

本文作者：肖京，Spring Cloud Alibaba PMC，阿里云智能技术专家。

01 全链路灰度背景介绍

发布新版本时，为了有效、谨慎地验证新版本代码逻辑的正确性，通常会采用灰度发布，从而达到减小第一次变更影响面的目的。

举个例子，应用的集合中可能会包含交易中心、商品中心、库存中心等多个模块。在一次新版本发布的过程中，可能有 feature 既修改了交易中心，又修改了商品中心。为了验证新版本的正确性，需要让灰度的流量到达交易中心和商品中心的灰度版本，串联起来才能有效验证新版本的正确性，因此需要全链路灰度。

如上图，流量从入口应用进来之后，如果被识别成灰度流量，则它不仅会去往交易中心的灰度，也会去往商品中心的灰度。如果库存中心有灰度，也会去库存中心的灰度；如果没有，则会降级到库存中心的基线环境。

假设有一个网关，客户端可以从 iOS、安卓或 H5 对网关进行访问，在访问过程中，会给参数加上 header（http协议)，header 头里包含用户 ID 信息。后端分为A、B、C三个模块，比如发布了新功能，需要更新 A 和 C 两个应用模块，A 和 C 的灰度版本需要同时发布，而B应用没有新特性发布。为了有效地验证 A 和 C 新版本代码逻辑的正确性，我们将灰度规则设置为user ID =120 时去往灰度环境。因此流量从网关进来之后，先去往 A 的灰度环境；而后A调用B时，发现 B 没有灰度环境，会降级到 B 的基线环境；下一跳 B 调用 C 的时候，发现 C 存在灰度环境，又重新回到 C 的灰度环境，以此实现全链路的灰度发布。

上述全链路灰度发布的过程可以有效验证 A 和 C 两个应用的新版本组合在一起时的有效性，只有可控范围内的流量参与到灰度环境，可以有效验证新版本的正确性，避免因为新版本的业务逻辑错误造成比较重大的损失或业务故障。

以上为RPC 层的全链路灰度。

当链路请求中存在消息的时候，如何实现全链路灰度？

假设库存中心C收到一笔订单之后，会生产消息并发送到 RocketMQ server 中，同时由 A 应用来消费该消息。此时如果在过程中对消费逻辑进行了修改，则需要 C 应用生产的消息（灰度的消息）被 A 的灰度环