01
业务背景现状以及遇到的问题
1、消息队列概况
（1）在线场景：RabbitMQ，实例数9个；
（2）离线场景：Kafka，8个集群；
2、遇到的问题
在线场景缺乏治理：
· 业务混用，相互干扰，非核心对接积压过多触发集群限流；
· 节点负载不均衡，资源浪费严重；
· 资源和应用无关联，消息积压；
· 业务混用，相互干扰，非核心对接积压过多触发集群限流；
02
在线MQ集群改造方案
1、选型
（1）业务便捷性：易于开发、使用、维护，提高效率，如自带重试、自带死信、自带事务保障；
（2）性能：包容业务的不确定性，如抗短时突发流量、抗积压等；
（3）简单：架构适用于拆分小集群；Java语言易于排查问题和二次开发；社区活跃，使用的人多，方便排查问题；
2、治理方案
（1）集群划分方针：划分小集群，减少相互干扰，减少影响面；
（2）拆分方案：
如上图所示，对于公司和“钱”相关的业务及核心业务，不仅要给足资源，同时要保证较高的数据安全，在这里就使用了SYNC_MASTER；
对于非核心业务，我们希望它的性价比高，使用尽量少的资源去支撑足够多的数据量，此处就使用了ASYNC_MASTER，伸缩性会更好；
对于其它数据安全要求不高的业务，包括消息轨迹，我们使用单MASTER集群，保证了性能需要，资源使用也少；
对于延时集群，专注于积压消息，pagecache利用率低，目前还没用做，未来考虑在云上采用按需购买的方式来使用；另外对于临时集群目前也没有涉及。
3、控制面管理
（1）统一消息治理后台；
对所有消息中间件的后台做了一个统一的管理后台，如上图。
（2）对RabbitMQ，仅维护，自动维护关联关系；
（3）对于RocketMQ，用于提升用户体验，比如发送/查询消息、一键接入demo、死信重发等；
消息管理界面
配置demo
死信重发
（4）PaaS化审批
我们对消息化的资源管理做了一个PaaS化的管理，对功能做了一些限制，开发和运维只能在测试环境下做申请和审批，审批通过后再同步到其它环境，然后创建资源、通知用户。
4、统一接入SDK
（1）用户只关心用什么资源，不需要了解namesrv地址，减少出错概率；
（2）动态配置热生效，节约用户时间；
（3）收/发消息，失败重试，为中间件做兜底；
（4）熔断限流，为业务做兜底；
（5）灰度收消息（消息开关），满足业务特殊场景；
（6）集成公司其他功能，如调用链、全链路压测等；
5、多维度监控
运维：整体情况，cluster内top情况，所属物理机情况；
资源：Topic上下游qps，lag等；
用户：实例消息收发均匀，延迟。
03
老集群迁移方案
1、人工迁移
场景：消息上下游均为自己的服务；
迁移流程：双收（RocketMQ&RabbitMQ）-> 双发-> 单发（RocketMQ）-> 单收；
需要注意的问题：业务重构，topic合并可能导致下游多tag消息倾斜，导致lag异常问题；
2、自动迁移
RabbitMQ <--> RocketMQ 相互镜像迁移；
粒度: exchange < -- > topic；
注意: 相同组的任务互斥；
（1）RabbitMQ -> RocketMQ的迁移方案：
把RabbitMQ的exchange整体同步到topic，在abc.exchange加一个topic前缀为topic_abc.excange；
把RabbitMQ的Routing key预设为RocketMQ的tag；
通过migrator任务程序收集RabbitMQ的消息队列，按照不同的类型传递到RocketMQ；
（2）RocketMQ -> RabbitMQ的迁移方案：
方法类似，见下图：
（3）自动迁移的几种情况：
消费者迁移，生产者不动：
配置RabbitMQ -> RocketMQ 任务；
生产者迁移，消费者不动：
配置RocketMQ -> RabbitMQ 任务；
生产者先不迁移，然后迁移了：
先配置RabbitMQ -> RocketMQ 任务；
迁移完毕后，关闭RabbitMQ -> RocketMQ 任务；
配置RocketMQ -> RabbitMQ 任务。
本文作者：曹融，来自喜马拉雅，从事微服务和消息相关中间件开发。
联系客服
