一、背景简介

在零碎开发初期，很容易呈现这样一种状况：不同业务线上开发人员，因为技术栈和版本工夫的影响，在选型的时候会优先应用本人相熟的，例如 MQ 中间件罕用的：Kafka、Rocket、Rabbit 等，这样很容易疏忽各个我的项目之间的组件差别问题；

在零碎开发中后期，业务绝对稳固之后，通常都会对资源占用较高的模块逐渐重构，公共服务进行整合治理，从而使零碎更具备整体性，在这个过程中，解决不同我的项目的中间件差别通常首当其冲，例如常见的缓存核心，MQ 音讯治理等；

这种状况一般来说很难防止，零碎初期为了疾速撑持业务，埋下很多坑点，一旦业务能够稳固倒退，并且可持续性失去验证，就会开始适当思考逐渐进行模块重构，降低成本。

二、重构思路

2.1 初期问题

在某守业公司研发初期，业务线上存在五个我的项目并行开发的状况，过后对于 MQ 的应用情况如下：

• Rocket：外围业务 3 个我的项目，版本有差别；
• Kafka：数据权重偏高，1 个我的项目采纳；
• Redis：基于 Python 连贯，队列音讯模式；

刚开始因为用的不多，整体还在可控范畴内，后续随着业务的继续迭代，我的项目间呈现须要通信的状况，就开始凌乱难以保护，而后就是被迫开始重构，对立音讯组件。

2.2 二次选型

基于业务的综合考量，对现有几个我的项目进行 MQ 从新设计，造成的整体架构思路如下：

• MQ 组件抉择：采纳 RocketMQ；
• 换掉 Redis 组件的队列模式；
• 将基于 Python 的零碎改 Java 语言；
• 提供音讯生产与生产两个服务；
• MQ 的性能由上述服务进行对立保护；

这里在外围业务线上没有扭转组件抉择，换掉 kafka 的一个起因是波及大量结算业务，Redis 队列模式弃用，基于 Python 的管理系统性能不多，这里只是棘手换掉，对立业务线的编程语言。这样设计之后，从整体思路上看就会正当很多。

三、革新过程

3.1 整体思路

波及外围角色阐明，从左向右顺次：

• 生产客户端：须要申请服务端通信的节点，调用生产服务端封装的音讯发送接口即可；
• 生产服务端：封装音讯发送 API，并保护路由治理，权限辨认等，音讯落地存储等；
• 音讯存储层：次要基于消息中间件进行存储，数据库层面用来解决特定状况下的二次调度；
• 生产服务端：封装音讯接管 API，并依据路由标识，申请指定的生产端接口，实现通信；
• 生产客户端：响应生产服务端的申请，封装生产时具体的业务逻辑；

在整体的技术难度上没有太多差异，然而引入两个服务【生产和生产】，用来治理 MQ 通信流程，适配特定的业务逻辑，引入数据库做一次落地存储，在异样流程的解决上更加灵便，这样整个音讯模块具备很强的可扩展性。

3.2 细节形容

• 组件选型

消息中间件的抉择是比拟多的，然而鉴于业务线上开发人员的相熟水平，以及参考多方提供的测试比照报告，最终确定选用 RocketMQ 组件，同时 RocketMQ 相干特点：高性能、高可靠性，以及对分布式事务的反对，也是外围的思考因素。

• 微服务架构

基于以后微服务的架构模式，把 MQ 性能自身集成在两个外围服务中，进行对立治理和迭代，以及组件的版本控制，对于所有生产的音讯，进行全局路由管制，以及特定状况下的，通过应用服务层面功能设计，实现音讯延时生产，以及失败音讯的二次调度执行，和局部单条音讯的手动触发。

• 数据存储

对音讯实体进行二次存储，次要还是适配局部特定的性能点，有些音讯能够延时解决，例如当 MQ 队列呈现沉积的时候，或者达到监控的预警线时，能够通过配置伎俩，干涉一部分音讯只存储入库，不推送 MQ，期待服务绝对闲暇的时候再去发送。

消息中间件作为零碎间解耦的稳固撑持，在服务层面治理时，须要具备清晰的设计路线，以及流程要害节点的监控和记录，确保整个链路的稳固和容错。

同系列 ：分布式概念 | 分布式事务 | Kafka 集群 | RocketMQ 组件 | Redis 集群

四、源代码地址

GitEE·地址
https://gitee.com/cicadasmile
Wiki·地址
https://gitee.com/cicadasmile/butte-java-note/wikis

浏览标签

【Java 根底】【设计模式】【构造与算法】【Linux 零碎】【数据库】

【分布式架构】【微服务】【大数据组件】【SpringBoot 进阶】【Spring&Boot 根底】

【数据分析】【技术导图】【职场】