一、背景
随着公司业务的快速发展，业务部门为了满足自己业务场景需求自己搭建RocketMQ集群，没有做MQ消息中间件集群做统一规划，导致现有公司线上存在多套集群（分别是：mro集群，mdm集群，rot-sc集群，每个集群采用多主多从部署，保证服务的高可用）。然而随着业务的增长，虽然多套集群能够起到业务间消息、流量隔离、各个业务间相互不影响，但是也会存在其他的问题。
主要有以下问题：
部门使用了不同的集群，业务消息跨部门消费变得困难（需要引入多套集群才能实现、并且代码不便于维护）
集群消息量小、机器资源得不到充分利用
同时需要维护多套集群，升级维护成本高
二、线上集群现状
集群：采用主备部署（每套集群3主3从），部署版本rocketmq 4.4.0
Namesrv域名：一个域名对应一个Namesrv节点IP，通过域名+端口访问
三、集群迁移前期准备
准备新机器6台（部署3主3从），打通业务机器和新集群机器之间网络
验证MRO集群、MDM集群、ROT-SC集群三套集群Topic和Group是否有冲突，如果存在冲突需要业务方修改后再进行迁移。
准备RocketMQ 4.4.0版本的镜像，采用docker部署
四、迁移方案一 （不推荐）
部署：
部署一套新集群，提供业务使用的新集群Namesrv地址
将老集群的Topic和Group迁移到新集群（老集群不再新建Topic和Group）
生产者和消费者地址：新业务使用新集群Namesrv地址，老服务使用Namesrv地址不变
切换DNS 老集群Namesrv域名的 IP到新集群机器IP（只切1/2的域名）
生产端：可以连接到新集群或者老集群发送消息（从老集群或者新集群选择其中一个Namesrv地址获取broker节点连接）
消费端：可以连接到新集群或者老集群消费消息（从老集群或者新集群选择其中一个Namesrv地址获取broker节点连接），这步消费会存在问题
5. 切换老集群broker节点权限为只读，不再写入新消息（注：切换权限消费时不会重新负载均衡）
6. 将老集群Namesrv域名IP地址全部切换到新集群Namesrv地址 IP
7. 下线老集群节点（确保消息被消费完、无新消息写入）
优点：
业务改动少：新业务引入新集群Namesrv地址，老集群地址不变
问题：
由于切换域名对应的IP后，生产者和消费者只能连接到新集群Namesrv地址或者老集群Namesrv地址，存在部分机器的消息不能被消费 （暂时不能解决）
消费端连接到老集群，新集群消息不能被消费
反之消费端连接到新集群，老集群的消息就不能被消费
只有消费端和生产端连接Namesrv都是新集群地址或者老集群地址才能正常消费
2. 切换域名IP地址时业务会重新连接生产/消费
由于生产/消费端和MQ Namesrv地址连接是长连接，重启或者下线Namesrv节点后才可以拿到新的IP地址进行连接
迁移期间新增Topic和Group需要同步在新老集群创建
切换部分IP可能存在风险（当前域名配置是一个域名对应一个IP）
如果当前业务方只配置一个Namesrv节点的域名地址切换后会导致老集群的消息不会被消费
域名切换：
切换部分老集群Namesrv域名IP:
老集群Namesrv域名IP全部切换到新集群Namesrv IP：
五、方案二 （推荐使用）
部署：
新部署集群（Namesrv地址为：老Namesrv IP + 新namesrv IP），服务权限为只读
迁移老集群Topic和Group到新集群服务
业务方使用现有集群Namesrv地址不变
新集群开启读写权限，老集群部分流量会自动切到新集群进行生产和消费
将老集群节点切换为只读，不再写入新消息，等待老集群broker节点消息消费完成
DNS将老集群Namesrv域名地址IP切换指向新集群Namesrv地址IP （运维操作）
下线老集群服务节点（确保消息被消费完成、无新消息写入，流量全部切入新集群）
PS: 优点：
业务无需要做任何修改，使用集群Namesrv地址不变
新集群broker节点注册到了老集群Namesrv节点，业务方可以能拿到新集群broker和老集群broker配置
问题：
1. DNS切换老集群Namesrv域名IP后业务会重新连接到新的Namesrv地址进行生产/消费
由于生产/消费端和MQ Namesrv地址连接是长连接，只有老Namesrv重启或者下线后才可以拿到新集群的Namesrv 地址IP进行连接
2. 迁移期间新增Topic和Group需要同时在新老集群创建
域名IP切换：
修改DNS将老集群Namesrv域名IP切换到新集群Namesrv IP：
六、总结
1. 这里选择方案二可以解决消息不被消费的问题，通过控制MQ服务Broker节点的权限可以平滑的进行流量切换，对业务无损。
2. 最后一步DNS切换老集群Namesrv 域名IP地址需要将老集群Namesrv节点重启或者下线，客户端通过域名重新拿到最新的Namesrv IP地址连接，从而保证消息的正常生产和消费。
3. 根据方案二合并后所有业务部门使用一套集群，便于部门间业务合作
4. 合并后可以释放出两套集群机器，并且可以充分利用服务器资源
5. 合并后可以降低运维成本，后续升级维护更加方便
PS: 有其他好的解决方案可以一起留言交流