喜马拉雅 Apache RocketMQ 消息治理实践

简介：本文通过喜马拉雅的RocketMQ治理实践分享，让大家了解使用消息中间件过程中可能遇到的问题，避免实战中踩坑。

作者：曹融，来自喜马拉雅，从事微服务和消息相关中间件开发。

本文通过喜马拉雅的RocketMQ治理实践分享，让大家了解使用消息中间件过程中可能遇到的问题，避免实战中踩坑。

业务背景现状以及遇到的问题

1、消息队列概况

（1）在线场景：RabbitMQ，实例数9个；

（2）离线场景：Kafka，8个集群；

2、遇到的问题

在线场景缺乏治理：

• 业务混用，相互干扰，非核心对接积压过多触发集群限流；

• 节点负载不均衡，资源浪费严重；

• 资源和应用无关联，消息积压；

• 业务混用，相互干扰，非核心对接积压过多触发集群限流；

在线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 等；
用户：实例消息收发均匀，延迟。

老集群迁移方案

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 任务。

原文链接

本文为阿里云原创内容，未经允许不得转载。