消息代理

menu icon

消息代理

消息代理是一种应用间通信技术,用于帮助构建公共集成机制,以支持云原生、基于微服务、无服务器以及混合云架构。

什么是消息代理?

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

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

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

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

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

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

消息代理模型

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

  • 点到点消息传递:这是消息队列中使用的分发模式,消息的发送方和接收方之间存在一对一关系。 队列中的每条消息都只发送到一个接收方,并且仅被使用一次。 如果消息必须仅处理一次,那么会调用点到点消息传递。 这种消息传递样式的适当用例的示例包括工资单和金融交易处理。 在这些系统中,发送方和接收方都需要保证每次付款发送一次,仅且一次。
  • 发布/预订消息传递:这种消息分发模式通常称为“发布/预订”,每条消息的产生方将其发布到主题,多个消息使用方预订要从中接收消息的主题。 发布到主题的所有消息都将分发到预订它的所有应用。 这是一种广播式分发方法,消息的发布方与使用方之间存在一对多关系。 例如,如果一家航空公司要发布关于其航班的着陆时间或延迟状态的更新,那么多个当事方可以利用这些信息: 执行飞机维修和加油的地面人员;准备飞机的下一次旅行的行李处理员、乘务员和飞行员;以及通知公众的视觉显示器的操作员。 发布/订阅消息传递样式适合在此场景中使用。

云架构中的消息代理

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

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

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

消息代理 vs. API

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

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

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

消息代理 vs 事件流平台

消息代理可支持两个或更多消息传递模式(包括消息队列和发布/预订),而事件流平台仅提供发布/预订样式的分发模式。 事件流平台旨在用于大量消息,易于扩展。 它们能够将记录的流排序为称为主题的类别,并将其存储预先确定的时间长度。 但是,与消息代理不同,事件流平台无法保证消息送达,也无法跟踪哪些使用者已收到消息。

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

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

消息代理 vs ESB(企业服务总线)

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

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

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

消息代理用例

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

消息代理通常用于以下用途:

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

消息代理和 IBM Cloud

随着企业在云之旅中对应用进行现代化改造,消息代理的重要性又有了新的含义。许多世界上最成功的企业,包括 85% 的《财富》100 强企业,依赖于 IBM 的消息代理功能,这些功能支持当今的敏捷开发环境、基于微服务的混合云基础架构,以及一系列广泛的系统类型和连接需求。

采取下一步行动: 了解有关 IBM Cloud Pak for Integration 的信息,这是基于 IBM MQ 的核心功能的领先的企业消息传递解决方案。

立即开始使用 IBM Cloud 帐户