喜马拉雅|喜马拉雅 Apache RocketMQ 消息治理实践 apache|中间件

文章图片

文章图片

文章图片

文章图片

文章图片

文章图片

本文通过喜马拉雅的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、人工迁移
场景：消息上下游均为自己的服务；
迁移流程：双收（RocketMQRabbitMQ）-双发-单发（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；