简介：本文通过喜马拉雅的RocketMQ治理实践分享，让大家了解消息中间件使用过程中可能遇到的问题，避免在实战中走弯路。作者：曹荣，来自喜马拉雅，从事微服务和消息相关中间件的开发。本文使用喜马拉雅的RocketMQ治理实践进行分享，让大家了解在使用消息中间件过程中可能遇到的问题，避免在实战中踩坑。业务后台现状及遇到的问题一、消息队列概述（一）线上场景：RabbitMQ，9个实例；(2)离线场景：Kafka，8个集群；2.遇到的问题线上场景缺乏治理：?业务混用，相互干扰，非核心互联积压过多触发集群限流；?节点负载不均衡，资源浪费严重；?不相关的资源和应用，消息积压；?业务混用，相互干扰，非核心互联积压过多触发集群限流；线上MQ集群改造方案1.选型(1)业务便利性：易于开发、使用、维护，提高效率，如内置重试、死信、事务保证；(2)性能：包括业务不确定性，如抗短时突发流量、抗积压等；(3)简单：架构适合拆分小集群；Java语言易于排错和二次开发；社区活跃，使用人数多，方便排错；2.治理方案(1)集群划分政策：划分小集群，减少相互干扰，减少影响；(2)拆分方案：如上图所示，对于公司与“钱”相关的业务和核心业务，不仅要提供足够的资源，还要保证数据的高安全性，这里我们使用SYNC_MASTER；对于非核心业务，我们希望性价比高，用尽可能少的资源来支撑足够的数据量，这里使用ASYNC_MASTER，扩展性会更好；对于其他对数据安全要求不高的业务，包括消息轨迹，我们使用单一的MASTER集群来保证性能需求，使用更少的资源；对于delayclusters，关注由于消息的积压，pagecache的利用率较低，目前没有使用。未来会考虑通过按需购买在云端使用；此外，它目前不涉及临时集群。3.控制面管理(1)统一消息管理后台；所有消息中间件的后台做了一个统一的管理后台，如上图所示。（2）对于RabbitMQ，只维护并自动维护关联关系；（3）对于RocketMQ，用于提升用户体验，例如发送/查询消息、一键访问demo、重发死信等；消息管理界面配置demo死信重发(4)基于PaaS的审批我们实现了基于PaaS的消息资源管理，并在功能上做了一些限制。开发和运维只能在测试环境下申请和认可。同步到其他环境，然后创建资源并通知用户。4、SDK统一接入（1）用户只关心使用什么资源，不需要知道namesrv地址，减少出错概率；(2)动态配置热生效，节省用户时间；(3)接收/发送消息，失败重试，为中间件做底线；（4）熔断限流，为业务做底线；（5）灰度接收消息（消息切换），满足特殊业务场景；（6）集成公司其他功能，如调用链、全链路压测等；5、多维度监控运维：全局、集群内top状态、物理机状态；resources：topic上下游qps，lag等；user:实例消息收发均匀延迟。老集群迁移方案1.手动迁移场景：消息的上下游都是自己的服务；迁移过程：双收（RocketMQ&RabbitMQ）->双发->单发（RocketMQ）->单收；需要注意的问题：业务繁重2.自动迁移RabbitMQ<-->RocketMQ互镜像迁移；粒度：交换<-->主题；注：同组任务互斥；(1)RabbitMQ->RocketMQ迁移方案：将RabbitMQ的exchange整体同步到topic，在abc.exchange中添加一个topic前缀作为topic_abc.excange；将RabbitMQ的Routingkey预设为RocketMQ的标签；通过migrator任务程序收集RabbitMQ的消息队列，根据不同的类型投递到RocketMQ；(2)RocketMQ->RabbitMQ迁移方案：方法类似，见下图：(3)自动迁移的几种情况：消费者迁移，生产者不动：配置RabbitMQ->RocketMQ任务；生产者迁移，消费者不动：配置RocketMQ->RabbitMQ任务；producer先不迁移，再迁移：先配置RabbitMQ->RocketMQ任务；迁移后，关闭RabbitMQ->RocketMQ任务；配置RocketMQ->RabbitMQ任务。原文链接本文为阿里云原创内容，未经许可不得转载。
