消息系统的演进：从 MOM、ESB 到下一代云原生的分布式消息系统

本文介绍了消息系统的发展，从 MOM 到 ESB，到现在以 Pulsar 为代表的下一代云原生的分布式消息系统。从单一的消息传递管道，发展为集消息投递、消息存储和轻量化函数式计算为一体的融合系统。希望为你在消息系统选型时带来一定的帮助。

【本期主要内容】

1、什么是企业消息系统？

2、面向消息的中间件

3、企业服务总线

4、分布式消息系统

什么是企业消息系统？

企业消息系统(Enterprise Messaging System)是提供实现各种消息协议的软件，如 AMQP、MSMQ 等。这些协议支持在企业内部的分布式系统和应用程序之间发送和接收消息。企业消息系统是为了解决远程过程调用（RPC）的一些问题而设计的。在 RPC 架构中，当一个进程想要与远程服务交互时，它首先需要通过服务发现确定服务的位置，然后使用适当的参数远程调用所需的方法。应用程序进行远程调用时，必须等待该调用返回后才能继续处理。

RPC 的同步特性使得基于这种架构的应用程序本身就会变慢。另外，远程服务可能会在一段时间内不可用，这就需要应用开发者使用防御性编程来识别服务是否可用，并做出相应的反应。

企业消息系统则通过引入中间服务，解耦了消息发送者和接收者。通过提供一个标准化和可靠的组件来完成解耦，该组件作为处理数据的持久缓冲区，消息的发送者和接收者不必同时在线。

企业消息系统有一些关键特性

• 异步通信：消息系统允许服务和应用程序以非阻塞的方式相互通信。

• 消息持久化：RPC 的消息只存在于网络上，而发布到消息传递系统中的消息会被持久化，直到它们被成功投递。

• 消息确认：消息系统必须保留消息，直到所有的接收者都收到信息。因此需要一种机制，使消费者能够确认消息的成功投递。这样，消息系统就可以清除所有成功投递的消息。

• 消息消费模式

•     发布订阅模式——支持向一个特定的消息主题生产消息，多个订阅者可能对接收来自特定消息主题的消息感兴趣。

•     消息队列模式——用于消息生产者和消息消费者之间点到点通信。消息生产者将消息发送到由某个名字标识的特定消费者。这个名字实际上对于消费服务中的一个 队列（Queue），在消息传递给消费者之前它被存储在这个队列中。

消息系统已经存在了几十年，并得到了广泛的应用。让我们回顾一下消息系统的演进。

面向消息的中间件

第一类消息系统通常被称为面向消息的中间件(Message Oriented Middleware，MOM)，它的设计目的是在运行于不同网络、操作系统等的分布式系统之间提供进程间通信和应用集成。最著名的 MOM 实现之一是 1993 年发布的 IBM WebSphere MQ。

最早的实现被设计为部署在一台机器上，这意味着系统的可扩展性受限于主机的物理硬件，这台单一的服务器负责处理所有的客户请求和存储所有的消息。这些单服务器 MOM 系统可以服务的并发生产者和消费者的数量受到网卡带宽的限制，存储容量受到机器上物理磁盘的限制。

通过为 MOM 系统中增加集群功能，可以解决可扩展性问题。这使得多个单服务实例可以分担消息的处理，并提供一些负载平衡。尽管 MOM 是集群部署，但实际上每个服务实例负责为所有主题的一个子集提供服务和消息存储。在出现主题"热点"的情况下，分配给该特定主题的实例仍然会成为瓶颈。

这种局限性要求用户必须注意的消息分布，调整主题的分别，使主题与底层物理硬件相匹配，确保负载在集群中均匀分布。更好的做法是，能够将一个主题分布在多台机器上，这正是分布式消息系统所做的事情。

企业服务总线

企业服务总线(Enterprise Service Bus, ESB)出现于本世纪初，当时 XML 是使用基于 SOAP 的 SOA 架构应用的首选消息格式。ESB 的核心概念是 "消息总线"，它是所有应用程序和服务之间的通信通道。这种集中式的架构与面向消息的中间件（MOM）所采用的点对点的集成方式形成了直接对比。

每个应用向 ESB "注册 "自己，并指定一套规则，用于识别它感兴趣的消息，而 ESB 将处理所有必要的逻辑，以便从总线上动态地路由符合这些规则的消息。同样，每个服务不再需要事先知道消息的预定目标，只需将消息发布到 "总线 "上，让它对消息进行路由。每个应用或服务通过 ESB 发送和接收所有消息，而不必指定它们想要发布和消费的特定主题名称。

ESB 在 "流处理 "上迈出了第一步，强调在消息系统内部处理消息的能力。大多数 ESB 提供消息转换服务，通过 XSLT 或 XQuery，处理发送和接收者之间的消息格式转换。这是对消息系统的一种全新的思考方式，在这之前，消息系统几乎只被用作一种传输通道。现在 ESB 都支持更先进的计算功能，包括业务流程编排、事件关联和模式匹配等复杂事件处理。

ESB 在今天仍然非常流行，但它们是集中式系统，被设计成部署在单台主机上。ESB 和 MOM 一样，同样存在着可扩展性的问题。

分布式消息系统

随着 Hadoop 的普及，分布式计算模式开始被广泛采用。分布式计算最大的一个优势就是，只需在系统中增加新的机器，就可以横向扩展系统。新的系统架构将计算和存储分离，并且分布在多台机器上，不再受单机物理硬件的限制。

消息系统已经向分布式计算模式过渡。当前最流行的 Kafka，以及最近崛起的 Pulsar 都采用了分布式计算模式，以满足互联网、大型企业对可扩展性和性能的需求。

在分布式消息系统中，一个主题被分布在多台机器上，以便在消息层提供水平可扩展的存储。将数据分布存储还提供了一些优势，包括数据的冗余和高可用性，增加了消息的存储容量，增加了消息吞吐量，以及消除了系统内的单点故障。

分布式消息系统和集群式单节点系统在架构上的关键区别，是存储层的设计方式。在以前的单节点系统中，主题的消息数据都被存储在一台机器上，这将主题的大小限制在该机器上磁盘容量大小。在分布式消息系统中，数据分布在集群内的多台机器上。

分布式消息系统的另一个好处是，可以有多个 broker 为给定的主题提供消息服务，通过将负载分散在多台机器上，提高了消息的生产和消费吞吐量。

我们以新近崛起的 Pulsar 为例，它就是典型的分布式消息系统架构。Pulsar 使用了存储和计算分离的云原生架构，数据从 Broker 搬离，存在共享存储内部。上层是无状态 Broker，复制消息分发和服务；下层是持久化的存储层 Bookie 集群。Pulsar 存储是分片的，这种构架可以避免扩容时受限制，实现数据的独立扩展和快速恢复。Pulsar 解决了 Kafka 在设计上的一些并不能很好地适应于云原生环境的缺陷，比如消息服务和消息存储的紧耦合、IO 并不隔离、基于物理分区的存储模型等。Pulsar 还内置了一个轻量级计算引擎，为用户提供了一个部署简单、运维方便的 FaaS（Function as a service）平台。

【本期作者】马震，金蝶天燕中间件产品部架构师，负责应用服务器产品的研发工作。