全链路灰度之 RocketMQ 灰度

推荐学习：本文关联技术专题已在「RocketMQ 中文社区」持续更新，含实战案例及源码解析等内容
之前的系列文章中，我们已经通过全链路金丝雀发布这个功能来介绍了 MSE 对于全链路流量控制的场景，我们已经了解了 Spring Cloud 和 Dubbo 这一类 RPC 调用的全链路灰度应该如何实现，但是没有涉及到消息这类异步场景下的流量控制，今天我们将以上次介绍过的《如何用 20 分钟就能获得同款企业级全链路灰度能力？》中的场景为基础，来进一步介绍消息场景的全链路灰度。

虽然绝大多数业务场景下对于消息的灰度的要求并不像 RPC 的要求得这么严格，但是在以下两个场景下，还是会对消息的全链路有一定的诉求的。

1、第一种场景是在消息消费时，可能会产生新的 RPC 调用，如果没有在消息这一环去遵循之前设定好的全链路流量控制的规则，会导致通过消息产生的这部分流量“逃逸”，从而导致全链路灰度的规则遭到破坏，导致出现不符合预期的情况。

为了防止出现这个情况，我们需要在消费时候将消息里原来的流量标复原，并在 RPC 调用的时候遵循原来的规则。我们通过架构图来详细描述一下，满足这个逻辑之后，调用链路是怎样的，从下图中我们可以看到，灰度和基线环境生产出来的消息，虽然在消息推送的时候是随机的，但是在消费过程中，产生的新的 RPC 调用，还是能够回到流量原来所属的环境。

2、第二种场景需要更加严格的消息灰度隔离。比如当消息的消费逻辑进行了修改时，这时候希望通过小流量的方式来验证新的消息消费逻辑的正确性，要严格地要求灰度的消息只能被推送给灰度的消息消费者。

今天我们就来实操一下第二种场景消息的全链路灰度，目前 MSE 仅支持 RocketMQ 消息的灰度。若您使用的是开源版 RocketMQ，那么版本需要在 4.5.0 及以上，若您使用的是阿里云商业版 RocketMQ，那么需要使用铂金版，且 Ons Client 版本在 1.8.0.Final 及以上。如果只是想使用第一种场景，只需要给 B 应用开启全链路灰度的功能即可，不需要做额外的消息灰度相关的配置。

在这次最佳实践的操作中，我们是将应用部署在阿里云容器服务 Kubernetes 版本，即 ACK 集群来演示，但是事实上，消息灰度对于应用的部署模式是没有限制性要求的，您可以参考 MSE 帮助文档，找到自己所使用的部署模式对应的接入方式，也能使用消息全链路灰度。

前提条件

1. 开通 MSE 专业版，请参见开通 MSE 微服务治理专业版**[****1]**。

2. 创建 ACK 集群，请参见创建 Kubernetes 集群**[2****]**。

操作步骤

步骤一：接入 MSE 微服务治理

1、安装 mse-ack-pilot

1. 登录容器服务控制台**[3****]**。
2. 在左侧导航栏单击市场 > 应用目录。
3. 在应用目录页面点击阿里云应用，选择微服务，并单击 ack-mse-pilot。
4. 在 ack-mse-pilot 页面右侧集群列表中选择集群，然后单击创建。

安装 MSE 微服务治理组件大约需要 2 分钟，请耐心等待。
创建成功后，会自动跳转到目标集群的 Helm 页面，检查安装结果。如果出现以下页面，展示相关资源，则说明安装成功。

2、为 ACK 命名空间中的应用开启 MSE 微服务治理

1. 登录 MSE 治理中心控制台**[4****]**，如果您尚未开通 MSE 微服务治理，请根据提示开通。

2. 在左侧导航栏选择微服务治理中心 > Kubernetes 集群列表。

3. 在 Kubernetes 集群列表页面搜索框列表中选择集群名称或集群 ID，然后输入相应的关键字，单击搜索图标。

4. 单击目标集群操作列的管理。

5. 在集群详情页面命名空间列表区域，单击目标命名空间操作列下的开启微服务治理。

6. 在开启微服务治理对话框中单击确认。

步骤二：还原线上场景

首先，我们将分别部署 spring-cloud-zuul、spring-cloud-a、spring-cloud-b、spring-cloud-c 这四个业务应用，以及注册中心 Nacos Server 和消息服务 RocketMQ Server，模拟出一个真实的调用链路。

Demo 应用的结构图下图，应用之间的调用，既包含了 Spring Cloud 的调用，也包含了 Dubbo 的调用，覆盖了当前市面上最常用的两种微服务框架。其中 C 应用会生产出 RocketMQ 消息，由 A 应用进行消费，A 在消费消息时，也会发起新的调用。这些应用都是最简单的 Spring Cloud 、 Dubbo 和 RocketMQ 的标准用法，您也可以直接在 https://github.com/aliyun/alibabacloud-microservice-demo/tree/master/mse-simple-demo 项目上查看源码。

部署之前，简单介绍一下这个调用链路

spring-cloud-zuul 应用在收到 “/A/dubbo” 的请求时，会把请求转发给 spring-cloud-a ，然后 spring-cloud-a 通过 dubbo 协议去访问 spring-cloud-b， spring-cloud-b 也通过 dubbo 协议去访问 spring-cloud-c，spring-cloud-c 在收到请求后，会生产一个消息，并返回自己的环境标签和 ip。这些生产出来的消息会由 spring-cloud-a 应用消费，spring-cloud-a 应用在消费消息的时候，会通过 spring cloud 去调用 B，B 进而通过 spring cloud 去调用 C，并且将结果输出到自己的日志中。

当我们调用 /A/dubbo 的时候
返回值是这样 A[10.25.0.32] -> B[10.25.0.152] -> C[10.25.0.30]


同时，A 应用在接收到消息之后，输出的日志如下

2021-12-28 1