开源 VS 商业，消息中间件你不知道的那些事

演讲实录  

随着云计算的兴起，Docker、微服务的流行，分布式消息队列技术成为云计算平台中不可或缺的组件。今天由我来给大家分享下目前市场上主流的商业、开源消息中间件之间的区别。

什么是消息中间件MOM（Message Oriented Middleware）利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。

异步：基于存储转发机制的异步通信方式，发送者将消息发送给消息服务器，消息服务器将消息存放在若干队列中，在合适的时候再将消息转发给接收者。

松耦合：客户和服务对象的生命周期松耦合，由MOM来保障消息队列及服务，二者的生命周期无需相同，即发送消息的时候接收者不一定运行，接收消息的时候发送者也不一定运行。

可靠性：由MOM来保障消息不会因网络连接异常断开、进程异常重启等各种原因导致消息丢失。

消息传递模式分为PTP和Pub/Sub两种模式。

 

PTP（Point–to-Point）

消息中间件有着异步通知、数据复制、日志同步、延迟队列、广播通知五大适用业务场景。

异步通知：为面向服务架构（SOA）提供分布式事务支持；保证全局数据一致性。比如订单处理调度通知，订单拆解后发送开通、计费、账处等到期提醒，办理告知短信，订单状态，二次确认等。

数据复制：利用消息中间件将数据从源头复制到多个目的地；满足搜索、离线分析和分表规则变化等需求。如系统间TF数据同步多系统，局数据增量发布等。

日志同步：应用通过可靠异步方式将日志同步到消息中间件；可以对日志做实时或离线分析。如统一日志平台中心日志入库等。

延迟队列：把消息中间件当做可靠的延迟队列；分布式环境下的定时器。如受理订单入库，系统日志入库等高频率DB写入场景。

消息协议JMS VS AMQP

JMS提供了两种消息模型，peer-2-peer(点对点)以及publish-subscribe（发布订阅）模型。在JMS中，消息路由非常简单，由producer和consumer链接到同一个queue（p2p）或者topic（pub/sub）来实现消息的路由。JMSconsumer同时支持message selector（消息选择器，通过消息选择器，consumer可以只消费那些通过了selector筛选的消息。

AMQP是一种协议，更准确的说是一种binary wire-level protocol（链接协议）。这是其和JMS的本质差别。AMQP不从API层进行限定，而是直接定义网络交换的数据格式。这使得实现了AMQP的provider天然性就是跨平台的。

在AMQP中，消息路由（messagerouting）和JMS存在一些差别，在AMQP中增加了Exchange和binding的角色。producer将消息发送给Exchange，binding决定Exchange的消息应该发送到那个queue，而consumer直接从queue中消费消息。queue和exchang的bind有consumer来决定。

市场上目前主流的消息中间件有IBM MQ、WebLogic JMS、ActiveMQ、Rabbit MQ、Rocket MQ、Apollo等。

IBM  MQ：WebSphere MQ是IBM业务集成基础性产品，以其独特的安全机制、简便快速的编程风格、高稳定性、可扩展性和跨平台性，以及强大的事务处理能力和消息通讯能力，成为业界市场占有率最高的消息中间件产品。

WebLogic JMS：WebLogic JMS是Oracle公司一个高性能、集群的Messaging Server，基于WebLogic产品，支持数据库和文件持久化，完全支持XA事务。

RocketMQ：RocketMQ是阿里开源的分布式、队列模型的消息中间件，支持严格的消息顺序；支持Topic与Queue两种模式；亿级消息堆积能力；比较友好的分布式特性；同时支持Push与Pull方式消费消息。

ActiveMQ：ActiveMQ是目前市场上非常流行的开源消息传递和集成服务器。它的消息传递速度非常快，支持多种跨平台的客户端和协议，非常容易构建企业级的集成模式，同时支持JMS1.1和J2EE1.4规范。ActiveMQ基于Apache2.0许可。

Apollo：Apollo是以ActiveMQ原型为基础，是一个更快、更可靠、更易于维护的消息代理工具，Apache称Apollo为最快、最强健的STOMP（Streaming Text Orientated Message Protocol，流文本定向消息协议）服务器。

RabbitMQ：RabbitMQ是AQMP协议用Erlang实现的消息队列产品，它实现了代理（Broker）架构，消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使用和部署，适宜于很多场景如路由、负载均衡或消息持久化等。

这是某团队各产品功能和性能对比的最终结果，从结果来看：

ActiveMQ各功能模块相对完善，不支持集群控制台管理，在订阅模式性能测试（10K及以下消息大小）领先其他产品。

IBM WMQ有最完善的功能点实现，在点对点模式读写混合性能测试中领先其他产品。

Oracle JMS是Weblogic的组件，非独立产品，各功能模块相对完善，在点对点模式纯读取性能测试中领先其他产品，不支持AMQP消息协议。

RabbitMQ有独特的镜像队列功能，能支持分布式内存复制实现持久化，在分布式扩展方面相对有优势，控制台实现性能监控非常丰富。

RocketMQ功能模块支持较差，实现的消息协议是自定义的文本传输协议，在1M消息大小的性能测试中领先其他产品。

Apollo产品成熟度不够，不支持集群模式（消息路由）。

商业产品中IBM WMQ产品成熟度高，实现功能完整，应用广泛，兼容性强，跨平台和跨语言支持较好；Oracle JMS是基于WebLogic的一个组件，仅支持JMS和WebLogic T3消息协议，不支持AMQP协议，跨平台支持有待完善。开源产品中ActiveMQ最成熟、功能最完善。

基本功能专题分析

总体来看，各产品在C/C++语言客户端API、消息优先级实现相对较好。

基本功能——语言和协议支持

基本功能——用户名密码认证：主要通过新建用户名和密码，使用JMS客户端进行连接尝试，实现用户名密码不一致的情况是否允许连接。

IBM WMQ由队列管理器、队列、通道各部分组成，可通过界面对每个组成部分都进行访问控制。

Oracle JMS消息队列基于AdminServer实例，可通过界面添加用户，指定JMS消息队列的访问控制。

基本功能——死信机制：主要通过测试消息在传递失败或消息过期时是否可以标记为死信。

IBM WMQ、Oracle JMS、RabbitMQ、ActiveMQ均支持读取异常、消息过期两种死信机制。

Apollo只支持消息过期模式，可设置redelivered参数，当超过maximumRedeliveries（缺省为6次）次数时，消息会放入死信队列。

基本功能——消息有效期：主要通过在JMS客户端设置消息生存时间，在生存时间结束后启动消费者，消息是否被丢弃或销毁。

除RocketMQ之外的产品均支持消息有效期配置。

基本功能——消息优先级：主要通过在JMS客户端发送一组消息，是否可配置消息的优先级，是否可按消息的优先级进行处理。

IBM WMQ、Oracle JMS、ActiveMQ、Apollo均支持消息优先级和队列优先级配置。

RabbitMQ、RocketMQ不支持消息优先级配置，只支持队列优先级配置，即配置一个优先级高的队列，和一个普通优先级的队列，将优先级不同的消息发往不同队列进行处理。

运维管理——管理工具：在管理界面测试是否可以进行队列的创建、删除、启动等基本功能。

商业产品在管理界面上支持较为完善，能通过管理界面进行队列的创建、删除及队列的启停等动作。

RabbitMQ、RocketMQ管理界面不支持队列的启停，可通过命令行、接口实现，支持Rest API接口。

ActvieMQ / Apollo管理界面除不支持队列的启停外，不支持集中化管理，通过JMX配置文件实现，支持Rest API接口。

运维管理——日志系统：可以修改实例的日志级别，使其可以记录系统的重要事件，比如新的入站连接、新消息入站等。

商业产品在日志系统上做得最为完善，日志配置也比较简单。

运维管理——监控系统：可监控消息中间件运行状态，可监控到集群内所有节点队列数、队列中消息数、出入队消息数、连接数等。

RabbitMQ在监控系统模块表现最为优秀，集群性能、队列性能、消息发送次数、持久化大小、TPS性能等均有丰富的实现。

ActiveMQ / Apollo仅支持单个队列的控制台实现，但对单个队列的监控实现较为丰富，不支持TPS性能的实现。

Apollo不支持集群功能（消息路由），能通过配置文件实现水平扩展，能通过failover协议实现负载均衡。

集群功能：通过配置集群实例，能实现队列的水平扩展、动态扩展，能实现消息的路由和负载均衡。

除Apollo外各产品均能较好的实现集群所需功能。

Apollo不支持集群功能（消息路由），能通过配置文件实现水平扩展，能通过failover协议实现负载均衡。

高可用：通过测试当队列服务器出现故障或者网络故障时，客户端可以自动连接到其他队列，保持业务的不间断。

所有产品均能实现FAILOVER机制，RabbitMQ需通过HAProxy来实现FAILOVER。

各产品均表现出良好的稳定性，在连续12小时高并发测试情况下，均能保持100%的消息处理正确率。

扩展功能专题分析

各产品在文件传输功能、事件消息机制、网络限流方面均能较好的实现。

文件传输功能：通过测试服务器之间的文件传输，统计数据发送和接收正确率，检验是否有文件丢失或重复。

所有产品均能实现文件传输功能。商业产品本身支持文件传输功能，开源产品需通过应用程序实现。

事件消息机制功能：通过在测试时，人为进行网络断连等异常事件，在出现异常事件后消息节点会收到异常事件信息。

所有产品均能实现事件消息机制功能。

网络限流功能：通过调整消息中间件的配置参数，测试允许使用的网络带宽，进行数据传输，检查限流功能。

IBM WMQ对网络限流支持较为全面，能通过消息大小限制、批次传输限制、消息总量限制、内存使用限制、磁盘使用限制等各种配置实现对网络限流功能。

续传重传功能：通过人为断开网络来测试消息中间件的断点续传能力，统计数据发送和接收正确率，检查是否有数据丢失或重复。

除Apollo之外的产品均支持续传重传功能。

Apollo不支持ConnectionControl command处理，不能实现自动重连，所以不支持重传功能。预计在Apollo1.8版本中实现该特性。

大文件传输效率：通过进行大文件传输测试消息中间件对大文件传输的支持程度。

IBM WMQ、Oracle JMS、ActiveMQ、Apollo支持大文件传输。

交易一致性：通过验证消息中间件是否支持交易最终一致性。

除Rocket之外的产品均支持交易一致性功能。

延迟队列：通过应用程序设置消息延时时间，在延时时间后消息是否被丢弃或销毁，无法被处理。

除Apollo之外各产品均支持延迟队列功能。

点对点性能测试方面，RabbitMQ、Oracle JMS表现尚可，ActiveMQ、IBM WMQ、RocketMQ略有不足，Apollo差距较大。

订阅性能测试方面，ActiveMQ一枝独秀，表现优秀，RocketMQ、IBM WMQ表现尚可，Oracle JMS、Apollo仍有差距，RabbitMQ差距较大。

水平扩展专题分析：通过两节点、四节点配置进行消息大小1KB、持久化、读写混合的性能测试，得出水平扩展的数据。

从各产品的水平扩展能力来看，RabbitMQ和Rocket的处理能力明显优于其他产品。2节点的处理能力，RabbiMQ和RocketMQ优势较为明显。

点对点性能测试专题分析：通过进行点对点模式，分1K、2K、10K、1M四种消息大小、对8个队列组成的集群进行性能测试。

IBM WMQ在读写混合性能测试中表现优秀，纯写入性能测试表现不理想。

RabbitMQ在持久化方面支持内存复制模式，在纯写入性能测试表现优秀，纯读取性能测试不理想。

ActiveMQ在混合性能测试中表现优秀，纯写入性能测试表现良好，纯读取性能测试表现不理想。

订阅性能测试专题分析：通过进行订阅模式，分1K、2K、10K、1M四种消息大小、对8个队列组成的集群进行性能测试。

ActiveMQ整体表现非常优秀，无论是非持久化还是持久化。

行业实践：RocketMQ 业务集成典型行业应用和实践 本文讲述了 RocketMQ 的业务消息场景、一些功能特性的使用方法，包括事务消息、定时消息、消息全链路灰度等，欢迎大家尝试使用。
技术盘点：消息中间件的过去、现在和未来 目前以“事件驱动”构建的数字化商业生态才刚起步，未来 EventBridge 将围绕事件这一抽象层次实现更强大的能力，比如事件的全链路可观测、事件分析计算、低代码开发等特性，帮助企业全面落地云时代的“事件驱动”架构。
行业实践：RocketMQ 业务集成典型行业应用和实践 本文讲述了 RocketMQ 的业务消息场景、一些功能特性的使用方法，包括事务消息、定时消息、消息全链路灰度等，欢迎大家尝试使用。
阿里云中间件发展历程和开源现状 中间件已经发展多年，其目的主要为通过标准接口和协议解决异构网络环境下分布式应用软件互联和互操作问题。近几年，随着云原生技术的高速发展，云时代对中间件的定义又进行了扩充。2020 年由信通院牵头组织的云原生中间件白皮书对于云原生中间件又提出了 10 项新要求，主要分为底层资源、设计原则、运行时和呈现状态四个维度。阿里巴巴中间件已经有 15 年的发展历史，它与阿里业务一起成长，也是阿里巴巴云原生实践 15 年全程见证者。
NextArch 基金会旗下微服务标准化方案已开源：支持不同开发语言和技术框架 今年，腾讯、字节跳动、快手、BIGO、好未来、七牛云、中国移动、蓝色光标等多达 10 家企业和 go-zero/CloudWeGo/GoFrame/TARS 开源社区的技术专家，在 Linux 下一代架构基金会下成立了微服务技术组 SIG（Special Interest Group），共同探讨微服务治理标准化的解决方案，并向 NextArch 基金会提交了首个落地方案。
云计算情报局预告｜告别 Kafka Streams，让轻量级流处理更加简单 消息的流式计算主要采取接入Flink、Kafka Streams等技术方案，但面对70%以上都是简单流场处理景的需求，传统方案的弊端会被不断放大，客户仍然需要投入较大的人力成本和较高的资源，同时整个架也比较更复杂。消息队列Kafka版 发布Kafka-ETL组件，是一款免运维的流计算组件，基于低代码开发可满足包括格式转换、内容富化、本地聚合、路由分发等常用的数据处理需求。
技术盘点：消息中间件的过去、现在和未来 目前以“事件驱动”构建的数字化商业生态才刚起步，未来 EventBridge 将围绕事件这一抽象层次实现更强大的能力，比如事件的全链路可观测、事件分析计算、低代码开发等特性，帮助企业全面落地云时代的“事件驱动”架构。