五、灰度场景的校验

测试是校验方案可行性的真理，下面用简单的demo来验证鲁班平台的MQ灰度方案。

5.1 灰度版本Topic & Tag不变

这种场景在4.3、4.4时已经做了验证，不再赘述。

5.2 灰度版本Topic增加

假设v1、v2的订阅信息如表5.1所示，则Topic订阅结果如图5.1所示，TOPIC_V_ORDER被v1、v2同时订阅，首尾两条Queue分配给灰度v2的客户端，中间4条Queue则分配给非灰度v1的客户端；TOPIC_V_PAYMENT只被灰度版本v2订阅，则只会将首尾两条Queue分配给v2的客户端，其余四条Queue不会被客户端订阅。我们向TOPIC_V_ORDER分别发送4条非灰度消息和灰度消息，向TOPIC_V_PAYMENT发送4条灰度消息，从图5.2中可以看出TOPIC_V_ORDER中的非灰度消息由v1的两个客户端成功消费，TOPIC_V_ORDER与TOPIC_V_PAYMENT的灰度消息则由v2的两个客户端成功消费。

（表5.1  订阅信息表）

（图5.1  订阅结果）

（图5.2  消费结果）

5.3 灰度版本Topic减少

假设v1、v2的订阅信息如表5.2所示，则Topic订阅结果如图5.3所示，TOPIC_V_ORDER被v1、v2同时订阅，首尾两条Queue分配给灰度v2的客户端，中间4条Queue则分配给非灰度v1的客户端；TOPIC_V_PAYMENT只被非灰度版本v1订阅，则只会将中间的四条Queue分配给v1的客户端，首尾两条Queue不会被客户端订阅。我们向TOPIC_V_ORDER分别发送4条非灰度消息和灰度消息，向TOPIC_V_PAYMENT发送4条非灰度消息，从图5.4中可以看出TOPIC_V_ORDER与TOPIC_V_PAYMENT的非灰度消息由v1的两个客户端成功消费，TOPIC_V_ORDER中的灰度消息则由v2的两个客户端成功消费。

（表5.2  订阅信息表）

（图5.3  订阅结果）

（图5.4  消费结果）

5.4 灰度版本Tag变化

假设v1、v2的订阅信息如表5.3所示，则Topic订阅结果如图5.5所示，TOPIC_V_ORDER被v1、v2同时订阅，首尾两条Queue分配给灰度v2的客户端，中间4条Queue则分配给非灰度v1的客户端，我们向TOPIC_V_ORDER分别发送4条Tag=v1的非灰度消息和Tag=v2的灰度消息，从图5.6中可以看出Tag为v1的非灰度消息由v1的两个客户端成功消费，Tag为v2的灰度消息则由v2的两个客户端成功消费。

（表5.3  订阅信息表）

（图5.5  订阅结果）

（图5.6  消费结果）

5.5 灰度版本Topic & Tag混合变化

假设v1、v2的订阅信息如表5.4所示，则Topic订阅结果如图5.7所示，与5.2情况相同不再赘述。我们向TOPIC_V_ORDER分别发送4条Tag=v1的非灰度消息和Tag=v2的灰度消息，向TOPIC_V_PAYMENT发送4条灰度消息，消费结果如图5.8所示，可以看出v2的两个客户端成功消费了TOPIC_V_PAYMENT及TOPIC_V_ORDER中Tag=v2的灰度消息，而v1的两个客户端则只消费了TOPIC_V_ORDER中Tag=v1的非灰度消息。

（表5.4  订阅信息表)

（图5.7  订阅结果）

（图5.8  消费结果）

六、结语

实际的MQ灰度版本，我们还对MQ的发送与消费方做了统一的封装，业务方只需配置graySwitch、grayFlag即可，graySwtich标记是否需要开启灰度消息，在graySwitch开启的前提下，grayFlag才会生效，用来标记当前客户端是否为灰度客户端。

在多系统交互时，业务系统可通过开关graySwitch来控制是否全量消费其他系统的灰度与非灰度消息，通过grayFlag来控制是单独消费灰度消息还是非灰度消息。graySwitch、grayFlag参数可放在配置中心做到热生效，当需要切换灰度流量时，可开发相应的脚本统一化更改grayFlag，实现全链路灰度流量的无损切换。

另外，我们对于切换状态借助Namesrv做了充分细节上的控制，保证在真正执行切换前，未消费完的消息会被消费完毕才真正的执行切换。

在此，也非常感谢阿里开源RocketMQ这个消息中间件！