改造MQ组件，采用RocketMQ

• MQ组件选择：采用RocketMQ；
• 换掉Redis组件的队列模式；
• 将基于Python的系统改Java语言；
• 提供消息生产与消费两个服务；
• MQ的功能由上述服务进行统一维护；

这里在核心业务线上没有改变组件选择，换掉kafka的一个原因是涉及大量结算业务，Redis队列模式弃用，基于Python的管理系统功能不多，这里只是顺手换掉，统一业务线的编程语言。这样设计之后，从整体思路上看就会合理很多。

改造过程

1 整体思路

涉及核心角色说明，从左向右依次：

• 生产客户端：需要请求服务端通信的节点，调用生产服务端封装的消息发送接口即可；
• 生产服务端：封装消息发送API，并维护路由管理，权限识别等，消息落地存储等；
• 消息存储层：主要基于消息中间件进行存储，数据库层面用来处理特定情况下的二次调度；
• 消费服务端：封装消息接收API，并根据路由标识，请求指定的消费端接口，完成通信；
• 消费客户端：响应消费服务端的请求，封装消费时具体的业务逻辑；

在整体的技术难度上没有太多差别，但是引入两个服务【生产和消费】，用来管理MQ通信流程，适配特定的业务逻辑，引入数据库做一次落地存储，在异常流程的处理上更加灵活，这样整个消息模块具有很强的可扩展性。

2 细节描述

• 组件选型

消息中间件的选择是比较多的，但是鉴于业务线上开发人员的熟悉程度，以及参考多方提供的测试对比报告，最终确定选用RocketMQ组件，同时RocketMQ相关特点：高性能、高可靠性，以及对分布式事务的支持，也是核心的考虑因素。

• 微服务架构

基于当前微服务的架构模式，把MQ功能本身集成在两个核心服务中，进行统一管理和迭代，以及组件的版本控制，对于所有生产的消息，进行全局路由控制，以及特定情况下的，通过应用服务层面功能设计，实现消息延时消费，以及失败消息的二次调度执行，和部分单条消息的手动触发。

• 数据存储

对消息实体进行二次存储，主要还是适配部分特定的功能点，有些消息可以延时处理，例如当MQ队列出现堆积的时候，或者达到监控的预警线时，可以通过配置手段，干预一部分消息只存储入库，不推送MQ，等待服务相对空闲的时候再去发送。

消息中间件作为系统间解耦的稳定支撑，在服务层面管理时，需要具备清晰的设计路线，以及流程关键节点的监控和记录，确保整个链路的稳定和容错。