什么是 Azure 服务总线?

Azure 服务总线是一个完全托管的企业消息代理,其中包含消息队列和发布订阅主题。 服务总线用于分离应用程序和服务,提供以下优势:

  • 跨争用工作节点实现工作负载均衡
  • 跨服务和应用程序边界安全路由和传输数据和控制
  • 协调需要高度可靠性的事务性工作

概述

数据通过消息在不同的应用程序和服务之间传输。 消息是用元数据修饰的容器,它包含数据。 数据可以是任何类型的信息,包括以常用格式编码的结构化数据,例如:JSON、XML、Apache Avro 和纯文本。

一些常见的消息传送方案包括:

  • 消息。 传输业务数据,例如销售或采购订单、日志或库存变动。

  • 分离应用程序。 提高应用程序和服务的可靠性和可伸缩性。 生产者和使用者不必同时处于联机或可用状态。 负载平衡,使流量高峰不会使服务负担过重。

  • 负载均衡。 允许多个竞争性使用者同间从队列读取内容,每个使用者都安全地获取对特定消息的独占所有权。

  • 主题和订阅。 在发布服务器和订阅服务器之间启用 1:n 关系,使订阅服务器可以从已发布的消息流中选择特定消息。

  • Transactions。 允许你执行多个操作,所有操作都在原子事务的作用域中执行。 例如,可以在事务的作用域中执行以下操作。

    1. 从一个队列获取消息。
    2. 将处理结果发布到一个或多个不同的队列。
    3. 从原始队列移动输入消息。

    仅在成功时才对下游使用者显示结果,包括成功处置输入消息,允许使用一次性处理语义。 对于更大的解决方案上下文中的补偿事务模式,此事务模型是一个可靠的基础。

  • 消息会话。 对于需要严格消息排序或消息延迟的工作流和多路复用传输,实现大规模协调。

如果熟悉 Apache ActiveMQ 等其他消息代理,服务总线的概念与你已知的概念相似。 服务总线是一个平台即服务 (PaaS) 产品,一个关键区别在于你不用担心以下操作。 Azure 会为你完成这些琐事。

  • 担心硬件失败
  • 持续修补操作系统或产品
  • 存放日志和管理磁盘空间
  • 处理备份
  • 故障转移到保留计算机

概念

本部分讨论服务总线的基本概念。

队列

消息可以发送到队列,也可以从其接收。 在能够使用接收应用程序接收并处理消息之前,可以通过队列来存储消息。

显示服务总线队列的示意图,其中包含发送消息的发送方和接收消息的接收方。

队列中的消息会排队,并在到达时加盖时间戳。 在该代理接受消息后,消息将始终长期保留在三重冗余存储中;如果命名空间启用了区域,则这些冗余存储会分布在多个可用性区域中。 服务总线将消息保留在内存或易失存储中,直到客户端报告它们已被接受。

消息以拉取模式传送,即仅按请求传送消息。 不同于其他某些云队列的繁忙轮询模式,拉取操作可能会长期存续,消息可用时才会完成。

注意

有关服务总线队列与存储队列的比较,请参阅存储队列和服务总线队列 - 比较与对照

主题

也可通过主题发送和接收消息。 队列通常用于点到点通信,而主题则用于发布-订阅方案。

显示服务总线主题的示意图,其中包含一个发送方和多个接收方。

主题可以有多个独立的订阅,这些订阅附加到主题,其他方面与来自接收方的队列完全一样。 主题的订阅者可以收到发送到该主题的每个消息的副本。 订阅是命名实体。 订阅默认持久存续,但可为其配置过期时间,并在过期后自动将其删除。 通过 Java 消息服务 (JMS) API,服务总线高级版还允许创建在连接期间存在的易失订阅。

你可以定义订阅的规则。 订阅规则有一个筛选器,用于定义要复制到订阅中的消息应满足的条件,以及可以修改消息元数据的可选操作。 有关详细信息,请参阅主题筛选器和操作。 此功能在以下情况下很有用:

  • 不要让订阅接收发送到某个主题的所有消息。
  • 最好在消息通过订阅时使用额外的元数据来标记消息。

注意

有关队列和主题的详细信息,请参阅服务总线队列、主题和订阅

命名空间

命名空间是一个适用于所有消息组件(队列和主题)的容器。 命名空间可以有一个或多个队列和主题,通常充当应用程序容器。

命名空间相当于有关其他中转站的术语中的“服务器”,但这两个概念并不直接等效。 服务总线命名空间是你拥有的容量部分,它属于由数十个全部活跃的虚拟机组成的群集。 它可以选择跨三个 Azure 可用性区域。 因此,你可以获得超大规模运行消息代理的所有可用性和可靠性优势。 而且无需担心底层复杂性。 服务总线是无服务器消息传递。

高级功能

服务总线还有用于解决更复杂消息传送问题的高级功能。 以下部分介绍这些重要功能:

消息会话

若要保证在处理服务总线队列或订阅中的消息时实现先入先出 (FIFO),请使用会话。 会话还可用于实现“请求-响应”模式。 通过“请求-响应”模式,发送方应用程序可以发送请求并为接收方提供将响应正确发送回发送方应用程序的方法。 有关详细信息,请参阅消息会话

自动转发

通过自动转发功能,可将队列或订阅连接到作为相同命名空间组成部分的另一个队列或主题。 启用自动转发时,服务总线会自动删除放置在第一个队列或订阅(源)中的消息,并将其放入第二个队列或主题(目标)中。 有关详细信息,请参阅使用自动转发链接服务总线实体

死信

服务总线队列和主题订阅将提供一个名为死信队列 (DLQ) 的辅助子队列。 死信队列可存放无法传递给任何接收方的消息或无法处理的消息。 然后,可从 DLQ 中删除这些消息并对其进行检查。 在操作员的帮助下,应用程序可能会纠正问题并重新提交消息,记录存在错误的事实,并采取纠正措施。 有关详细信息,请参阅服务总线死信队列概述

计划的传递

可以将消息提交到队列或主题,以便进行延迟处理。 例如,用来计划作业,以使其在特定时间可供系统处理。 有关详细信息,请参阅计划的消息

消息延迟

当队列或订阅客户端收到一条它愿意处理,但由于应用程序中出现特殊状况而目前无法处理的消息时,该实体可将消息的检索延迟到将来的某个时间点。 该消息将保留在队列或订阅中,但会搁置处理。 有关详细信息,请参阅消息延迟

事务

一个事务将两个或更多操作组合成执行作用域。 服务总线支持对事务作用域内的消息传送实体(队列、主题、订阅)执行分组操作。 有关详细信息,请参阅服务总线事务处理概述

筛选器和操作

订阅者可以定义他们希望从主题接收的消息。 这些消息采用一个或多个命名订阅规则的形式指定。 每个规则都包含用于选择特定消息的筛选器条件,并且(可选)包含对所选消息进行批注的操作。 对于每个匹配规则条件,订阅会生成消息的副本,这对于每个匹配规则可能会以不同方式进行批注。 有关详细信息,请参阅主题筛选器和操作

出现空闲队列时自动删除

可以使用出现空闲队列时自动删除功能指定一个空闲时间间隔,该时间间隔过后系统会自动删除队列。 当队列上有流量时,将重置间隔。 最短持续时间为 5 分钟。

重复检测

如果出现错误,导致客户端怀疑某个发送操作的结果,则可使用重复项检测,此功能支持发送方重新发送相同的消息,并让队列或主题放弃任何重复的副本,这样就消除了这些情况下的怀疑。 有关详细信息,请参阅重复检测

安全性

服务总线支持多种安全协议,例如共享访问签名 (SAS) 和适用于 Azure 资源的托管标识

服务总线支持标准的高级消息队列协议 (AMQP) 1.0HTTP/REST 协议。

异地灾难恢复

在 Azure 区域数据中心遭遇停机的情况下,可以使用异地灾难恢复在其他区域或数据中心进行数据处理,以实现连续运行。

注意

有关这些功能的详细信息,请参阅 Azure 服务总线的高级功能

符合标准和协议

服务总线的主要网络协议是高级消息队列协议 (AMQP) 1.0,它是一项开放式 ISO/IEC 标准。 它允许客户编写针对服务总线和本地代理(例如 ActiveMQ 或 RabbitMQ)的应用程序。 如果你想生成这样的抽象,AMQP 协议指南提供了详细信息。

服务总线高级版完全兼容 Java/Jakarta EE Java 消息服务 (JMS) 2.0 API。 而服务总线标准版支持专注于队列的 JMS 1.1 子网。 JMS 是消息代理的一般抽象,可与许多应用程序和框架(包括热门的 Spring 框架)集成。 若要从其他代理切换到 Azure 服务总线,重新创建队列和主题的拓扑,并更改客户端提供程序依赖关系和配置即可。 有关示例,请参阅 ActiveMQ 迁移指南

客户端库

可通过 Azure SDK 使用完全受支持的服务总线客户端库。

Azure 服务总线的主要协议是 AMQP 1.0,可从兼容 AMQP 1.0 的任何协议客户端使用它。 若干开源 AMQP 客户端具有显式演示服务总线互操作性的示例。 查看 AMQP 1.0 协议指南,了解如何通过 AMQP 1.0 客户端直接使用服务总线功能。

语言
Java Apache Qpid Proton-J
C/C++ Azure uAMQP CApache Qpid Proton-C
Python Azure uAMQP for PythonApache Qpid Proton Python
PHP Azure uAMQP for PHP
Ruby Apache Qpid Proton Ruby
Go Azure Go AMQPApache Qpid Proton Go
C#/F#/VB AMQP .NET LiteApache NMS AMQP
JavaScript/Node Rhea

集成

服务总线与许多 Microsoft 和 Azure 服务完全集成,例如:

后续步骤

有关服务总线消息传送入门的内容,请参阅以下文章: