消息中间件

定义

消息中间件是指在应用层与平台层之间起连接作用的一层软件，其英文名称为面向消息的中间件(Message-Oriented Middleware)，缩写为 MOM。使用该层之后，在不同网络节点上独立开发、运行于不同平台的软件组件可以通过应用程序接口彼此通信，无需了解对方的操作系统与底层网络服务细节^[1]。

在中间件的分类中，它与基于远程过程调用的中间件、基于对象请求代理的中间件并列。区别在于后两者建立的是紧耦合的组件系统，调用方必须等待被调用方返回；而消息中间件允许组件之间以异步方式交换消息，耦合度更松^[4]。国内也有文献把它的主要功能概括为在应用程序之间传递消息，并处理网络通信中的传输可靠性、传输效率与系统可靠性等问题^[5]。

从组成上看，这类系统的基本元素是客户端、消息和消息提供者，提供者一般由接口与管理工具构成。提供者可以采用集中式消息服务器，也可以把路由与投递功能分布到各个客户端上，部分产品把两种方式结合使用^[4]。

原理

消息由消息头与消息正文构成，消息头携带路由等控制信息，正文存放需要传输的数据；目的地则是一个有名称的消息存储仓库。发送方将消息投递到目的地后即可继续处理其他工作，接收方在自身可用时再取走消息，从而在时间维度上把生产与消费分开^[6]。消息提供者负责消息的存储、路由与投递，即便个别组件或连接出现故障，系统仍可继续运行^[1]。

两种常见的通信模型是点对点与发布订阅。点对点模型中，一条消息由队列中的一个消费者取走；发布订阅模型又称主题模式，生产者发布一次，所有订阅该主题的消费者都能收到副本，因此发布订阅模式在 20 世纪 80 年代即被提出用于解决软件之间的通信问题^[7]。以 AMQP 为代表的协议进一步引入交换机与绑定规则，交换机根据路由键把消息投递到一个或多个队列^[8]。

投递保证是衡量具体产品的重要指标。最多一次投递在失败时不重试，至少一次投递保证最终送达但可能产生重复，恰好一次投递的保证最强，需要额外的协调机制并会增加时延；持久化订阅与死信队列则用于处理无法投递的消息^[2]。消息堆积通常是消费速度跟不上生产速度所致，常见处置方式是扩充消费者或调整队列、分区数量。

flowchart LR

P[生产者] -->|发布消息| B[消息提供者：存储与路由]

B --> Q1[队列A]

B --> Q2[主题B]

Q1 --> C1[消费者1]

Q2 --> C2[消费者2]

Q2 --> C3[消费者3]

发展历程

有资料将消息队列的发展追溯至 20 世纪 80 年代，当时出现了被视作第一款消息队列的 The Information Bus，它首次把发布订阅模式用于解决软件之间的通信问题；也有说法称其实现者为 1983 年创办的 Teknekron 公司^[3][9]。20 世纪 90 年代进入商业软件厂商主导的时期，IBM、Oracle、微软等相继推出各自的 MQ 产品，其中 IBM MQ 最具代表性，价格较高，主要面向大型金融、电信企业，交付方式多为软硬件一体机，架构上以单机为主^[10]。IBM MQ 于 1993 年推出，最初名为 MQSeries，2002 年更名为 WebSphere MQ，2014 年 4 月改称 IBM MQ^[11]。

2000 年至 2007 年前后，初代开源消息队列兴起，形成了 JMS 与 AMQP 两大标准，对应的代表实现分别是 ActiveMQ 与 RabbitMQ。JMS 通过统一的 Java 接口屏蔽各厂商的专有接口，AMQP 则从网络传输的数据格式层面作出规定，因此不受开发语言限制^[12]。开源降低了使用门槛，使消息队列逐渐成为企业架构的常见组件，但这一时期的产物主要面向传统企业应用与小流量场景，横向扩展能力较弱^[3]。

2007 年之后，随着互联网用户规模与数据量增长，传统产品难以承受亿级访问流量，采用分布式架构的互联网消息中间件出现，代表有 Kafka 与 RocketMQ^[10]。Kafka 由领英(LinkedIn)于 2011 年初开源，以高吞吐、低时延处理实时数据流，并把消息中间件的应用范围从异步解耦延伸到流存储与流计算^[11]。2014 年以后，云计算、物联网与云原生成为新的技术背景，消息队列的能力向边缘机房与终端设备延伸，支持 MQTT 等物联网协议逐渐成为各产品的常见配置^[13]。

应用

最常见的用途是系统解耦、异步处理与削峰填谷。系统之间不再直接调用接口，而是把事件写入消息队列由下游按需订阅，从而减少彼此的依赖；请求链路中非核心的环节可以转为异步处理，缩短主流程耗时；面对秒杀、抢红包等活动带来的流量脉冲，队列充当缓冲区，让后端按自身处理能力消费，避免被瞬时流量压垮^[7][14]。这些能力在单体应用拆分为微服务之后尤其常用，成为微服务之间通信的基础设施^[15]。

在交易类系统中，消息中间件常用于订单状态流转、支付结果通知等环节，事务消息可以把本地数据库操作与下游通知放进同一套流程，定时消息则用于处理超时状态等场景^[16]。金融行业对每笔交易的可靠性要求较高，因此对消息的可靠传输、并发能力和容灾能力有较严格的要求^[17]。此外，在多系统集成场景中，消息队列也被用于在功能重复或结构不同的既有系统之间传递数据^[4]。

在物联网与移动互联网领域，轻量级的发布订阅协议被用于连接终端与云端，承担连接接入、连接管理与数据转发，适用于车联网、智能家居、移动直播等场景^[18]。而在大数据方向，Kafka 一类产品被广泛用于日志收集、监控数据聚合与流式数据处理^[19]。

局限

引入消息中间件会带来架构上的代价。系统增加一个外部依赖后，可用性相应下降，消息服务本身故障时会影响整条链路；同时需要额外考虑重复消费、消息丢失、顺序性等问题，系统的复杂程度明显上升^[14]。一致性也是常见难点：上游处理完成后即向用户返回成功，若下游某个环节消费失败，就可能出现数据不一致^[20]。

异步模型还有其固有短板。远程过程调用要等被调用方完成后才返回，而异步系统中调用方会不断向接收方堆积工作，直至资源耗尽、被调用组件失效，因此需要靠性能监控与流量调节来控制^[4]。各产品的能力也存在取舍：RabbitMQ 的可靠性机制较重，吞吐量相对较低，生产环境容易出现消息积压；Kafka 吞吐量高，但可靠性主要依赖多副本，相比前者仍有差距^[21]。部分产品还存在功能与扩展上的限制，例如传统集群方式扩展性有限，扩容往往需要迁移分区并占用带宽^[22]。

选型时需要权衡投入与收益。消息队列通常更适合具备一定流量规模、确有解耦或削峰需求的系统，流量不大的系统保持简单架构往往更为稳妥^[7]。此外，不同产品的可靠性、吞吐量与功能侧重各异，需要结合具体业务场景确定^[21]。

参见

• 中间件 —— 消息中间件所属的基础软件类别，位于应用与操作系统之间。

• 消息队列 —— 消息中间件的核心抽象，用于暂存和转发消息。

• Java消息服务 —— 面向 Java 平台的消息访问接口标准，屏蔽各厂商专有接口。

• AMQP —— 规定消息传输数据格式的开放协议标准，RabbitMQ 是其代表实现。

• Apache Kafka —— 采用分布式日志结构的消息与流处理平台。

• 发布订阅模式 —— 一条消息分发给多个订阅者的事件分发模型。