Apache RocketMQ在我司的最佳实践--智慧政务场景下的分布式消息与分布式事务

Posted 2022-04-08 CSDN云计算

<本文已参与 RocketMQ Summit 优秀案例征文活动，点此了解详情>

缘起

对于Apache RocketMQ的了解，追溯起来，可以说是从开源初始，就认识到了它。那时候的它，还是个幼年，没有成熟的社区，也没有好的机制去运作。本身，也不算是成熟的产品。

但是，在阿里强大的技术背景驱动下，随着业务的支撑，它慢慢得到了长远的发展，更多的走向了大众的视野，也慢慢成为了一款优秀的消息队列中间件。

在技术选型中，可以作为一名佼佼者，为各个技术负责人提供技术支持。

缘与业务

对于我司传统的业务场景以及相关产品中，一般不会涉及到消息中间件的涉及。很有幸，公司的发展以及壮大，新的产品、新的业务场景进行了拓展。我司，也参与了智慧城市的相关业务场景建设。

很多的产品，属于互联网平台，因此，对于消息队列中间件的需求，就随之诞生，也就比较迫切。借助消息队列其减少相应所需的时间和削峰，降低系统耦合性的相关特性，构建更加健壮的平台产品。

实践从业务中来，到业务中去。本次分享便从一个企业服务平台的建设才讲述。

业务场景如下所示：

我司与政府大数据局，参与共建一个企业与企业、企业与政府之间互联互通的、信息交互的一个新型互联网平台。平台中，为企业提供了最便捷的沟通入口。

根据政府的需求，企业可以在线，实现政策申报、政策享受等一系列先进的、优秀的、便捷、快速的政府服务。同时，企业在平台中，跟其他企业可以实现在线服务申请、在线沟通。其中，平台上企业个人中心中会有个模块会消息中心。展示了，企业收到的来自各个方面的消息通知。

场景如下图所示：

缘与技术

本身作为分布式消息业务需要，同时为了降低系统耦合性，选择消息队列中间件，来完成消息中心的建设。

技术选型

四种常用的分布式消息队列开源软件：Kafka、ActiveMQ、RabbitMQ 及 RocketMQ。

在分布式消息队列的江湖里，Kafka 凭借其优秀的性能占据重要一席。

Kafka 作为流平台具有以下三种能力：

1. 发布和订阅记录流，类似于消息队列或企业消息系统；
2. 具有容错能力，且可以持久化的方式存储记录流；
3. 当记录流产生时（发生时），可及时对其进行处理。

Kafka 适用于两类应用：

1. 建立实时流数据管道，在系统或应用之间可靠地获取数据；
2. 建立对数据流进行转换或反应的实时流应用程序。

目前，Kafka更多的用于数据量大的大数据平台项目。

ActiveMQ 由 Apache 出品，据官网介绍，它是最流行和最强大的开源消息总线。ActiveMQ 非常快速，支持多种语言的客户端和协议，而且可以非常容易地嵌入到企业的应用环境中，并有许多高级功能。

ActiveMQ 基于 Java 语言开发，从使用的便捷性与开源程度，是可以承担起更多的职责。但是，目前由于

1. 社区活跃度较低，更新慢，增加维护成本；
2. 网络资料显示，ActiveMQ 存在一些莫名其妙的问题，会丢失消息；
3. 目前，官方将重心放到 ActiveMQ 6.0 下一代产品 Apollo 上，对 5.x 的维护较少；
4. 不适合用于上千个队列的应用场景。

因此，不适合更新迭代速度的互联网平台。

RabbitMQ 是流行的开源消息队列系统，支持多种客户端，如 Python、Ruby、.NET、Java、JMS、C、php、ActionScript、XMPP、STOMP 等，支持 AJAX、持久化。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。但是，目前由于

1. 尽管结合 Erlang 语言本身的并发优势，性能较好，但是不利于做二次开发和维护；
2. 实现了代理架构，意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得 RabbitMQ 易于使用和部署，但使得其运行速度较慢，因为中央节点增加了延迟，消息封装后也比较大；
3. 需要学习比较复杂的接口和协议，学习和维护成本较高。

因此，综合考虑没有选择。

RocketMQ 由阿里研发团队开发的分布式队列，侧重于消息的顺序投递，具有高吞吐量、可靠性等特征。RocketMQ 与ActiveMQ一样，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的改进，在消息可靠性上比 Kafka 更好，RocketMQ 已经被业界多个大型互联网公司采用。

所谓实践是检验真理的唯一标准，实际应用中的表现比文字更具说服力。在阿里内部，RocketMQ 很好地服务了集团大大小小上千个应用，在每年的双十一当天，更有不可思议的万亿级消息通过 RocketMQ 流转（在 2017 年的双 11 当天，整个阿里巴巴集团通过 RocketMQ 流转的线上消息达到了万亿级，峰值 TPS 达到 5600 万），在阿里大中台策略上发挥着举足轻重的作用。

目前，社区活跃，开源程度高，本身经得起业务场景的考验，因此最终选型为RocketMQ。

部署架构

RocketMQ支持部署场景的自定义，同时支持高可用的部署方案。

对于当前平台的建设，存在DMZ区、金宏网区网络隔离环境。对于平台的中间件部署存在一些复杂的网络要求。

借用官网对于部署架构的图示：

对于我们在实践中的部署，同样采用了官方的部署实践。采用了多Master、多Slave异步复制的方式，即使磁盘损坏，消息丢失得非常少，消息实时性不会受影响，因为 Master 宕机后，消费者仍然可以从 Slave 消费，此过程对应用透明，不需要人工干预，性能同多 Master 模式几乎一样。

技术实现

对于RocketMQ的客户端消费者、服务端生产者来讲，采用Springboot作为技术开发框架，实现起来非常简单。

引入对应的POM依赖

<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-spring-boot-starter</artifactId>
    <version>2.0.3</version>
</dependency>

应用配置文件修改

rocketmq:
  name-server: xxxx:9876
  producer:
    group: base_group_syncMsg
    send-message-timeout: 5000
    retry-times-when-send-failed: 2
    max-message-size: 4194304

对应的添加相关注解、实现业务代码即可。

使用方便，功能强大，对于开发者来说非常友好，是一个很好的选择。

缘与分布式事务

写到这里，同时也描述下，采用了微服务技术解决方案后，在很多场景下，会产生分布式事务。那么，除了自实现，分布式事务框架，同时，我们可以采用消息队列来实现。

在本次实践中，我们有过进一步的实践。在此，就不多说。

缘与未来

实践看来，对于RocketMQ的落地过程中，虽有坎坷，但是达到了预想的效果。社区的文档也是比较满足实际落地需要，总体来说，是不错的。

在此，也希望社区越做越好吧，未来可期。