五、灰度场景的校验
测试是校验方案可行性的真理,下面用简单的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这个消息中间件!