缘起
对于Apache RocketMQ的了解，追溯起来，可以说是从开源初始，就认识到了它。那时候的它，还是个幼年，没有成熟的社区，也没有好的机制去运作。本身，也不算是成熟的产品。
但是，在阿里强大的技术背景驱动下，随着业务的支撑，它慢慢得到了长远的发展，更多的走向了大众的视野，也慢慢成为了一款优秀的消息队列中间件。
在技术选型中，可以作为一名佼佼者，为各个技术负责人提供技术支持。
缘与业务
对于我司传统的业务场景以及相关产品中，一般不会涉及到消息中间件的涉及。很有幸，公司的发展以及壮大，新的产品、新的业务场景进行了拓展。我司，也参与了智慧城市的相关业务场景建设。
很多的产品，属于互联网平台，因此，对于消息队列中间件的需求，就随之诞生，也就比较迫切。借助消息队列其减少相应所需的时间和削峰，降低系统耦合性的相关特性，构建更加健壮的平台产品。
实践从业务中来，到业务中去。本次分享便从一个企业服务平台的建设才讲述。
业务场景如下所示：
我司与*大数据局，参与共建一个企业与企业、企业与*之间互联互通的、信息交互的一个新型互联网平台。平台中，为企业提供了最便捷的沟通入口。
根据*的需求，企业可以在线，实现政策申报、政策享受等一系列先进的、优秀的、便捷、快速的*服务。同时，企业在平台中，跟其他企业可以实现在线服务申请、在线沟通。其中，平台上企业个人中心中会有个模块会消息中心。展示了，企业收到的来自各个方面的消息通知。
场景如下图所示：
缘与技术
本身作为分布式消息业务需要，同时为了降低系统耦合性，选择消息队列中间件，来完成消息中心的建设。
技术选型
四种常用的分布式消息队列开源软件：Kafka、ActiveMQ、RabbitMQ 及 RocketMQ。
在分布式消息队列的江湖里，Kafka 凭借其优秀的性能占据重要一席。
Kafka 作为流平台具有以下三种能力：
- 发布和订阅记录流，类似于消息队列或企业消息系统；
- 具有容错能力，且可以持久化的方式存储记录流；
- 当记录流产生时（发生时），可及时对其进行处理。
Kafka 适用于两类应用：
- 建立实时流数据管道，在系统或应用之间可靠地获取数据；
- 建立对数据流进行转换或反应的实时流应用程序。
目前，Kafka更多的用于数据量大的大数据平台项目。
ActiveMQ 由 Apache 出品，据官网介绍，它是最流行和最强大的开源消息总线。ActiveMQ 非常快速，支持多种语言的客户端和协议，而且可以非常容易地嵌入到企业的应用环境中，并有许多高级功能。
ActiveMQ 基于 Java 语言开发，从使用的便捷性与开源程度，是可以承担起更多的职责。但是，目前由于
- 社区活跃度较低，更新慢，增加维护成本；
- 网络资料显示，ActiveMQ 存在一些莫名其妙的问题，会丢失消息；
- 目前，官方将重心放到 ActiveMQ 6.0 下一代产品 Apollo 上，对 5.x 的维护较少；
- 不适合用于上千个队列的应用场景。
因此，不适合更新迭代速度的互联网平台。
RabbitMQ 是流行的开源消息队列系统，支持多种客户端，如 Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等，支持 AJAX、持久化。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。但是，目前由于
- 尽管结合 Erlang 语言本身的并发优势，性能较好，但是不利于做二次开发和维护；
- 实现了代理架构，意味着消息在发送到客户端之前可以在*节点上排队。此特性使得 RabbitMQ 易于使用和部署，但使得其运行速度较慢，因为*节点增加了延迟，消息封装后也比较大；
- 需要学习比较复杂的接口和协议，学习和维护成本较高。
因此，综合考虑没有选择。
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的落地过程中，虽有坎坷，但是达到了预想的效果。社区的文档也是比较满足实际落地需要，总体来说，是不错的。
在此，也希望社区越做越好吧，未来可期。