消息队列的处理在测试环境路由中是非常特殊的存在，据说阿里ToG的团队都没有搞定RocketMQ。知道了这个消息，我们还是很值得骄傲的！！！
消息队列有多种实现，当时我们公司同时使用了RabbitMQ、ActiveMQ、Kafka、RocketMQ四种，但业务主要使用的是ActiveMQ，未来计划统一为RocketMQ，所以当时对ActiveMQ和RocketMQ做了测试环境路由的增强。
这里主要讲解RocketMQ的增强实现。
为了避免增强的实现逻辑过于复杂，方便升级操作，RocketMQ的路由判断的主要实现放到了RocketMQ-Dashboard服务里面，整体的架构如下图所示：
整体思路：
1、不同特性环境的生产者向同一个主题放送消息，但在消息中会携带链路信息
2、不同的特性环境以不同的消费组订阅主题，消费组名称中带有特性环境的名称
3、每个消费组接收到消息后，调用dashboard暴露的接口，判断是否应该自己消费，不应该自己消费，就抛弃掉此消息
下面从代码层面详情介绍具体的业务逻辑
消费者注册特性环境身份
拦截方法：voidDefaultMQPushConsumer#setConsumerGroup(String consumerGroup)
修改消费组名称，名称中附加特性环境标识
消费者消费逻辑
从消息头中解析出调用链路来源的特性环境标识，与消费者的特性环境身份对比，如果一致，直接消费；
若不一致，则调用RocketMQ Dashboard中的新增暴露的http方法，判断是否应该由自己消费，若不应该，则抛弃
Dashboard中新增的远程消费规则逻辑
如果你觉得这篇文章对你有帮助，请不要吝惜你的“关注”、“点赞”、“评价”，我们可以进一步讨论实现方案和细节。你的支持永远是我前进的动力~~~
