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

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

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

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

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

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

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

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

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

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

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

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

命名空间是一个适用于所有消息组件（队列和主题）的容器。 多个队列和主题可以位于一个命名空间中，命名空间通常用作应用程序容器。

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

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

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

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

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

计划的传递

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

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

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

筛选器和操作

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

出现空闲队列时自动删除

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

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

服务总线支持多种安全协议，例如 共享访问签名 (SAS)、 基于角色的访问控制 (RBAC) 和 适用于 Azure 资源的托管标识 。

服务总线支持标准的 高级消息队列协议 (AMQP) 1.0 和 HTTP/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 客户端直接使用服务总线功能。