消息代理是使应用、系统和服务能够相互通信和交换信息的软件。 消息代理通过在正式消息传递协议之间转换消息来执行此功能。 它支持相互依赖的服务直接相互“交谈”，即使它们以不同的语言编写或在不同的平台上实施。

消息代理是消息传递中间件或面向消息的中间件 (MOM) 解决方案中的软件模块。 这种类型的中间件为开发人员处理应用组件之间的数据流动提供了一种标准化方法，从而使他们能够集中精力开发核心逻辑。 它可以充当分布式通信层，支持涉及多个平台的应用的内部通信。

消息代理可验证、存储、路由消息，以及将消息传递到相应的目的地。 它们充当其他应用之间的中介，支持发送方在不知晓接收方所在位置的情况下发出消息，无论接收方是否活跃，也无论有多少接收方。 这有助于对系统内的流程和服务进行解耦。

为了提供可靠的消息存储和保证消息送达，消息代理通常依赖名为消息队列的子结构或组件，它用于存储消息并进行排序，直到使用方应用能够处理这些消息为止。   在消息队列中，消息按发送时的确切顺序进行存储，并保留在队列中，直到确认接收为止。

异步消息传递 (15:11) 是指消息代理可使用的应用间通信的一种类型。 它有助于防止丢失有价值的数据，使系统能够持续正常运行，即使面对公共网络上常见的间歇性连接或延迟问题也不例外。  异步消息传递保证消息以相对于其他消息的正确顺序传递一次（且仅一次）。

消息代理可能包含队列管理器，用于处理多个消息队列之间的交互，还可能包含用于提供数据路由、消息转换、持久性和客户端状态管理等功能的服务。

消息代理提供两种基本的消息分发模式或消息传递样式：

点到点消息传递：这是消息队列中使用的分发模式，消息的发送方和接收方之间存在一对一关系。  队列中的每条消息都只发送到一个接收方，并且仅被使用一次。 如果消息只能被处理一次，那么会调用点到点消息传递。 这种消息传递样式的适当用例包括工资单和金融交易处理。 在这些系统中，发送方和接收方都需要保证每次付款发送一次，且仅一次。

发布/预订消息传递：这种消息分发模式通常称为“发布/预订”，每条消息的产生方将其发布到主题，多个消息使用方预订要从中接收消息的主题。  发布到主题的所有消息都将分发到预订它的所有应用。 这是一种广播式分发方法，消息的发布方与使用方之间存在一对多关系。 例如，如果某航空公司打算发布关于降落时间或航班延误状态的更新信息，以下多个参与方可使用这些信息：负责飞机维护和加油的地勤人员、行李处理人员、准备飞机下次飞行的空乘人员和飞行员，以及通过可视方式通知公众的操作人员。 发布/订阅消息传递样式适合在此场景中使用。

云原生应用旨在利用云计算的固有优点，包括灵活性、可扩展性和快速部署能力。   这些应用由称为微服务的小型、分散的可复用组件构成。  每个微服务部署后都可相互独立地运行。 这意味着可以更新、扩展或重新启动其中的任何微服务，而不会影响系统中的其他服务。 微服务通常打包成容器，多个微服务协同工作以构成完整应用，而每个微服务都具有自己的技术栈，包括可能各不相同的数据库和数据模型。

微服务必须具有相互沟通的方法，才能协同运行。 消息代理是微服务用来创建这种共享通信主干的机制。

消息代理通常用于管理混合云环境中的本地系统和云组件之间的通信。   使用消息代理可加强对服务间通信的控制，确保在应用的组件之间安全可靠地发送数据。 消息代理可以在集成多云环境中发挥类似的作用，从而支持驻留在不同平台上的工作负载和运行时之间的通信。   它们也非常适合在无服务器计算中使用，在这种情况下，各个云托管的服务都基于请求按需运行。 

REST API 通常用于微服务之间的通信。 术语“具象状态传输”(REST) 定义了开发人员在构建 Web Service 时可遵循的一系列原则和约束。 任何遵循 REST 的服务都能够通过一组统一的共享无状态操作程序和请求进行通信。 应用编程接口 (API) 表示底层代码，如果它符合 REST 规则，那么支持服务彼此通信。

REST API 使用超文本传输协议 (HTTP) 进行通信。 由于 HTTP 是公共互联网的标准传输协议，因此 REST API 广为人知、使用频繁，而且具有广泛的互操作性。 但是，HTTP 是请求/响应协议，因此最好在调用同步请求/应答的情境中使用。 这意味着通过 REST API 发出请求的服务必须设计为预期能够立即响应。 如果接收响应的客户端关闭，那么在等待应答时，将会阻止发送服务。 故障转移和错误处理逻辑应构建到这两种服务中。

消息代理支持服务之间的异步通信，因此发送服务不必等待接收服务的应答。 这提高了使用服务的系统中的容错能力和弹性。 此外，使用消息代理更便于扩展系统，这是因为发布/预订消息传递模式可稳定地支持数量不断变化的服务。 消息代理还跟踪使用者的状态。

消息代理可支持两种或更多消息传递模式（包括消息队列和发布/预订），而事件流平台仅提供发布/预订样式的分发模式。 事件流平台旨在用于处理大量消息，且易于扩展。 它们能够对记录流进行排序，列入名为主题的不同类别，然后根据预先确定的时间长度进行存储。 但是，与消息代理不同的是，事件流平台无法保证消息送达，也无法跟踪哪些使用者已收到消息。

与消息代理相比，事件流平台具有更高的可扩展性，但确保容错（如消息重新发送）方面的功能更少，并且消息路由和排队功能也比较有限。

了解有关事件驱动型架构的更多信息。 

 企业服务总线 (ESB) 是一种架构模式，有时用于企业中实施的面向服务的架构 (SOA)。  在 ESB 中，一个集中式软件平台将通信协议和数据格式组合成一种“通用语言”，由架构中的所有服务和应用共享。 例如，它可将接收的请求从一种协议（如 XML）转换为另一种协议（例如 JSON）。 ESB 使用自动化过程转换消息有效内容。 这种集中式软件平台还处理其他编排逻辑，如连接、路由和请求处理。

但是，ESB 基础架构比较复杂，难以集成，而且维护成本高昂。 当 ESB 在生产环境中出现问题时，很难进行故障诊断，ESB 也不易于扩展，而且更新过程冗长。

消息代理是 ESB 的“轻量级”替代项，它提供类似的功能 - 一种用于在服务间通信的机制，但更简单，成本更低。 随着 ESB 的热度不再，消息代理非常适合在越来越普遍的微服务架构中使用。

实施消息代理可满足各行各业、各种企业计算环境中的广泛业务需求。 无论何时何地，只要需要可靠的应用间通信和有保证的消息送达，就可以使用消息代理。

消息代理通常用于以下方面：

• 金融交易和支付处理： 确保支付发送一次且仅一次至关重要。 通过使用消息代理处理这些交易的数据，可保证支付信息不会丢失，也不会意外复制，此外还提供收据证明，并支持系统可靠地进行通信，即使中间网络中断也不例外。
  
  
• 电子商务订单处理与履行： 如果您在线开展业务，那么品牌声誉取决于网站和电子商务平台的可靠性。 消息代理能够提高容错能力，保证消息使用一次且仅一次，这使其成为处理在线订单自然而然的选择。
  
  
• 保护静态存储和动态传输中的高度敏感数据：如果您所在行业受到严格管制，或您的业务面临重大安全风险，那么就需要选择具有端到端加密功能的消息传递解决方案。