主页
topics
消息代理
消息代理是一种软件，它使应用程序、系统和服务能够相互通信并交换信息。
消息代理通过在正式消息传递协议之间转换消息来实现这一功能。这使得相互依赖的服务可以直接与彼此“对话”，即使它们是用不同语言编写或在不同平台上实现的。
消息代理是消息传递中间件或面向消息的中间件 (MOM) 解决方案中的软件模块。这种类型的中间件为开发人员提供处理应用程序组件之间数据流的标准化方法，以便他们可以专注于核心逻辑。它可以作为分布式通信层，允许跨越多个平台的应用程序进行内部通信。
消息代理可以验证、存储、路由并将消息传递到适当的目的地。它们充当其他应用程序之间的中介，允许发送者在不知道接收者位置、接收者是否处于活动状态或接收者数量的情况下发出消息。这有助于在系统内解耦流程和服务。
为了提供可靠的消息存储和有保证的传递，消息代理通常依赖于称为消息队列的子结构或组件来存储和对消息排序，直到使用的应用程序可以进行处理。在消息队列中，消息按照传输的准确顺序存储，并保留在队列中，直到确认接收为止。
异步消息传递是指消息代理可以实现的应用程序间通信类型。它可以防止宝贵的数据丢失，并使系统即使面对公共网络上常见的间歇性连接或延迟问题也能继续运行。异步消息传递保证消息将按相对于其他消息的正确顺序传递一次（且仅一次）。
消息代理可能包括队列管理器，以处理多个消息队列之间的交互，以及提供数据路由、消息转换、持久化和客户端状态管理功能的服务。
了解智能自动化如何为您的业务运营带来竞争优势。
消息代理提供两种基本的消息分发模式或消息传递样式：
点对点消息传递：这是消息队列中使用的分发模式，消息的发送者和接收者之间存在一对一关系。队列中的每条消息仅发送给一个接收者，并且仅使用一次。必须仅对消息执行一次操作时，会调用点对点消息传递。这种消息传递样式的合适用例示例包括薪资和财务交易处理。在这些系统中，发送者和接收者均需保证每笔付款只发送一次。
发布/订阅消息传递：在这种消息分发模式（通常称为“发布/订阅”）中，每条消息的创建者将其发布到一个主题，多个消息使用者订阅他们想要从中接收消息的主题。发布到某个主题的所有消息都会分发到订阅该主题的所有应用程序。这是一种广播式分发方法，其中消息的发布者与使用者之间存在一对多关系。例如，如果一家航空公司要发布有关航班落地时间或延误状态的更新信息，则多方可以利用这些信息：执行飞机维护和加油的地勤人员、行李搬运工、为飞机下一次飞行做准备的乘务员和飞行员，以及通知公众的视觉显示器操作员。在这种情况下，适合采用发布/订阅消息传递样式。
云原生应用程序旨在利用云计算的固有优势，包括灵活性、可扩展性和快速部署。这些应用程序由称为微服务的小型、独立、可重复使用的组件组成。每个微服务都已部署，可以独立运行。这意味着可以更新、扩展或重新启动其中任何一项服务，而不会影响系统中的其他服务。微服务通常封装在容器中，它们协同工作以构成完整的应用程序，不过每个微服务都有自己的堆栈，包括可能与其他微服务不同的数据库和数据模型。
微服务必须具有相互通信的方式，以便协同工作。消息代理是它们用来创建此共享通信主干的一种机制。
消息代理通常用于管理混合云环境中本地系统和云组件之间的通信。使用消息代理可以增强对服务间通信的控制，确保在应用程序组件之间安全、可靠、高效地发送数据。消息代理可以在集成多云环境方面发挥类似作用，实现驻留在不同平台上的工作负载和运行时之间的通信。它们也非常适合用于无服务器计算，在无服务器计算中，各个云托管服务根据请求按需运行。
REST API 通常用于微服务之间的通信。术语“代表性状态传输 (REST)”定义开发人员在构建 Web 服务时可以遵循的一组原则和约束。任何遵守这些原则和约束的服务都将能够通过一组统一的共享无状态算子和请求进行通信。应用程序编程接口 (API) 是指底层代码，如果符合 REST 规则，则允许服务相互通信。
REST API 使用超文本传输协议 (HTTP) 进行通信。由于 HTTP 是公共互联网的标准传输协议，因此 REST API 广为人知、使用频繁且具有广泛的互操作性。但是，HTTP 是一种请求/响应协议，因此最适合在需要同步请求/回复的情况下使用。这意味着通过 REST API 发出请求的服务必须设计为期望立即获得响应。如果接收响应的客户端关闭，则发送服务将在等待回复时被阻止。两种服务都应内置故障转移和错误处理逻辑。
消息代理支持服务之间的异步通信，以便发送服务无需等待接收服务的回复。这可以提高所采用系统的容错能力和弹性。此外，使用消息代理可以更轻松地扩展系统，因为发布/订阅消息传递模式可以随时支持不断变化的服务数量。消息代理还会跟踪使用者的状态。
虽然消息代理可以支持两种或多种消息传递模式，包括消息队列和发布/订阅，但事件流平台仅提供发布/订阅式分发模式。事件流处理平台专为处理大量消息而设计，易于扩展。它们能够将记录流按类别（称为“主题”）排序，并在预定时间内存储这些记录。然而，与消息代理不同，事件流平台无法保证消息传递或跟踪哪些使用者已收到消息。
事件流平台提供的可扩展性比消息代理更高，但确保容错的功能（如消息重新发送）较少，并且消息路由和排队功能更加有限。
了解有关事件驱动型架构的更多信息。
企业服务总线 (ESB) 是一种架构模式，有时用于跨企业实现的面向服务的架构 (SOA)。在 ESB 中，集中式软件平台将通信协议和数据格式组合成架构中所有服务和应用程序可以共享的“通用语言”。例如，它可以将从一种协议（例如 XML）接收的请求转换为另一种协议（例如 JSON）。ESB 使用自动化流程转换消息有效负载。集中式软件平台还处理其他编排逻辑，例如连接、路由和请求处理。
然而，ESB 基础设施非常复杂，集成起来可能很困难，维护成本高昂。当生产环境中出现问题时，很难对它们进行故障排除，它们不易扩展，并且更新也很繁琐。
消息代理是 ESB 的“轻量级”替代方案，它以更简单、更低成本提供类似功能（一种服务间通信机制）。它们非常适用于微服务架构，因为随着 ESB 逐渐不受欢迎，微服务架构变得越来越流行。
实施消息代理可以满足各个行业和不同企业计算环境中的各种业务需求。无论何时何地，只要需要可靠的应用程序间通信和有保证的消息传递，它们都非常有用。
消息代理通常通过以下方式使用：
- 金融交易和付款处理：重要的是，要确保只发送一次付款。使用消息代理处理这些交易数据可以保证支付信息既不会丢失也不会意外重复，提供收据证明，而且，即使在中间网络出现故障时，系统也能可靠地进行通信。
- 电子商务订单处理和履行：如果您在线开展业务，那么您品牌声誉的强度取决于您的网站和电子商务平台的可靠性。消息代理能够增强容错能力并保证消息只使用一次，这使得它们成为处理在线订单的自然选择。
- 保护静态和传输中的高度敏感数据：如果您所在行业受到严格监管或者您的业务面临重大安全风险，请选择具有端到端加密功能的消息传递解决方案。