Azure 服务总线高级消息传送层

Azure 服务总线是一个完全托管的企业消息代理。 服务总线 的高级层在 CPU 和内存级别提供专用的资源隔离,因此每个消息传递工作负载都可独立于其他租户运行。 有关服务总线的详细信息,请参阅 什么是 Azure 服务总线?

当应用程序需要可预测的吞吐量、一致的延迟或对最大 100 MB 的大型消息的支持时,高级层可提供生产和任务关键型方案所需的性能保证。

本文介绍高级层与标准层之间的技术差异、消息传送单元和资源使用情况的工作原理,以及如何开始使用高级命名空间。 下表重点介绍了一些主要差异。

条件 高级 标准
吞吐量 高吞吐量 可变吞吐量
性能 可预测性能 可变滞后时间
定价 固定定价 标准预付费套餐可变定价
缩放 增加和减少工作负荷的能力 不适用
消息大小 消息大小最大为 100 MB。 有关详细信息,请参阅大型消息支持 消息大小最大为 256 KB

服务总线高级消息传送在 CPU 和内存级别提供资源隔离,以便每个客户工作负荷以隔离方式运行。 此资源容器称为 消息传送单元。 每个高级命名空间至少会分配一个消息传送单元。 可以为每个服务总线高级命名空间购买 1、2、4、8 或 16 个消息传送单元。 单一工作负荷或实体可以跨多个消息传送单元,可以随意更改消息传送单元数。 这会为基于服务总线的解决方案提供可预测和稳定的性能。

与标准层相比,高级消息传送还提供更快的峰值性能。

高级消息传送技术差异

以下部分介绍高级和标准消息传送层之间的一些差异。

快捷实体

由于高级消息处理在隔离的运行时环境中运行,因此高级命名空间中不支持 Express 实体。 Express 实体会先将消息暂时保存在内存中,然后再将其写入持久性存储。 如果你的代码当前在标准消息层级下运行,并且你想将其迁移到高级层级,请确保已禁用快速实体功能。

高级消息传送资源使用情况

通常,对实体进行的任何操作都可能导致 CPU 和内存使用率增高。 下面是一些这样的操作:

  • 管理操作,例如对队列、主题和订阅的创建、检索、更新和删除 (CRUD) 操作。
  • 运行时操作(发送和接收消息)。
  • 监视操作和警报。

不过,不会额外定价额外的 CPU 和内存使用量。 对于高级消息传送层,消息单元有一个单价。

由于以下原因,系统会跟踪并显示 CPU 和内存使用情况:

  • 提供系统内部的透明度。
  • 了解已购资源的容量。
  • 帮助您通过容量规划决定是扩容还是缩容。

需要多少个消息传送单元?

在预配 Azure 服务总线高级命名空间时指定消息传送单元数。 这些消息传送单元是分配给命名空间的专用资源。 在命名空间上启用分区后,消息传送单元将均匀分布在各个分区中。

分配给服务总线高级命名空间的消息传送单元数可以动态调整,将工作负荷的变化(增加或减少)因素考虑进去。

为体系结构确定消息传送单元数量时,需要考虑以下几个因素:

  • 从分配给命名空间的 1 个或 2 个消息传送单元 开始,或者从 每个分区 1 个消息传送单元 开始。
  • 在命名空间的资源使用情况指标中研究 CPU 使用情况指标。
    • 如果 CPU 使用率 低于 20%,则可以 缩减 分配给命名空间的消息传送单元数。
    • 如果 CPU 使用率 超过 70%,则应用程序受益于 纵向扩展 分配给命名空间的消息传送单元数。

要了解如何将服务总线命名空间配置为自动缩放(增加或减少消息传送单元),请参阅自动更新消息传送单元

注意

分配给命名空间的资源的扩缩容可以采用预先或响应式的方式进行。

  • 预先:如果预计会有额外的工作负载(由于季节性因素或趋势),则可以在这些工作负载到来之前,先向该命名空间分配更多消息传递单元。

  • 被动:如果通过研究资源使用情况指标确定了额外的工作负荷,则可将额外的资源分配给命名空间来应对不断增长的需求。

服务总线按小时计费。 当进行纵向扩展时,您只需为额外资源的使用小时数付费。

开始使用高级消息

高级消息传送很容易入门,其操作过程类似于标准消息传送。 一开始时,请在 Azure 门户创建命名空间。 确保在“定价层”下选择“高级”。 选择“查看完整的定价详细信息”以查看有关每个层级的详细信息。

显示创建命名空间时选择高级层的屏幕截图。

也可以使用 Azure 资源管理器模板创建高级命名空间

大型消息支持

Azure 服务总线 高级层级命名空间支持发送高达 100 MB 的大型消息。 此功能主要面向这样的遗留工作负载:它们此前在其他企业消息代理上使用较大的消息负载,并希望无缝迁移到 Azure 服务总线。

以下是在Azure 服务总线上发送大型消息时的一些注意事项:

  • 仅在 Azure 服务总线高级层命名空间上受支持。
  • 仅在使用高级消息队列协议 (AMQP) 时受支持。 使用 SBMP 或 HTTP 协议时不受支持,在高级层中,SBMP 和 HTTP 协议的消息大小上限为 1 MB。
  • 使用 Java 消息服务 (JMS) 2.0 客户端 SDK 和其他语言客户端 SDK 时受支持。
  • 发送大型消息会导致吞吐量降低和延迟增大。
  • 虽然支持 100 MB 的消息有效负载,但仍应尽可能减小消息有效负载的大小,以确保 服务总线 命名空间提供可靠的性能。
  • 最大消息大小限制仅对发送到队列或主题的消息生效。 对于接收操作不强制实施大小限制。 允许更新给定队列(或主题)的最大消息大小。
  • 不支持批处理。

注意

2026 年 9 月 30 日,我们将不再支持 Azure 服务总线的 SBMP 协议,因此在 2026 年 9 月 30 日之后,你将无法再使用此协议。 请在该日期之前迁移到最新的使用 AMQP 协议的 Azure 服务总线 SDK 库,新库提供了关键安全更新和改进功能。

有关详细信息,请参阅支持停用公告

启用对新队列或主题的大型消息支持

若要启用对大型消息的支持,请设置创建新队列或主题时的最大消息大小,如下图所示:

显示如何在创建新队列时启用大型消息支持的屏幕截图。

为现有队列或主题启用大型消息支持

还可以通过更新特定队列或主题的“概述”上的最大消息大小,为现有队列或主题启用对大型消息的支持,如下图所示。

显示“最大消息大小”设置的现有队列“概述”页面截图。

服务总线 Premium 中的网络安全

以下网络安全功能仅在高级层中可用。 有关详细信息,请参阅网络安全

使用 Azure 门户配置 IP 防火墙仅适用于高级层命名空间。 但是,可以使用 Azure 资源管理器模板、CLI、PowerShell 或 REST API 为其他层配置 IP 防火墙规则。 有关详细信息,请参阅配置 IP 防火墙

服务总线 中静态数据的加密

所有服务总线数据都使用标准层和高级层中的Azure托管密钥进行静态加密。 高级层还支持客户管理的密钥(CMK),该密钥在Azure管理的密钥的基础上添加第二层加密。 使用 CMK,可以创建、轮换、禁用和撤销对用于加密数据的密钥的访问权限。 启用客户管理的密钥是命名空间上的一次性设置过程。 有关详细信息,请参阅加密 Azure 服务总线静态数据

服务总线中的分区

在分区方面,标准和高级层之间存在一些差异。

  • 分区在为基本或标准 SKU 中的所有队列和主题创建实体时可用。 命名空间可同时具有已分区实体和非分区实体。 分区在为高级层创建命名空间时可用,该命名空间中的所有队列和主题都会进行分区。 高级命名空间中以前迁移的任何已分区实体会继续按预期工作。
  • 在基本或标准 SKU 中启用分区时,服务总线创建了 16 个分区。 在高级层中启用分区时,在创建命名空间期间指定分区数。

有关详细信息,请参阅服务总线中的分区

服务总线 中的高可用性

Azure 服务总线将各计算机甚至整个机架的灾难性故障风险分散到数据中心内跨多个故障域的群集中,并且实现了透明的故障检测和故障转移机制,使服务继续在有保证的服务级别内运行,而通常不会在此类故障发生时出现明显中断。 高级命名空间可以具有两个或多个消息传送单元,这些消息传送单元分布在数据中心内的多个 故障域 中,从而支持 全主动 服务总线 群集模型

对于 服务总线 命名空间,中断风险会进一步分散到三个物理上彼此分离的设施可用区,并且该服务具备足够的容量储备,可即时应对整个数据中心的灾难性完全失效。 在应对严重硬件故障甚至整个数据中心设施灾难性损毁方面的弹性上,位于一个故障域内并结合可用区支持的全主动 Azure 服务总线群集模型优于任何本地消息代理产品。 然而,仍有可能出现严重的情况,造成广泛的物理破坏,即使采取这些措施也无法充分防范。

此外,Geo-Replication功能是Azure 服务总线应用程序防止中断和灾难提供元数据(实体、配置、属性)和数据(消息数据和消息属性/状态更改)复制的选项之一。 异地复制功能可确保命名空间的元数据和数据从主要区域持续复制到一个或多个次要区域。

  • 队列、主题、订阅、筛选器。
  • 驻留在实体中的数据。
  • 针对命名空间中的消息执行的所有状态更改和属性更改。
  • 命名空间配置。

此功能允许随时将任何次要区域提升为主要区域。 提升次要区域会将命名空间的名称重新指向所选次要区域,并在主要区域和次要区域之间切换角色。 升级一经启动,几乎会立即完成。

服务总线中的Java消息服务(JMS)支持

高级层支持 JMS 1.1 和 JMS 2.0。 有关详细信息,请参阅如何将 JMS 2.0 与 Azure 服务总线高级版配合使用

标准层仅支持专注于队列的 JMS 1.1 子集。 有关详细信息,请参阅将 Java Message Service 1.1 与 Azure 服务总线标准配合使用