你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 服务总线是一项完全托管的企业消息代理服务，它提供可靠的异步消息传送功能来分离应用程序和服务。 服务总线支持用于点到点通信的队列，以及用于发布-订阅消息传送模式的主题和订阅。 该服务提供内置可靠性功能，包括消息持久性、至少一次传递保证和死信队列来处理失败的消息处理。
使用 Azure 时， 可靠性是共同的责任。 Microsoft提供了一系列功能来支持复原和恢复。 你负责了解这些功能如何在你使用的所有服务中工作，并选择满足业务目标和运行时间目标所需的功能。
本文介绍如何增强服务总线的弹性，以应对各种可能的中断和问题，包括瞬时故障、可用性区域中断和区域中断。 它还重点介绍了有关服务总线服务级别协议（SLA）的一些关键信息。
生产部署建议
Azure Well-Architected Framework 提供了关于可靠性、性能、安全性、成本和操作的建议。 若要了解这些领域如何相互影响，并为可靠的 Azure 服务总线解决方案做出贡献，请参阅 服务总线的体系结构最佳做法。
可靠性体系结构概述
本部分介绍从可靠性的角度来看，服务工作原理最相关的一些重要方面。 本部分介绍逻辑体系结构，其中包括部署和使用的某些资源和功能。 它还讨论了物理架构，该架构提供了服务内部运作方式的详细信息。
逻辑体系结构
命名空间充当服务总线的管理容器，可配置为使用基本层、标准层或高级层。 在命名空间级别配置服务时，可以通过分配容量、配置网络安全以及启用地理复制和地理灾难恢复。
在命名空间中，部署队列和主题，这些 队列 和 主题是具有不同语义的消息传送实体。 有关详细信息，请参阅服务总线队列、主题和订阅。
可以选择在命名空间上配置 分区 ，该分区将队列和主题分散到多个消息中转站和消息存储中。 命名空间可以使用多个分区来处理并行处理和水平缩放。 服务总线仅保证单个分区内的排序。 分区在应用程序的可靠性设计中起着关键作用。 设计应用程序时，在最大化可用性和一致性之间进行权衡。 对于高级层， 在命名空间上启用分区。 对于“基本”和“标准”层命名空间，请在实体上配置分区，并在 发送消息时（可选）配置分区。
可以使用服务总线及其异步设计方法来提高应用程序的可用性。 有关详细信息，请参阅 异步消息传送模式和高可用性。
物理体系结构
服务总线提供基础计算和存储资源。 对于每个命名空间，多个 消息中转站 处理消息，多个 消息存储 存储消息。 每个消息存储都有三个副本：一个主副本和两个辅助副本。 服务总线使所有这三个副本保持同步，以用于数据和管理操作。 如果主复制副本故障，服务总线会将辅助副本升级为主副本，这样不会对客户端造成停机影响。
对于使用“基本”或“标准”层的命名空间，服务总线通过共享的多租户基础结构提供冗余，该基础结构可在可用可用性区域中自动复制消息。 该服务维护多个消息存储，并将所有副本保持同步，以实现数据和管理操作。
对于 高级层命名空间，服务总线提供具有专用 CPU 和内存资源的专用消息传输单元（MU）。 高级层命名空间可以根据工作负荷需求自动缩放。 有关详细信息，请参阅自动更新服务总线命名空间的 MU。
服务总线基础结构跨多个物理计算机和机架，这些计算机和机架分布在容错域中，从而降低影响命名空间的灾难性故障的风险。 在具有可用性区域的区域中，基础结构 跨不同的物理数据中心扩展。 该服务实现透明故障检测和故障转移机制，以便它在保证服务级别内继续运行，通常不会在这些故障发生时明显中断。
暂时性故障的复原能力
暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。
与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循 Azure 暂时性故障处理指南。 有关详细信息，请参阅有关处理暂时性故障的建议。
服务总线 SDK 包括自动重试逻辑，针对由于网络超时或临时服务不可用等暂时性条件而失败的操作，该逻辑会使用指数递增的退避策略进行重试。 当应用程序遇到与服务总线的暂时性断开连接时，SDK 会使用配置的重试策略自动尝试重新连接。
若要优化应用程序中的暂时性故障处理，请使用最新的服务总线 SDK，其中包括最新的重试逻辑和连接管理功能。 有关详细信息，请参阅 适用于 .NET 的服务总线客户端库。
应对可用区故障的弹性
可用性区域 是 Azure 区域内物理上独立的数据中心组。 当某个区域发生故障时，服务可以切换到其他可用的区域。
服务总线支持所有服务层级的区域冗余部署。 在受支持的区域中创建服务总线命名空间时，会自动启用区域冗余，无需额外付费。 区域冗余部署模型适用于所有服务总线功能，包括分区和会话。
服务总线以透明方式跨区域中的多个可用性区域复制配置、元数据和消息数据。 区域冗余提供自动故障转移，无需你的任何干预。 所有服务总线组件（包括计算、网络和存储）都会跨区域复制。 服务总线拥有足够的容量储备，可以立即应对区域完全丢失的情况。 即使整个可用性区域不可用，它仍继续运行，而不会丢失数据或中断消息应用程序。
要求
区域支持： 可以将区域冗余的服务总线命名空间部署到 支持可用性区域的 Azure 区域。 在受支持的区域中创建命名空间时，服务总线会自动启用可用性区域支持，无需额外配置。
层： 所有服务总线层（基本、标准和高级）都支持可用性区域，无需额外的要求。
注意事项
服务总线命名空间包括一个 zoneRedundant 属性。 以前，此属性是启用可用性区域所必需的，但此要求已更改，并且 zoneRedundant 属性已弃用。 即使启用了区域冗余，此属性也会显示 false 。 具有可用性区域的区域中的所有命名空间都是区域冗余的。
成本
服务总线中的区域冗余不会增加额外的成本。
配置可用性区域支持
在 受支持的区域中部署服务总线命名空间时，服务总线命名空间会自动支持区域冗余。 无需进一步配置。
所有区域正常时的行为
本部分介绍在为区域冗余配置服务总线命名空间以及所有可用性区域正常运行时的预期情况。
区域之间的流量路由： 服务总线使用主动-主动模型，其中消息分布在多个可用性区域。 客户端连接会跨区域自动负载均衡，服务无论区域如何，都会将操作路由到可用的消息传送基础设施。
区域之间的数据复制： 服务总线跨可用性区域使用同步复制，包括元数据和消息数据。 消息存储的多个副本必须在服务认为它们已完成之前确认写入操作，这可确保在正常操作期间跨区域的数据一致性。
区域故障期间的行为
本节介绍在配置服务总线命名空间以实现区域冗余时以及出现可用性区域中断时，预计会出现什么情况。
- 检测和响应：Microsoft自动检测区域故障，并启动故障转移到健康区域。 区域级故障转移不需要客户采取任何行动。
- 通知： Microsoft不会在区域关闭时自动通知你。 但是，可以使用 Azure 服务运行状况 来了解服务的总体运行状况，包括任何区域故障，并且可以设置 服务运行状况警报 来通知问题。
活动请求： 在区域故障期间，服务总线可能会删除活动请求。 如果客户在短时间内重试，以适当处理暂时性故障，通常可以避免重大影响。
预期数据丢失： 区域故障期间不会发生数据丢失，因为服务总线在确认之前同步跨区域复制消息。
预期的停机时间： 区域故障可能会导致几秒钟的停机时间。 如果客户在短时间内重试，以适当处理暂时性故障，通常可以避免重大影响。
流量重新路由： 服务总线会检测区域丢失情况，并自动将新请求重定向到一个正常的可用性区域中的另一个副本。
服务总线 SDK 通常以透明方式处理连接管理和重试逻辑。
区域恢复
当可用性区域恢复时，服务总线会自动将区域重新集成到活动服务拓扑中。 然后，恢复的区域将接受新的连接，并与其他区域一起处理消息。 在中断期间复制到幸存区域的数据保持不变，所有区域中的正常同步复制都会恢复。 无需采取措施进行区域恢复或重新集成。
测试区域故障
服务总线管理区域故障的流量路由、故障转移和区域恢复，因此无需验证可用性区域故障过程或提供进一步的输入。
对区域范围的故障的复原能力
服务总线提供两种类型的多区域支持，这两种支持都需要高级层命名空间：
异地复制 提供主要区域和次要区域之间的元数据和消息数据的主动-被动复制。 对大多数应用程序使用 Geo-Replication，这些应用程序必须保持对区域中断的复原能力，并且对消息数据丢失的容忍度较低。
元数据地理灾难恢复在主要区域和次要区域之间提供配置和元数据的主动-被动冗余，但不会复制消息内容。 请考虑对自行处理数据复制或不需要数据复制的应用程序使用 Geo-Disaster Recovery。
下表总结了这两个功能之间的主要区别：
| 能力 | Geo-Replication | 异地灾难恢复 |
|---|---|---|
| 复制的内容 | 元数据和数据（消息、消息状态、属性更改） | 仅元数据（实体、配置、属性） |
| 故障转移时数据丢失 | 计划升级时不会数据丢失，强制升级可能会丢失数据。 | 不会复制消息;必须从旧的主命名空间手动恢复 |
| 故障转移行为 | 将辅助数据库提升为主数据库;旧的主数据库变为辅助数据库 | 一次性故障转移；故障转移后配对中断 |
| 故障回复功能 | 是的，可以升级回原始主数据库 | 否，必须设置新的配对 |
| 复制模式 | 同步或异步 | 不适用（仅元数据） |
对于大多数灾难恢复方案，建议选择 Geo-Replication，因为它提供完整的数据保护。 仅当您特别需要仅限于元数据复制的情况下，才考虑地理灾难恢复。
异地复制和元数据异地灾难恢复都需要手动启动故障转移或将次要区域升级为新的主要区域。 即使主区域出现故障宕机，Microsoft也不会自动启动故障转移或提升操作。
基本层和标准层的命名空间不包括原生的多区域功能，但可以通过在跨区域之间使用多个命名空间来实现应用级复制模式。 有关详细信息，请参阅 用于复原的自定义多区域解决方案。
Geo-Replication
高级层支持异地复制。 此功能复制命名空间的元数据，如实体、配置和属性。 它还复制队列和主题中的消息以及消息属性和状态等数据。 您为命名空间的配置和数据设置复制方法。 此功能可确保消息在另一个区域中保持可用状态，并允许在需要时切换到次要区域。
在需要对区域故障具备弹性并对消息数据丢失容忍度较低的场景中，请使用 Geo-Replication。
命名空间实质上跨区域扩展。 一个区域充当主要区域，另一个区域充当次要区域。 您的 Azure 订阅显示单个命名空间。
可以随时将次要区域 提升 为主要区域。 升级次要区域时，服务总线会将命名空间的完全限定域名（FQDN）重新指向所选次要区域，并将以前的主要区域降级到次要区域。 你决定是执行 计划的升级，这意味着你等待数据复制完成，还是 强制升级，这可能会导致数据丢失。
注释
服务总线 Geo-Replication 使用术语 提升 ，因为它最能表示将次要区域提升到主要区域的过程（稍后将主要区域降级到次要区域）。 术语 故障转移 还用于描述此常规过程。
本部分总结了异地复制的重要方面。 查看完整的文档，了解其工作原理。 有关详细信息，请参阅 服务总线异地复制。
要求
区域支持： 可以选择支持服务总线作为主要区域或次要区域的任何 Azure 区域。 无需使用 Azure 配对区域，因此请根据延迟、符合性或数据驻留要求选择次要区域。
层： 若要启用异地复制，命名空间必须使用高级层。
元数据 Geo-Disaster Recovery: 无法将命名空间配置为同时使用 Geo-Replication 和 Geo-Disaster Recovery。
注意事项
功能限制： 启用异地复制时，会应用一些限制。 有关详细信息，请参阅 服务总线异地复制。
专用终结点： 如果使用专用终结点连接到命名空间，还必须在主要区域和次要区域中配置网络。 有关详细信息，请参阅专用终结点。
成本
若要了解异地复制的定价工作原理，请参阅 “定价”。
配置多区域支持
在新命名空间上启用 Geo-Replication。 若要在创建过程中对命名空间启用 Geo-Replication，请参阅 “设置异地复制”。
从元数据 Geo-Disaster 恢复迁移到异地复制。从使用元数据 Geo-Disaster 恢复切换到异地复制。
更改复制方法。 若要在同步复制模式和异步复制模式之间进行切换，请参阅 “切换复制模式”。
关闭异地复制。 若要关闭次要区域的 Geo-Replication，请参阅 “删除次要区域”。
当所有区域都正常时的行为
本部分介绍为 Geo-Replication 配置服务总线命名空间且主要区域正常运行时会发生什么情况。
区域之间的流量路由： 客户端应用程序通过命名空间的 FQDN 及其流量路由连接到主要区域。
只有在正常作期间，主要区域才会主动处理来自客户端的消息。 次要区域接收复制的消息，否则仍处于备用模式。
区域之间的数据复制： 主要区域和次要区域之间的数据复制行为取决于复制配对是使用同步复制还是异步复制。
同步： 在写入作完成之前，消息将复制到次要区域。
此模式提供最安全的保证，因为消息数据必须在主要区域和次要区域中提交。 但同步复制大大增加了传入消息的写入延迟。 它还要求次要区域可用于接受写入作，因此次要区域中的中断会导致写入作失败。
异步： 服务将消息写入主要区域，然后完成写入作。 不久后，它会将消息复制到次要区域。
此模式提供的写入吞吐量高于同步复制，因为写入作期间没有区域间复制延迟。 它还可以容忍次要区域的丢失，同时在主要区域中仍允许写入操作。 但是，如果主要区域中发生中断，则未复制到次要区域的任何数据都可能不可用或丢失。
配置异步复制时，可以设置复制的最大可接受延迟时间。 随时可以使用 Azure Monitor 指标验证当前复制滞后时间。
如果异步复制滞后时间超出指定的最大值，则主要区域开始限制传入请求，以便复制能够赶上。 为了避免这种情况，请选择地理上不太遥远的次要区域，并确保容量足以满足吞吐量。
即使选择异步复制模式，某些元数据类型也会同步复制。
有关详细信息，请参阅 复制模式。
区域中断期间的行为
本部分描述在为 Geo-Replication 配置服务总线命名空间后，当主要区域或次要区域发生中断时，可以预期的情况。
检测和响应： 你负责决定何时将命名空间的次要区域提升为新的主要区域。 即使发生区域中断，Microsoft也不会为你做出此决定或启动该过程。 若要在决定是否故障转移时要考虑的条件，请参阅 建议的方案以触发升级。
有关如何将次要区域提升到新主要区域的详细信息，请参阅 升级流。
升级次要区域时，请在 计划的促销 或 强制升级之间进行选择。 计划的促销活动等待次要区域赶上，然后再接受新流量。 此方法可防止数据丢失，但会导致停机。
在主要区域的中断期间，通常需要执行强制升级。 如果主要区域可用，并且出于其他原因触发促销，则可以改为选择计划的促销。
- 通知： Microsoft不会在区域关闭时自动通知你。 但是，可以使用 Azure 服务运行状况 来了解服务的总体运行状况，包括任何区域故障，并且可以设置 服务运行状况警报 来通知问题。
活动请求： 此行为取决于区域故障是发生在主要区域还是次要区域：
主要区域中断： 如果主要区域不可用，则会终止所有活动请求。 客户端应用程序应在晋级完成后重试操作。
次要区域中断： 在以下情况下，次要区域中的中断可能会导致活动请求出现问题：
如果使用同步复制模式，如果任何次要区域不可用，则主要区域无法完成写入作。
如果使用异步复制模式，则命名空间会限制，在复制滞后时间达到所配置的最大值后不接受新消息。
若要继续使用主要区域中的命名空间，请从 Geo-Replication 配置中删除辅助命名空间。
预期数据丢失： 数据丢失量取决于是执行计划升级还是强制升级，以及复制模式是同步还是异步：
计划内促销： 不会丢失任何数据。 但在区域中断期间，计划内升级可能是不可能的，因为它要求所有主要区域和次要区域都可用。
强制升级、同步复制： 不会丢失任何数据。
强制提升、异步复制： 您可能会遇到一些数据丢失，这些丢失涉及未在次要区域复制的最近消息和未复制的状态更改。 金额取决于复制滞后时间。 若要验证当前复制滞后时间，请使用 Azure Monitor 指标。
如果执行强制升级，即使主要区域可用，也不能恢复丢失的数据。
预期的停机时间： 预期的停机时间量取决于是执行计划内升级还是强制升级：
计划的推广： 计划推广的第一步是将数据复制到备用区域。 此过程通常很快完成，但在某些情况下，由于复制滞后，可能需要花费与复制滞后时间相当的时间才完成。 复制完成后，升级过程通常需要大约 5 到 10 分钟。 域名系统（DNS）服务器有时可能需要更长的时间来更新条目并完全将其记录复制到客户端。
在整个提升过程中，主要区域不接受写入操作。
在发生区域中断期间，此选项可能无法实现，因为它要求所有主要区域和次要区域都可用。
强制升级： 在强制升级期间，服务总线不会等待数据复制完成并立即启动升级。 升级过程通常需要大约 5 到 10 分钟。 有时，在客户端之间完全复制和更新 DNS 条目可能需要更长的时间。
在整个提升过程中，主要区域不接受写入操作。
流量重新路由： 升级完成后，命名空间的 FQDN 指向新的主要区域。 但是，此重定向取决于客户端的 DNS 记录的更新速度，包括其 DNS 服务器是否遵循命名空间 DNS 记录的生存时间（TTL）。
区域恢复
原始主要区域恢复后，如果要将命名空间返回到该区域，请遵循相同的区域升级过程。
如果在区域中断期间进行了强制升级，即使主要区域可用，也不能恢复丢失的数据。
针对区域故障进行测试
若要测试异地复制，请暂时将次要区域提升为主区域，并验证客户端应用程序是否可以在发生最小中断的情况下在区域之间切换。
监视升级持续时间并验证 Runbook 和自动化是否正常工作。 测试后，可以将系统切回到原始配置。
了解升级过程中及升级后可能遇到的潜在停机时间和数据丢失情况。 在一个非生产环境中测试地理复制，该环境镜像了生产命名空间的配置。
元数据地理灾难恢复
高级层支持元数据地理灾难恢复。 此功能可改善灾难恢复方案，包括区域灾难性损失。 地理灾害恢复仅复制命名空间的配置和元数据，并且不会复制消息数据。 为了支持灾难恢复，此功能可确保预配置另一个区域中的命名空间，并准备好立即接受来自客户端的消息。 异地灾难恢复是一种单向恢复解决方案，不支持故障恢复到之前的主要区域。
元数据地理灾难恢复非常适合那些不严格要求保留每条消息并且能容忍在灾难情况下出现一定数据丢失的应用程序。 元数据地理灾难恢复也可能适用于自行复制数据或无需数据复制的应用程序。 例如，如果消息包含稍后转换为缩略图的大型图像，如果可以快速恢复处理另一个区域中的新消息并稍后重新构造丢失的消息，则从失败的区域丢失某些消息可能是可以接受的。
重要
地灾恢复可实现具有相同配置但不复制消息数据的业务连续性。 如果必须复制消息数据，请考虑使用 异地复制。
当您配置元数据地理灾难恢复时，创建客户端应用程序要连接的别名。 别名是一个 FQDN，默认情况下将所有流量定向到主命名空间。
如果主要区域发生故障或发生其他类型的灾难，可以随时手动启动从主要区域到次要区域的单向故障转移。 可以执行 安全故障转移，这会在等待复制完成后再切换到次级副本。 在区域中断期间，此选项可能不可用。 故障转移启动后，它几乎会立即完成。 在故障转移过程中，异地灾难恢复别名会重新指向辅助命名空间，且配对关系会被移除。
本章节总结了地质灾害恢复的重要方面。 查看完整的文档，了解其工作原理。 有关详细信息，请参阅 服务总线地理灾难恢复。
要求
区域支持： 可以选择支持服务总线作为主要命名空间或辅助命名空间的任何 Azure 区域。 无需使用 Azure 配对区域，因此请根据延迟、符合性或数据驻留要求选择次要区域。
层： 若要启用元数据地理灾难恢复，这两个命名空间都必须使用高级层。
分区： 无法将分区命名空间与非分区命名空间配对。
元数据 Geo-Disaster Recovery: 无法将命名空间配置为同时使用 Geo-Replication 和 Geo-Disaster Recovery。
注意事项
角色分配： Microsoft Entra 主命名空间中实体的基于角色的访问控制（RBAC）分配不会复制到辅助命名空间。 在辅助命名空间中手动创建角色分配，以保护对这些实体的访问。
应用程序设计： 在设计客户端应用程序时，地理灾难恢复需要具体的注意事项。 有关详细信息，请参阅 注意事项。
专用终结点： 如果使用专用终结点连接到命名空间，请在主要区域和次要区域中配置网络。 有关详细信息，请参阅专用终结点。
从标准版迁移到高级版的命名空间： 如果命名空间位于标准层中，并且将其迁移到高级层，则必须以不同的方式处理别名。 有关详细信息，请参阅 服务总线标准版到高级版。
成本
启用元数据地理灾害恢复功能时，您需要为主命名空间和辅助命名空间付费。
配置多区域支持
创建元数据 Geo-Disaster Recovery 配对。 若要在主要命名空间和辅助命名空间之间配置灾难恢复，请参阅 设置和故障转移流。
关闭元数据 Geo-灾难恢复。 若要中断命名空间之间的配对，请参阅 设置和故障转移流程。
容量计划和管理
规划多区域部署时，如果一个区域发生故障，请确保这两个区域有足够的容量来处理完整负载。 次要区域在正常运行期间保持被动状态，但故障转移后必须立即处理流量。 规划如何缩放辅助命名空间容量，以便它可以不延迟地接收生产流量。 如果在故障转移过程中可以容忍额外的停机时间，则可以在故障转移期间或故障转移后缩放辅助命名空间容量。 若要减少停机时间，请提前在辅助命名空间中预配容量，使其仍可接收生产负载。
当所有区域都正常时的行为
本部分介绍了当服务总线命名空间配置为地理灾难恢复且主要区域正常运行时的预期情况。
区域之间的流量路由： 客户端应用程序通过命名空间的地理灾难恢复（Geo-Disaster Recovery）别名进行连接，流量路由到主要区域中的主命名空间。
在正常作期间，只有主命名空间主动处理来自客户端的消息。 辅助命名空间保持待机模式，访问数据的任何请求都失败。
区域之间的数据复制： 仅配置元数据在命名空间之间复制。 配置复制持续且异步。
所有消息数据仅保留在主命名空间中，不会复制到辅助命名空间。
区域中断期间的行为
本节内容描述了在将服务总线命名空间配置为地理灾难恢复时，以及主要区域发生中断时的预期情况。
检测和响应： 你负责监视区域运行状况并手动启动故障转移。 Microsoft不会自动发起故障转移或提升次要区域，即使您的主要区域宕机。
有关如何启动故障转移的详细信息，请参阅 故障转移流。
启动故障转移时，选择是执行 安全故障转移 还是 标准故障转移，例如强制故障转移还是手动故障转移。 在故障转移开始之前，安全的故障转移会等待复制完成到次要区域。 此方法可减少元数据丢失，但会导致停机。 安全故障转移要求命名空间位于同一 Azure 订阅中。
在主要区域发生中断时，通常必须执行强制故障转移。 如果主要区域可用，而你出于其他原因触发故障转移，则可以选择计划故障转移。
故障转移是单向操作，因此之后必须重新建立地理灾难恢复配对。 有关详细信息，请参阅 区域恢复。
- 通知： Microsoft不会在区域关闭时自动通知你。 但是，可以使用 Azure 服务运行状况 来了解服务的总体运行状况，包括任何区域故障，并且可以设置 服务运行状况警报 来通知问题。
活动请求： 在故障转移启动时，正在进行的活动请求将终止。 客户端应用程序应在故障转移完成后重试操作。
预期数据丢失：
元数据： 配置和元数据通常复制到辅助命名空间。 元数据复制以异步方式进行，因此最近的更改可能不会复制，尤其是复杂的更改。 在客户端访问辅助命名空间之前验证辅助命名空间的配置。
消息数据： 消息数据不会在区域之间复制。 如果主要区域出现故障，则主命名空间中的消息将变为不可用。
除非灾难性灾难导致主要区域完全丢失，否则消息不会永久丢失。 如果区域恢复，则可以稍后从主命名空间检索消息。
预计停机时间：故障转移通常在 5 到 10 分钟内完成。 客户端可能需要更长的时间才能完全复制和更新 DNS 条目。
流量重新路由： 使用 Geo-Disaster Recovery 别名连接到命名空间的客户端会在故障转移后自动重定向到辅助命名空间。 但是，此重定向取决于 DNS 服务器是否如实遵循命名空间 DNS 记录的 TTL，以及客户端接收到这些已更新的 DNS 记录。
区域恢复
原始主要区域恢复后，必须手动重新建立配对连接并可选择性地执行故障回切。 创建一个新的地理灾难恢复配对，将恢复的区域设为次要区域，然后执行故障转移以返回到原始区域。 此过程涉及发送到临时主命名空间的消息的潜在数据丢失。
如果灾难导致主要区域中所有区域丢失，则可能无法恢复数据。 在其他场景中，从故障转移前保留在主命名空间中的消息数据是可恢复的。 还原访问后，可以从旧的主命名空间获取历史消息。 你负责配置应用程序以接收和处理这些消息。 Microsoft不会自动将其还原到次要区域。
针对区域故障进行测试
为了测试你的响应和灾难恢复过程，请在维护窗口期期间执行计划性故障转移。 启动从主命名空间到辅助命名空间的故障转移，并验证应用程序是否可以连接和处理来自新主命名空间的消息。
监视故障转移的持续时间，并验证运行手册和自动化程序是否正常运作。 测试后，可以将系统切回到原始配置。
了解故障转移过程中及故障转移后可能遇到的潜在停机时间和数据丢失情况。 在一个反映生产命名空间配置的非生产环境中，测试元数据的地理灾难恢复。
用于复原的自定义多区域解决方案
Geo-Replication 和 Geo-Disaster Recovery 提供应对区域中断和其他问题的恢复能力，并且适用于大多数工作负荷。 在以下情况下，这些功能可能不符合你的需求：
你对自定义复制或同时维护多个活动区域有要求。
使用不支持这些功能的服务总线层。
有多种设计模式在服务总线中提供不同类型的多区域支持。 其中许多模式要求部署多个命名空间，并配置应用程序以适当地使用它们。 有关详细信息，请参阅以下资源：
服务维护期间的系统弹性能力
服务总线会定期维护。 在计划内维护期间，命名空间将移动到包含最新更新的冗余节点。 在移动期间，客户端 SDK 断开连接，然后自动重新连接到命名空间。 升级通常在 30 秒内完成。 应用程序必须做好准备，以应对在维护期间可能发生的暂时性网络断开连接。
有关详细信息，请参阅 服务总线的 Azure 维护事件。
备份和还原
服务总线不是为长期数据存储设计的。 数据通常仅在短时间内存储在主题或队列中。 然后，它将处理或保存到另一个数据存储系统中，然后将其删除。 由于此设计，服务总线会自动维护消息数据的副本，但不为该数据提供任何备份和还原功能。
对于需要长期消息保留的方案，请考虑实现到 Azure 存储或其他持久存储服务的应用程序级存档。
服务级别协议
Azure 服务的服务级别协议 (SLA) 描述了每个服务的预期可用性，以及解决方案为实现该可用性预期而必须满足的条件。 有关详细信息，请参阅 联机服务的 SLA。
服务总线为所有命名空间提供 SLA（服务水平协议）。 当命名空间满足以下条件时，可用性 SLA 更高：
- 它使用的是高级层。
- 它位于具有可用性区域的区域中。
- 它使用分区。