服务总线高级消息传送层
服务总线消息传送(包括队列和主题等实体)将企业消息传送功能与丰富的云规模发布-订阅语义结合在一起。 对于许多复杂的云解决方案,服务总线消息传送用作通信中枢。
服务总线消息传送的 高级 层处理有关任务关键应用程序的规模、性能和可用性的常见客户请求。 建议将高级层用于生产方案。 虽然功能集几乎完全相同,但服务总线消息传送的标准和高级层旨在用于满足不同的用例。
下表突出显示了部分高层差异。
条件 | 高级 | Standard |
---|---|---|
吞吐量 | 高吞吐量 | 可变吞吐量 |
性能 | 可预测性能 | 可变滞后时间 |
定价 | 固定定价 | 标准预付费套餐可变定价 |
缩放 | 增加和减少工作负荷的能力 | 空值 |
消息大小 | 消息大小最大为 100 MB。 有关详细信息,请参阅大型消息支持。 | 消息大小最大为 256 KB |
服务总线高级消息传送在 CPU 和内存级别提供资源隔离,以便每个客户工作负荷以隔离方式运行。 此资源容器称为 消息传送单元。 每个高级命名空间至少会分配一个消息传送单元。 可以为每个服务总线高级命名空间购买 1、2、4、8 或 16 个消息传送单元。 单一工作负荷或实体可以跨多个消息传送单元,可以随意更改消息传送单元数。 这会为基于服务总线的解决方案提供可预测和稳定的性能。
这种性能不仅更可预测和可用,而且速度也更快。 在高级消息传送中,峰值性能比标准层快得多。
高级消息传送技术差异
以下部分介绍高级和标准消息传送层之间的一些差异。
快速实体
由于高级消息传送在一个隔离的运行时环境中运行,因此高级命名空间中不支持快速实体。 快速实体先将消息暂时保存在内存中,然后将其写入永久性存储。 如果你的代码在标准消息传递下运行,并且想要将其移植到高级层,请确保已禁用快速实体功能。
高级消息传送资源使用情况
通常,对实体进行的任何操作都可能导致 CPU 和内存使用率增高。 下面是一些这样的操作:
- 管理操作,例如对队列、主题和订阅的创建、检索、更新和删除 (CRUD) 操作。
- 运行时操作(发送和接收消息)
- 监视操作和警报
但是,额外的 CPU 和内存使用量并不额外定价。 对于高级消息传送层,消息单元有一个单价。
由于以下原因,系统会跟踪并显示 CPU 和内存使用情况:
- 让你透彻了解系统内部情况
- 让你了解所购资源的容量。
- 让你通过容量计划来决定是进行纵向扩展还是缩减。
需要多少个消息传送单元?
在预配 Azure 服务总线高级命名空间时指定消息传送单元数。 这些消息传送单元是分配给命名空间的专用资源。 在命名空间上启用分区后,消息传送单元将均匀分布在各个分区中。
分配给服务总线高级命名空间的消息传送单元数可以动态调整,将工作负荷的变化(增加或减少)因素考虑进去。
为体系结构确定消息传送单元数量时,需要考虑以下几个因素:
- 从分配给命名空间 1 或 2 个消息传送单元开始,或者为每个分区分配 1 个消息传送单元。
- 在命名空间的资源使用情况指标中研究 CPU 使用情况指标。
- 如果 CPU 使用率低于 20%,则可纵向缩减分配给命名空间的消息传送单元数。
- 如果 CPU 使用率超过 70%,则增加分配给命名空间的消息传送单元数将有益于应用程序。
注意
缩放分配给命名空间的资源的操作可以抢先进行,也可以被动进行。
抢先:如果预期会有额外的工作负荷(考虑到季节性或趋势),可以在达到工作负荷限制之前向命名空间分配额外的消息传送单元。
被动:如果通过研究资源使用情况指标确定了额外的工作负荷,则可将额外的资源分配给命名空间来应对不断增长的需求。
服务总线的费用按小时计。 进行纵向扩展时,只需按额外资源的使用小时数付费。
高级消息传送入门
高级消息传送很容易入门,其操作过程类似于标准消息传送。 一开始时,请在 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 库,新库提供了关键安全更新和改进功能。
有关详细信息,请参阅支持停用公告。
为新队列(或主题)启用大型消息支持
若要启用大型消息支持,请在创建新队列(或主题)时,按下图所示设置最大消息大小:
为现有队列(或主题)启用大型消息支持
还可以为现有队列(或主题)启用大型消息支持,方法是在该特定队列(或主题)的“概述”中更新“最大消息大小”,如下图所示。
网络安全性
以下网络安全功能仅在高级层中可用。 有关详细信息,请参阅网络安全。
使用 Azure 门户配置 IP 防火墙仅适用于高级层命名空间。 但是,可以使用 Azure 资源管理器模板、CLI、PowerShell 或 REST API 为其他层配置 IP 防火墙规则。 有关详细信息,请参阅配置 IP 防火墙。
静态数据加密
存储子系统中存储的所有数据都使用 Azure 托管密钥进行加密。 如果你使用自己的密钥(也称为客户托管密钥),则仍使用 Azure 托管密钥对数据进行加密,但另外,将使用客户管理的密钥对 Azure 托管密钥进行加密。 使用此功能可以创建、轮换、禁用用于加密 Azure 托管密钥的客户管理的密钥,以及撤销对这些密钥的访问权限。 启用客户管理的密钥功能是命名空间上的一次性设置过程。 有关详细信息,请参阅加密 Azure 服务总线静态数据。
分区
在分区方面,标准和高级层之间存在一些差异。
- 分区在为基本或标准 SKU 中的所有队列和主题创建实体时可用。 命名空间可同时具有已分区实体和非分区实体。 分区在为高级层创建命名空间时可用,该命名空间中的所有队列和主题都会进行分区。 高级命名空间中以前迁移的任何已分区实体会继续按预期工作。
- 在基本或标准 SKU 中启用分区时,服务总线创建了 16 个分区。 在高级层中启用分区时,在创建命名空间期间指定分区数。
有关详细信息,请参阅服务总线中的分区。
异地灾难恢复
Azure 服务总线将各计算机甚至整个机架的灾难性故障风险分散到数据中心内跨多个故障域的群集中,并且实现了透明的故障检测和故障转移机制,使服务继续在有保证的服务级别内运行,而通常不会在此类故障发生时出现明显中断。 高级命名空间可以有两个或多个消息传送单元,这些消息传送单元分布在数据中心内的多个故障域中,支持全活动服务总线群集模型。
对于高级层命名空间,中断风险会进一步分散到三个物理上分离的设备(可用性区域),并且该服务有足够的容量预留,可立即应对数据中心的全部灾难性损失。 在针对严重硬件故障甚至整个数据中心设施灾难性损失的恢复能力方面,容错域内支持可用性区域的全活动 Azure 服务总线群集模型优于任何本地消息中转站产品。 然而,仍有可能出现严重的情况,造成广泛的物理破坏,即使采取这些措施也无法充分防范。
服务总线异地灾难恢复 (Geo-DR) 功能旨在使你更轻松地从如此大规模的灾难中恢复,并永久放弃发生故障的 Azure 区域,无需更改应用程序配置。 放弃 Azure 区域通常涉及到几项服务,此功能主要是为了帮助保持复合应用程序配置的完整性。 此功能在全球范围内可用于服务总线高级层。
异地灾难恢复功能可确保命名空间(事件中心、使用者组和设置)的整个配置在配对后能够从主命名空间连续复制到辅助命名空间,并允许你随时启动从主命名空间到辅助命名空间的一次性故障转移。 故障转移移动会将命名空间的所选别名重新指向辅助命名空间,然后中断配对。 故障转移几乎是启动后立即发生的。
有关详细信息,请参阅 Azure 服务总线异地灾难恢复。
异地复制
异地复制功能是使 Azure 服务总线应用程序免受服务中断和灾难影响的选项之一,可复制元数据(实体、配置、属性)和数据(消息数据和消息属性/状态更改),而上一部分所述的 Geo-DR 功能仅复制元数据。
异地复制功能可确保命名空间的元数据和数据从主要区域持续复制到一个或多个次要区域。
- 队列、主题、订阅、筛选器。
- 数据,驻留在实体中。
- 针对命名空间中的消息执行的所有状态更改和属性更改。
- 命名空间配置。
此功能允许随时将任何次要区域提升为主要区域。 提升次要区域会将命名空间的名称重新指向所选次要区域,并在主要区域和次要区域之间切换角色。 提升几乎是在启动后立即发生的。
Java 消息服务 (JMS) 支持
高级层支持 JMS 1.1 和 JMS 2.0。 有关详细信息,请参阅如何将 JMS 2.0 与 Azure 服务总线高级版配合使用。
标准层仅支持专注于队列的 JMS 1.1 子集。 有关详细信息,请参阅将 Java Message Service 1.1 与 Azure 服务总线标准配合使用。