Azure 服务总线的体系结构最佳做法

考虑可能导致设计限制的因素：Azure 服务总线的配额和分层特定限制会影响设计。 选择一个等级，为消息处理容量提供缓冲，并避免成本高昂的重新设计。 例如，如果对峰值和突发吞吐量的评估指示更高的限制，则 Premium 可能适用。 同样，对于较大的负载，请考虑使用高级版。

通过故障模式分析预测潜在故障： 故障模式分析提供了一种系统的方法，用于预测潜在的故障方案并制定缓解策略，以确保消息传递服务复原能力。

跨解决方案层实现冗余： 冗余是一种关键技术，用于通过消除跨多个层的单一故障点来确保可靠的消息传送。

• 实例级冗余：在基础级别，通过跨多个独立的服务总线实例分发消息，以实现实例级冗余。 这 >要求应用程序跨多个消息传送终结点实现自定义故障转移逻辑或负载均衡策略。

• 区域级冗余：启用可用区以防止数据中心级故障。 如果出现此类故障，应用程序可能会遇到 >临时中断;但是，服务总线会自动跨多个可用性区域复制消息数据和元数据，以保持连续性。

• 区域级别冗余：对于要求更高恢复能力的工作负荷，请考虑实现区域级别冗余。 这可以通过在不同区域中的多个命名空间之间使用 >主动-主动配置来实现。

确保选择支持这些冗余功能的服务总线层，例如高级层。

实施灾难恢复和备份策略： 多区域灾难恢复通过异地灾难恢复功能防范完整的区域故障。 服务总线高级层支持主要区域和副区域之间的地理灾难恢复对，允许自动元数据复制和故障转移协调。 异地灾难恢复复制命名空间元数据，但不会复制消息数据，而异地复制则提供额外的复杂性的完整消息数据复制。

在区域中断期间，应用程序可以使用自动指向活动区域的别名连接重定向到辅助命名空间。 恢复规划必须在故障转移方案和恢复时间目标（具体取决于 DNS 传播和应用程序重新连接逻辑）期间考虑消息数据丢失。

消息级备份策略需要应用程序级实现，因为服务总线不提供内置的消息备份功能。 配置备份包括导出命名空间元数据、队列和主题定义以及访问策略，以便在灾难恢复情境中快速重建命名空间。

灾难恢复需要考虑消息排序保证、故障转移方案中的重复处理，以及应用程序级重试逻辑来处理跨区域延迟变化。

为变量消息加载实现可靠的缩放： 使用依赖于分区策略和并发接收方配置的可靠消息处理模式来保持一致的吞吐量，而不会失败。 为每个队列配置多个并发接收器，以通过分配负载并减少单一故障点来提高处理可靠性。 启用会话的队列可确保有序处理，但将并行度限制为每个会话一个活动接收器，从而产生潜在的可靠性瓶颈。

使用分区实体跨多个消息代理分发消息以实现容错，尽管它们可能会影响排序保证和事务一致性。 使用消息筛选配置主题订阅，以启用可靠的扇出方案，这些方案可在多个使用者应用程序中分配处理，而无需创建基础结构依赖项。

服务总线高级版提供专用的消息单元，具有可预测的容量，并自动扩展吞吐量单元，以应对动态消息量。 每个消息传送单元都提供有保证的发送和接收限制，其自动缩放可防止在流量高峰期间进行限制。 标准层使用具有可变容量的共享基础结构，但缺少专用吞吐量保证和自动缩放功能。

实现以可靠性为中心的监视和运行状况检测： 为了保持可靠的消息传送，监视可能表明潜在问题的性能特征至关重要。 关注关键指标，例如：

• 用于检测积累或处理延迟的活动消息计数趋势。
• 服务器错误可能指向底层基础设施问题。
• 表示容量约束或资源饱和的节流事件。

除了功能指标之外，还包括以可靠性为中心的指标，例如：

• 消息传递成功率可确保吞吐量一致。
• 死信队列累积，这可以揭示持续性传递失败。
• 故障转移事件检测，以评估基础设施中断期间的系统复原能力。

将监视扩展到依赖项运行状况，涵盖发布或使用消息的连接应用程序和外部服务。 由于消息传递的可靠性取决于整个流链，因此应配置阈值以在出现会影响交付保证的情况时触发警报，如快速增加的死信队列或区域故障转移事件。

配置自我保护机制和弹性模式： 服务总线包括内置的自我保护机制，旨在防止故障在消息传递基础设施中级联传播。 可以在三个级别配置这些保护：消息级、客户端级别和命名空间级别。

• 消息级保护：配置死信队列以自动隔离无法传递的消息，防止正常消息流受到阻碍。 根据工作负荷要求设置最大传递计数和生存时间（TTL）等参数。 启用重复检测，以避免在重试方案中通过指定重复检测历史记录窗口来重新处理消息。

• Client-Level 保护：使用包含指数退避和断路器功能的内置重试策略的客户端 SDK 来缓解级联故障。 实现连接池和客户端缓存以减少资源耗尽，尤其是在高吞吐量作期间。

• Namespace-Level 隔离：为不同的环境或工作负荷组件使用单独的服务总线命名空间来防止跨应用程序故障。 考虑消息批处理和预提取设置，以减少网络延迟。

建立安全基线： 查看 Azure 服务总线安全基线 ，并将适用的措施纳入安全基础。 Microsoft云安全基准为服务总线提供特定的安全控制，用于满足标识管理、网络安全、数据保护和合规性要求。

这种标准化的安全配置和策略实施方法使得您的消息传递基础结构能够满足行业标准和合规要求。

使用 Microsoft Entra ID 强制实施授权和身份验证： 服务总线提供内置的 Azure RBAC 角色，用于对消息传送作进行精细访问控制，包括 Azure 服务总线数据所有者、数据发送方和数据接收器角色，以实现不同的权限级别。 通过这些数据平面角色，可以利用遵循最低特权原则的分配对发送、接收和管理操作进行细粒度控制。

使用托管标识启用由 Microsoft Entra ID 管理的安全身份验证。

通过组成员身份定期进行角色分配评审和自动预配，以持续维护安全态势。

实现安全网络配置： 网络安全控制应在层中实现，以进行深层防御保护。 使用专用终结点为服务总线命名空间创建专用 IP 地址，确保消息流量保留在 Azure 主干网络中，从而启用安全连接。 或者，可以考虑使用服务终结点，因为它们在不需要专用 IP 地址的情况下提供网络集成。 对于最精细的控制，应设置 IP 防火墙规则和虚拟网络规则，以限制对特定客户端 IP 范围和子网的访问。

建立专用连接以消除基于 Internet 的攻击途径时禁用公共网络访问，而网络安全组规则为包含服务总线使用者和生成者的子网提供额外的筛选。

加密静态数据和传输中的数据： 使用基于 TLS 的 AMQP（高级消息队列协议）进行加密，以便使用身份验证功能保护消息传送。 传输层安全性 TLS 1.2 或更高版本在客户端和服务总线之间的传输过程中保护消息数据。

服务总线使用平台管理的密钥自动加密静态数据，其中 Azure 处理密钥创建、轮换和管理。 为了增强控制，高级层支持与 Azure Key Vault 集成，以便使用已建立的密钥轮换策略进行客户管理的密钥加密。

强化命名空间配置并减少攻击面： 删除不再需要不必要的队列、主题和订阅，以防止未经授权的访问未使用的消息传递实体。 配置适当的消息保留策略和自动删除设置，以防止无限期存储敏感数据。

在禁用消息转发等功能时，仅为工作负荷体系结构启用所需的消息传送模式，除非特别需要。 此外，定期审查命名空间配置，以随时间推移维护安全状况。

保护连接字符串和访问凭据： 更喜欢应用程序中基于标识的连接来消除连接字符串存储，因为它们包含敏感身份验证。 某些方案可能需要连接字符串，因为这些方案具有安全处理机制。

Azure Key Vault 集成可实现集中式存储和访问控制，从而降低应用程序配置中的凭据暴露风险，同时提供审核日志记录和访问策略。 通过密钥滚动更新过程定期轮换共享访问密钥，以最大程度地减少服务中断。

实现安全监视和威胁检测： 重点监视威胁检测、未经授权的访问尝试和可疑消息传送模式，包括身份验证尝试失败、特权升级和异常消息传送行为。 诊断日志应捕获身份验证事件和授权失败，而管理操作提供安全审计路径。

Azure Monitor 集成包括身份验证失败、限流事件和异常消息量模式。 为安全事件实现自动警报和响应过程，并集成到 Azure Sentinel 或 SIEM 解决方案中，以实现跨安全基础结构的关联。

建立安全测试和验证做法： 通过安全测试识别消息基础结构中潜在的安全漏洞，以根据安全基线验证服务总线配置，并验证组织安全策略符合性。

理想情况下，安全测试应集成到部署和作工作流中，并使用自动安全扫描工具评估网络配置和访问控制。

测试方案应解决各种攻击途径，包括验证 DLQ 策略，防止消息丢失，而不公开敏感数据，确认有害消息不会导致无限重试，并验证幂等处理。 此外，模拟 DoS 攻击以测试限制、注入格式不正确的消息以测试验证，以及模拟未经授权的访问尝试。

选择正确的服务总线服务层级： 服务总线提供具有不同成本结构和功能的多个定价层。 考虑到服务总线层选择时，需要会话、重复检测和异地灾难恢复的技术要求。 如果设计不需要，请避免为更高等级支付更多费用。

在层决策中，还要考虑容量规划，容量规划需要考虑峰值流量、并发连接和消息大小。 高级层提供具有可预测的每月成本的专用消息传送单元，使其适合生产工作负荷。 标准层为非生产环境节省成本。

建立服务总线使用情况预测和成本建模方法： 预测服务总线费用时确定成本驱动因素。 事件驱动处理、作业队列和发布-订阅方案等使用模式具有不同的成本特征。 考虑到操作计数和消息存储的持续时间，以构建一个实际的成本模型。

考虑需求波动，包括季节性变化和业务增长预测。 在预测中包括灾难恢复测试和其他管理活动的运营开销，以避免预算意外。

为服务总线资源实现成本监视和预算警报： 查看服务总线命名空间的成本明细，以了解支出模式。 监视使用费用，包括消息操作、存储消耗和网络出口费用。 这些指标揭示了优化机会和成本趋势。

配置具有多个阈值级别的预算警报，以便在出现重大溢出之前出现提前警告。 成本警报可能会触发扩展调整或预算控制紧急措施。 在 50%、75%和 90% 预算时触发警报，并做出积极的成本管理决策。 建立包括自动响应和通知工作流的警报处理过程。 集成用于高成本部署的审批工作流，以防止意外支出。

实施成本分配策略，以用于服务多个应用程序的共享命名空间。 资源标记通过详细监视实现退款模型，确保跨团队和项目实现准确的成本归属。

对分配的资源进行权限化，以最大化其使用情况： 分析资源利用率，以确定优化机会。 查看消息吞吐量模式、队列深度趋势和连接利用率，以查找未使用或未充分利用的资源。 禁用不必要的功能并合并未充分利用的命名空间。 下面是需要考虑的一些典型区域：

• 优化存储成本。 应用死信队列管理，以防止无限期地累积失败的消息。 根据实际要求配置消息保留策略。 根据实际需求设置重复检测窗口，而不是最大值。

• 降低网络和数据传输成本。 将多个消息合并为一个操作，以减少可计费操作。 将服务总线命名空间与使用应用程序共同部署，以消除跨区域的数据出口费用。

• 实现消息压缩和高效的序列化，以最大程度地减少有效负载大小。 这可以降低存储成本和网络传输费用，同时提高吞吐量。

• 根据使用模式动态调整容量。 监视季节性变化和业务周期波动，以通知容量规划。 主动调整可防止在低需求期间过度预配，同时确保在高峰期有足够的容量。

为服务总线成本管理实现 Azure Policy 控制： 实施 Azure Policy 控制以强制实施成本管理标准。 定义限制服务总线层部署、将部署限制为经济高效的区域以及控制成本高昂的功能（如异地灾难恢复）的策略。 这些防护措施可防止未经授权的高成本配置。

跨不同环境优化服务总线配置： 使用适合每个环境的成本优化默认值设计自动化环境预配。 模板应包括合理的配置，用于根据环境目的平衡功能与成本效益。

将服务总线功能与实际环境要求相匹配。 生产需要区域冗余、异地灾难恢复和专用吞吐量。 非生产环境可以使用简化的功能集、较低的吞吐量和降低的可用性保证来最大程度地降低成本。

实施服务总线合并策略以降低成本： 当安全性和作边界允许时，跨应用程序共享服务总线资源。 合并命名空间通过资源共享提高消息传送单元利用率，从而降低总体成本。 实现资源标记，以实现跨部门和项目的成本分配，支持多租户环境中的退款模型。

评估服务总线作的团队准备情况： 服务总线作需要消息传送方面的专业知识，例如死信队列管理、消息生命周期处理和安全配置。 Teams 需要熟练使用身份验证方法，包括共享访问策略、托管标识和 Azure RBAC 实现。

为服务总线部署实现基础结构即代码： 服务总线基础结构支持 ARM 模板、Bicep 和 Terraform，以便跨环境进行一致的部署。 模板应包含命名空间配置、队列和主题定义、订阅筛选器和访问策略，以便进行完整的基础结构管理。 使用模板参数化在保持部署一致性的同时启用特定于环境的配置。 有关详细信息，请参阅 服务总线命名空间模板。

如果托管标识等依赖项需要顺序预配，请考虑分层部署策略，以便将命名空间预配与实体配置分开。

服务总线配置的版本控制可确保可审核性，并为基础结构更改提供回滚功能。

建立安全的消息传输基础设施部署策略：包括命名空间切换的蓝绿部署，以及订阅筛选器更改的金丝雀测试部署。 蓝绿策略支持零停机时间转换，而金丝雀部署会在全面推出之前验证路由的正确性。

确保在基础结构更新期间进行部署验证检查，以确保消息传递连续性。 包括对消息路由、订阅筛选器和死信队列配置进行测试。

设计服务总线操作任务的自动化策略： 在可行的情况下，让服务总线的自动化针对重复性任务。 评估 Azure 逻辑应用、Azure Functions 和 Azure 自动化的工作流自动化功能。

关键自动化机会包括死信队列清理，以防止资源积累和过期的消息删除来控制存储成本。 计划的缩放操作可以根据可预测的使用模式来调整容量。

其他自动化目标可能包括订阅维护、访问策略轮换和命名空间容量监视，以减少作开销并确保一致的管理做法。

收集监视数据： 监视消息流运行状况、命名空间性能指标和依赖项。 Azure Monitor 集成为消息传送基础结构提供基本指标、日志和分布式跟踪功能。 关键遥测包括消息吞吐量速率、队列深度趋势、死信累积、限制事件和连接池利用率。 Application Insights 通过服务总线向使用者启用从发布者到使用者的端到端跟踪，以便完全了解情况。

建立消息传送失败的事件响应过程：命名空间故障转移，确保有消息恢复和订阅重建。 完整配置后，地理灾害恢复功能可以实现自动的区域故障转移。

响应策略必须考虑到消息排序保证、重复处理、路由和筛选器的验证，以及复杂恢复方案的手动干预过程，同时保留传递保证。

实现消息传送基础结构的测试策略： 包括消息传送模式的功能测试、集成测试和路由、筛选器和处理逻辑的验证。 负载测试在预期的流量量下验证性能特征。

通过 CI/CD 管道测试自动化可确保对消息传递基础结构更改和应用程序集成方案进行一致的验证。

评估消息 API 选择，以匹配团队的技能集： 服务总线支持本机 Azure SDK 和用于 Java 应用程序的 JMS 2.0 API，每个 API 都提供不同的功能和性能特征。 API 选择应符合团队专业知识和应用程序要求。

原生 SDK 提供对服务总线功能的完整访问，包括会话、重复检测以及通过特定于 Azure 的优化进行自动转发。 这些 SDK 提供完整的功能访问和最佳性能特征。

与本机实现相比，JMS API 提供标准化的消息传送接口，但存在限制，包括服务总线会话不可用和性能选项降低。

为服务总线工作负荷执行容量规划： 服务总线容量规划需要通过系统评估来分析预期的消息量和峰值吞吐量要求。 使用实际消息模式进行负载测试，以在生产部署之前验证容量估算。

建立容量基线时，请考虑消息大小分布和并发连接模式。 考虑影响整体资源消耗的消息保留期、死信队列存储和订阅筛选器复杂性。

高级层提供具有可预测的性能特征和保证容量的专用消息传送单元。 较低级别使用具有变化性能的共享基础设施，由于“嘈杂邻居”效应，在高峰使用期间可能会出现限流现象。

设计消息处理工作负载的缩放策略： 服务总线缩放策略应包括满足不同性能要求的水平、垂直和体系结构缩放方法。

水平缩放涉及通过分区实体将消息分布到多个消息代理，从而提高吞吐量和并行度。 但是，分区会产生利弊，其中改进的可伸缩性可能会影响分区实体的排序保证和事务一致性。

高级层消息传送单元增加为动态工作负荷提供自动调整功能的专用容量。 跨区域命名空间分布的体系结构缩放支持具有区域性能优化的全局工作负荷。

配置消息处理模式以实现最佳吞吐量： 消息处理模式显著影响服务总线吞吐量和整体应用程序性能。 批处理通过在单个作中发送或接收多个消息来减少网络往返，从而提高效率。 使用筛选的主题订阅可以在消息传递中实现分发场景。

使用多个并发接收器进行并行处理会增加基于队列的工作负荷的总体吞吐量。 基于会话的消息传送可确保对相关消息进行有序处理，但通过将并行度限制为每个会话限制一个活动接收器来创建吞吐量约束。

监视性能指标并确定瓶颈： 服务总线性能监视需要跟踪关键指标，包括消息吞吐量速率、队列深度趋势、处理延迟和限制事件。 监视连接池利用率，以便跨消息传送基础结构进行性能评估。

通过专注于命名空间级别限制和订阅筛选器处理延迟来确定瓶颈，这些延迟可能会影响总体吞吐量。

优化消息处理和网络性能： 消息处理优化包括连接池、预提取配置和消息批处理，以提高客户端性能。 有效负载大小优化可降低网络开销并提高处理效率。

预提取设置使客户端能够主动接收多个消息，从而减少网络延迟对消息处理吞吐量的影响。 网络性能优化涉及通过区域共同位置将服务总线命名空间与消息生成者和使用者并置，从而最大程度地降低延迟。