消息队列
黑蓝背景
什么是消息队列?

消息队列是消息传递中间件解决方案的一个组件,支持应用和服务之间独立地交换信息。 消息队列按发送顺序来存储“消息” — 由应用所创建的供其他应用使用的数据包 — 直到使用它们的应用能够处理它们为止。 这使消息能够安全地等待,直到接收它们的应用准备好为止,因此,在网络或接收它们的应用出现问题时,消息队列中的消息不会丢失。

这种被称为异步消息传递的模式可以防止数据丢失,并使系统能够在进程或连接失败时继续工作。 这使开发人员能够保进程和应用相分离,从而保持它们的通信是独立的、由事件驱动的,导致架构更可靠。

消息队列可用于跨越众多部署模式的消息传递解决方案,包括经过优化处理的物理设备云服务大型机和作为软件使用。


优点

消息队列解决方案广泛应用于各行各业,可以同时为开发人员和系统管理员提供一系列优势,包括:

  • 可靠的消息交付:使用消息队列可以确保应用之间的业务关键型消息不会丢失,并且只被一次性地传递给接收方。 该特性消除了对额外的重复数据删除或防预防逻辑的需求。
  • 应用间连接:一些消息队列解决方案可以处理应用和服务之间的消息加密、事务性和其他通信任务。 这简化了应用开发,并使不同的架构能够一起工作。
  • 多功能性:消息队列解决方案可以支持多种语言,如Java、Node.js、COBOL、C/C++、Go、.NET、Python、Ruby 和 C#。 它们还可以支持多种应用编程接口 (API) 和协议,包括 MQTT、AMQP 及REST等。
  • 弹性:异步消息传递可确保特定于应用的故障不会影响到系统。 当系统中的一个组件停止工作时,所有其他组件都可以继续与队列交互并处理消息。 这就降低了由于某一部分的故障而影响到整个系统稳定性的可能性。
  • 改进安全性:消息队列可能能够识别和验证所有消息,并且某些消息队列解决方案允许设置为对消息进行静止时、传输中或端到端加密。 这有助于提高应用和/或基础结构的整体安全性。
  • 集成式文件传输:一些消息队列解决方案包含附加功能,如传输文件的能力。 因此可以用来替换企业中使用的 FTP。

客户案例

当今的企业计算环境复杂且高度分散。 消息传递提供单一、健壮和安全的共享消息传递主干,使得在不同平台上集成应用和服务变得更容易。 这可以防止数据丢失,甚至能够确保系统在连接不稳定的情况下继续工作。

消息队列特别适合于将本地后端系统与云服务集成。 在云架构中,应用通常被分解成独立的小组件。 这使得我们更容易对其进行设计和编码,也更容易管理其性能。 消息队列使这些解耦的基于云的解耦应用能够彼此通信或与本地系统通信。

消息排队因为消息可以具有持久性而增强了架构弹性。 这意味着消息将被存储到磁盘,直到接收消息的服务确认可以处理它们为止。 消息传递队列可用于需要高级别安全性、容错性和准确性的场景,例如金融事务处理、机票预订或更新患者病例。

消息队列还可用于支持驻留在不同云(无论是公共云还是私有云)中的应用和系统进行通信,即使它们位于不同的国家甚至不同的大陆也不例外。 使用消息队列可以提高容错性,并可用于防止数据在地理位置和技术上完全不同的系统上出现重复或丢失问题。 因为系统中的每个服务都是解耦的,或者在逻辑上与其他服务相分离,因此,无论哪个服务或应用出现故障或停止工作,其他服务都可以继续工作。

消息队列可以作用于不同的应用,如移动、物联网和传统的交易系统记录。 它们还支持各种平台 — 如虚拟机容器 — 并支持遗留应用和当前最新解决方案之间的集成。


消息队列与…

消息队列与发布/订阅
消息队列使用点对点消息传递模式,其中一个应用(称为发送方)向队列提交消息,另一个应用(称为接收方)从队列中获取消息并使用它。 发送者和使用者之间应建立紧密耦合的一对一关系,并且每个消息应该只被使用一次。

如果您的应用需要将消息分发给多个接收方,您可以选择组合多个消息队列,也可以使用发布/订阅 (pub/sub) 消息传递模式。

在发布/订阅消息传递中,生成消息的应用称为发布者,使用消息的应用称为订阅者。 每个消息都被发布到一个主题,订阅该主题的每个应用都会获得发布到该主题的所有消息的副本。

大多数的消息传递中间件解决方案都同时支持消息队列(点对点)和发布/订阅消息传递模式。

消息队列与消息传递总线
消息传递总线是一类企业服务总线 或 ESB,允许服务无处不在地访问数据,同时确保它们在分布式系统架构中保持解耦和独立运行。 当您使用消息总线时,所有的服务或应用必须共享通用数据类型、通用命令集和通用通信协议,尽管它们可能是使用不同语言编写的。 消费者可以决定他们如何使用消息。

如果解耦的应用希望通过消息传递总线进行通信,则必须对消息进行转换,以便它们都是相同类型的消息。 而消息队列则负责传输消息,无论它们是相同类型还是不同类型。

消息队列与 web 服务
应用可以通过web 服务或基于标准协议的 API 直接通信,如简单对象访问协议 (SOAP) 或 HTTP,而不是通过消息传递中间件进行通信。 Web 服务广泛应用于分布式系统中,相对而言简单且易于实施,这使得它们在某些用例和场景中成为消息队列的可行替代方案。

但是,与消息队列不同,web 服务不能保证消息传递。 如果服务器或连接失败,您将必须能够处理客户端错误。 Web 服务还缺乏发布/订阅-分发模式。 消息传递中间件提供了更大的容错性和更好的能力来处理繁忙的通信或活动突发。

如想详细了解何时使用 API、何时使用消息传递或何时将二者结合使用,请参阅“API 和消息传递简介。”

消息队列与数据库
在某些情况下,数据库可以用作消息队列的替代方案,但在大多数情况下,它们用于不同的目的,并且不能轻易互换。 数据库最常用于存储目的,允许您一遍又一遍地访问相同的信息。 消息队列不能被用于存储目的。 一旦消息被使用,就会从队列中删除。

您也许能够在数据库中设计类似消息队列的功能,但这需要大量的编码工作和知识。 数据库只能用于复制简单的队列结构,不能通过扩展来支持较大的应用。 

参阅“数据库格局概述”,了解有关数据库及其功能的更多信息。


Message-queuing-as-a-service

消息排队传统上是由 IT 部门的专门团队负责管理的。 但是,“即服务”交付 — 使用云托管消息队列 — 允许个人或业务部门 (LOB) 用户通过门户来请求自己更改消息传递基础结构,从而提高了敏捷性。

消息队列即服务自然适用于在云原生开发环境中常见的无服务器微服务架构。 因为它是在云托管服务模式中提供的,因此,云提供商负责为您处理消息传递基础架构的所有调配、安装和维护任务,并将它托管在云中。


教程

如果您对开发使用 IBM MQ 进行通信的应用还不熟悉,那么,这些教程将对您有所帮助:

这些额外的资源将给您提供更全面的信息:


消息队列和 IBM

IBM 消息队列解决方案支持混合云环境、敏捷开发流程和微服务架构,具有一体化消息传递主干,使开发人员的工作变得更轻松。 当企业在云计算的旅程中开启应用现代化任务时,这一点尤为重要。

采取下一步行动:

立即创建 IBM Cloud 账户 以使用该产品。


相关解决方案

混合云解决方案

了解利用 IBM Cloud 构建的混合云解决方案如何帮助组织迁移到云端,实现现有应用现代化,并构建新的云原生应用。


自动集成

将应用、服务和数据连接到市场上最全面的集成平台 IBM Cloud Pak for Integration。