作者:曹融,来自喜马拉雅,从事微服务和消息相关中间件开发。
本文通过喜马拉雅的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 任务。
以上就是本次分享的全部内容,点击此处即可查看活动视频回放,期待下次交流。