你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

特定 Azure 服务的复原能力检查表

项目
08/02/2023

复原能力是指系统能够在发生故障后进行恢复，然后继续正常运行。每项技术都有自己的特定故障模式，这是在设计和实现应用程序时必须考虑的。请使用此检查表查看特定 Azure 服务的复原能力注意事项。有关设计可复原应用程序的详细信息，请参阅设计可靠的 Azure 应用程序。

应用服务

使用“标准”或“高级”层。 这些层支持过渡槽位和自动备份。有关详细信息，请参阅 Azure 应用服务计划深入概述

避免纵向扩展或缩减。 应选择满足典型负载下的性能要求的层和实例大小，然后横向扩展实例来处理流量的更改。纵向扩展或缩减可能触发应用程序重启。

将配置存储为应用设置。 使用应用设置将配置设置保存为应用设置。在资源管理器模板中或使用 PowerShell 定义设置，以便可以在更可靠的自动部署/更新过程中应用这些设置。有关详细信息，请参阅在 Azure 应用服务中配置 Web 应用。

为生产和测试创建单独的应用服务计划。 不要使用生产部署中的槽位进行测试。同一应用服务计划中的所有应用共享相同的 VM 实例。如果将生产和测试部署放在同一个计划中，可能会对生产部署产生负面影响。例如，负载测试可能使实时生产站点降级。如果将测试部署放入单独的计划，则可将其与生产版本相隔离。

将 Web 应用与 Web API 相区分。 如果解决方案包含 Web 前端和 Web API，请考虑将其分解为单独的应用服务应用。使用这种设计可以更方便地按工作负荷分解解决方案。可以在单独的应用服务计划中运行 Web 应用和 API，以便对它们进行单独缩放。如果一开始不需要该级别的可伸缩性，可以先将应用部署到同一计划中，以后再根据需要将其移至独立的计划中。

部署区域冗余应用服务计划。 在受支持的区域，应用服务计划可以部署为区域冗余，这意味着实例会自动跨可用性区域分布。应用服务自动在区域之间分配流量，并在区域遇到服务中断时处理故障转移。有关详细信息，请参阅将应用服务迁移到可用性区域支持。

避免使用应用服务备份功能来备份 Azure SQL 数据库。 应该使用 SQL 数据库自动备份。应用服务备份会将数据库导出至 SQL BACPAC 文件，这会消耗 DTU。

部署到过渡槽位。 创建部署槽位用于过渡。将应用程序更新部署到过渡槽位，并在交换到生产环境之前验证部署。这可以减少生产环境中出现更新不当的可能性。此外，可确保所有实例在交换到生产环境之前已预热。许多应用程序的预热和冷启动时间很长。有关详细信息，请参阅为 Azure 应用服务中的 Web 应用设置过渡环境。

创建一个部署槽位用于保存上次已知正常 (LKG) 的部署。 将更新部署到生产环境时，请将前一个生产部署移到 LKG 槽位中。这可以更方便地回滚错误部署。如果以后发现问题，可以快速还原到 LKG 版本。有关详细信息，请参阅基本 Web 应用程序。

启用诊断日志记录，包括应用程序日志记录和 Web 服务器日志记录。日志记录对于监视和诊断很重要。请参阅在 Azure 应用服务中为 Web 应用启用诊断日志记录

记录 Blob 存储的日志。 这可以更方便地收集和分析数据。

为日志创建单独的存储帐户。 不要对日志和应用程序数据使用相同的存储帐户。这有助于防止日志记录降低应用程序的性能。

监视性能。 使用 New Relic 或 Application Insights 等性能监视服务来监视承受负载时的应用程序性能和行为。性能监视提供应用程序的实时深入信息。可以使用它来诊断问题，以及执行故障根本原因分析。

Azure 负载均衡器

选择标准 SKU。 标准负载均衡器提供了基本版负载均衡器不具有的可靠性维度，即可用性区域和区域复原能力。这意味着当区域关闭时，区域冗余标准负载均衡器将不会受到影响。这可确保部署能够承受区域中的区域故障。此外，标准负载均衡器支持全局负载均衡，确保应用程序也不会受到区域故障的影响。

至少预配两个实例。 在后端部署至少具有两个实例的 Azure LB。单个实例可能会导致单一故障点。若要规模构建，可能需要将 LB 与虚拟机规模集配对。

使用出站规则。 出站规则可确保不会因 SNAT 端口耗尽而遇到连接故障。详细了解出站连接性。虽然出站规则有助于改进适用于小型到中型部署的解决方案，但对于生产工作负荷，我们建议将标准负载均衡器或任何子网部署与 VNet NAT 耦合。

应用程序网关

至少预配两个实例。 部署至少包含两个实例的应用程序网关。单个实例会成为单一故障点。使用两个或更多个实例实现冗余和可伸缩性。若要满足 SLA，必须预配两个或更多个中型或大型实例。

Azure Cosmos DB

配置区域冗余。 使用区域冗余时，Azure Cosmos DB 会跨可用性区域同步复制所有写入。发生区域服务中断时，它会自动进行故障转移。有关详细信息，请参阅使用 Azure Cosmos DB 实现高可用性。

跨区域复制数据库。 Azure Cosmos DB 允许将任意数量的 Azure 区域与一个 Azure Cosmos DB 数据库帐户关联。 Azure Cosmos DB 数据库可以包含一个写入区域和多个读取区域。如果写入区域发生故障，可以从另一个副本读取。客户端 SDK 会自动处理此操作。还可以将写入区域故障转移到另一个区域。有关详细信息，请参阅如何使用 Azure Cosmos DB 进行全局数据分配。

事件中心

使用检查点。事件使用者应该根据某种预定义的间隔将其当前位置写入持久性存储。这样，如果使用者遇到故障（例如，使用者崩溃，或主机故障），则新实例可以继续从上一个记录的位置读取流。有关详细信息，请参阅事件使用者。

处理重复消息。 如果某个事件使用者故障，则会从上一个记录的检查点恢复消息处理。在上一个检查点之后已经处理的任何消息都会重新处理。因此，消息处理逻辑必须是幂等的，否则应用程序必须能够删除重复消息。

处理异常。 事件使用者通常以循环的方式处理一批消息。应该在该处理循环内处理异常，避免在单个消息导致异常的情况下丢失一整批消息。

使用死信队列。 如果处理消息时导致出现非暂时性故障，请将该消息置于死信队列中，以便跟踪状态。可以根据情况在以后重试消息、应用补偿事务，或者执行其他操作。请注意，事件中心没有任何内置的死信队列功能。可以使用 Azure 队列存储或服务总线来实现死信队列，也可以使用 Azure Functions 或某个其他的事件处理机制。

配置区域冗余。在命名空间上启用区域冗余后，事件中心会自动复制多个可用性区域之间的更改。如果一个可用性区域发生故障，则会自动进行故障转移。有关详细信息，请参阅可用性区域。

通过故障转移到辅助的事件中心命名空间实施灾难恢复。 有关详细信息，请参阅 Azure 事件中心异地灾难恢复。

用于 Redis 的 Azure 缓存

配置区域冗余。 在缓存上启用区域冗余后，Azure Cache for Redis 会将托管缓存的虚拟机分散到多个可用性区域。区域冗余在数据中心服务中断时提供高可用性和容错能力。有关详细信息，请参阅为 Azure Cache for Redis 启用区域冗余。

配置异地复制。 “异地复制”提供一种用于链接两个高级层 Azure Redis 缓存实例的机制。写入主缓存的数据将复制到辅助只读缓存。有关详细信息，请参阅如何为 Azure Cache for Redis 配置异地复制

配置数据持久性。 使用 Redis 持久性可以在 Redis 中持久存储数据。还可以获取快照并备份数据，以便在出现硬件故障时进行加载。有关详细信息，请参阅如何为高级层 Azure Cache for Redis 配置数据持久性

如果将 Azure Cache for Redis 用作临时数据缓存而不是持久性存储，则这些建议可能不适用。

认知搜索

预配多个副本。 至少使用两个副本实现读取高可用性，或至少使用三个副本实现读写高可用性。

使用区域冗余。 可以跨多个可用性区域部署认知搜索副本。此方法可帮助服务在数据中心中断时保持正常运行。有关详细信息，请参阅 Azure 认知搜索的可靠性

为多区域部署配置索引器。 若要进行多区域部署，请考虑使用索引连续性选项。

如果数据源是异地复制的，通常应该将每个区域性 Azure 认知搜索服务的每个索引器指向其本地数据源副本。但是，对于存储在 Azure SQL 数据库的大型数据集，不建议使用此方法。原因在于，Azure 认知搜索无法从辅助 SQL 数据库副本执行增量索引，而只能从主副本执行。应该将所有索引器指向主副本。故障转移后，请将 Azure 认知搜索索引器指向新的主副本。
如果数据源不是异地复制的，请将多个索引器指向同一个数据源，以便多个区域中的 Azure 认知搜索服务可从数据源连续独立地编制索引。有关详细信息，请参阅 Azure 搜索性能和优化注意事项。

服务总线

对生产工作负荷使用高级层。服务总线高级消息传送提供专用和预留的处理资源与内存容量来支持可预测的性能和吞吐量。使用高级消息传送层还能访问最初只为高级用户提供的新功能。可以根据预期工作负荷确定消息传送单元数。

处理重复消息。如果发布者在发送消息后立即失败，或者遇到网络或系统问题，它可能无法记录该消息已送达，而是将同一条消息发送到系统两次。启用重复检测后，服务总线可以处理此问题。有关详细信息，请参阅重复检测。

处理异常。发生用户错误、配置错误或其他错误时，消息传送 API 会生成异常。客户端代码（发送方和接收方）应在其代码中处理这些异常。此机制在批处理中尤为重要，在其中可以使用异常处理来避免丢失整批消息。有关详细信息，请参阅服务总线消息传送异常。

重试策略。服务总线允许为应用程序选择最佳的重试策略。默认策略是最多允许重试 9 次，并等待 30 秒，但可以进一步调整此策略。有关详细信息，请参阅重试策略 - 服务总线。

使用死信队列。如果多次重试后仍然无法处理某条消息或将其传送给任何接收方，该消息将移到死信队列。实施一个过程以从死信队列读取消息、检查消息，并解决问题。根据具体的场景，可按原样重试发送消息、对其进行更改并重试，或放弃消息。有关详细信息，请参阅服务总线死信队列概述。

使用区域冗余。在命名空间上启用区域冗余后，Azure 服务总线会自动复制多个可用性区域之间的更改。如果一个可用性区域发生故障，则会自动进行故障转移。有关详细信息，请参阅使应用程序免受服务总线中断和灾难影响的最佳实践。

使用异地灾难恢复。异地灾难恢复确保在整个 Azure 区域或数据中心由于灾难而不可用时，数据处理可以继续在不同的区域或数据中心进行。有关详细信息，请参阅 Azure 服务总线异地灾难恢复。

存储

使用区域冗余存储。 区域冗余存储 (ZRS) 跨主要区域中的三个 Azure 可用性区域同步复制数据。如果可用性区域发生服务中断，Azure 存储会自动转移到备用区域。有关详细信息，请参阅 Azure 存储冗余。

使用异地冗余时，请配置读取访问。 如果使用多区域体系结构，请使用适当的存储层来实现全局冗余。使用 RA-GRS 或 RA-GZRS，数据将被复制到次要区域。 RA-GRS 在主要区域使用本地冗余存储 (LRS)，而 RA-GZRS 在主要区域使用区域冗余存储 (ZRS)。这两种配置都提供对次要区域中数据的只读访问权限。如果主要区域中发生存储故障，应用程序可以从次要区域读取数据（如果已针对这种可能性进行了设计）。有关详细信息，请参阅 Azure 存储冗余。

对于虚拟机磁盘，使用托管磁盘。托管磁盘为可用性集中的虚拟机提供更高的可靠性，因为这些磁盘彼此充分隔离，可避免单一故障点。此外，托管磁盘不受存储帐户中创建的 VHD 的 IOPS 限制。有关详细信息，请参阅在 Azure 中管理 Windows 虚拟机的可用性。

对于队列存储，请在另一个区域中创建备份队列。 对于队列存储，只读副本的作用有限，因为无法将项排队或取消排队。应在另一个区域中的某个存储帐户中创建备份队列。如果发生 Azure 存储故障，应用程序可以使用备份队列，直到主要区域重新可用。这样，应用程序就可以在故障期间继续处理新请求。

SQL 数据库

使用“标准”或“高级”层。 这些层提供更长的时间点还原期限（35 天）。有关详细信息，请参阅 SQL 数据库选项和性能。

启用 SQL 数据库审核。 审核可用于诊断恶意攻击或人为错误。有关详细信息，请参阅 SQL 数据库审核入门。

使用活动异地复制使用活动异地复制在一个不同的区域中创建可读取的辅助副本。如果主数据库出现故障，或者只是需要脱机，可以手动故障转移到任何辅助数据库。在故障转移之前，辅助数据库将保持只读状态。有关详细信息，请参阅 SQL 数据库活动异地复制。

使用分片。 考虑使用分片将数据库横向分区。分片可提供故障隔离。有关详细信息，请参阅使用 Azure SQL 数据库进行横向扩展。

发生人为错误后使用时间点还原进行恢复。 时间点还原可将数据库还原到以前的某个时间点。有关详细信息，请参阅使用自动数据库备份恢复 Azure SQL 数据库。

发生服务中断后使用异地还原进行恢复。 异地还原可从异地冗余的备份还原数据库。有关详细信息，请参阅使用自动数据库备份恢复 Azure SQL 数据库。

Azure Synapse Analytics

不要禁用异地备份。 默认情况下，Synapse Analytics 会每 24 小时对专用 SQL 池中的数据进行一次完整备份，以便于灾难恢复。建议不要关闭此功能。有关详细信息，请参阅异地备份。

VM 中运行的 SQL Server

备份数据库。如果已在使用 Azure 备份来备份 VM，请考虑使用 DPM 为 SQL 工作负荷配置 Azure 备份。使用此方法时，将为组织配置一个备份管理员角色，并为 VM 和 SQL Server 创建统一的恢复过程。否则，请使用 Microsoft Azure 的 SQL Server 托管备份。

流量管理器

执行手动故障回复。 流量管理器故障转移后，请执行手动故障回复而不是自动故障回复。在故障回复之前，请验证是否所有应用程序子系统的运行状况都正常。否则，可能会造成应用程序在数据中心之间来回翻转的情况。有关详细信息，请参阅在多个区域中运行 VM 以实现高可用性。

创建运行状况探测终结点。 创建一个自定义终结点用于报告应用程序的总体运行状况。这样，当任何关键路径（而不仅仅是前端）发生故障时，流量管理器可故障转移。如果任何关键依赖项不正常或不可访问，终结点应返回 HTTP 错误代码。但是，不会报告非关键服务发生的错误。否则，运行状况探测可能触发不必要的故障转移，并产生误报。有关详细信息，请参阅流量管理器终结点监视和故障转移。

虚拟机

避免在单个 VM 上运行生产工作负荷。 单个 VM 部署不能弹性应对计划内或计划外维护。应当将多台虚拟机放入一个可用性集或虚拟机规模集，并在其前面使用负载均衡器。

预配 VM 时指定可用性集。 目前，没有任何方法可以在预配 VM 后将 VM 添加到可用性集。将新的 VM 添加到现有的可用性集时，请务必为该 VM 创建一个 NIC，并将该 NIC 添加到负载均衡器上的后端地址池。否则，负载均衡器不会将网络流量路由到该 VM。

将每个应用程序层放入不同的可用性集。 在 N 层应用程序中，不要将不同层中的 VM 放入同一个可用性集。可用性集中的 VM 放置在不同的容错域 (FD) 和更新域 (UD) 中。但是，为了获得 FD 与 UD 的冗余优势，可用性集中的每个 VM 必须能够处理相同的客户端请求。

使用 Azure Site Recovery 复制 VM。 使用 Site Recovery 复制 Azure VM 时，所有 VM 磁盘将以异步方式持续复制到目标区域。每隔几分钟就会创建恢复点。这可以实现分钟量级的恢复点目标 (RPO)。可以开展灾难恢复演练任意次，这不会影响生产应用程序或正在进行的复制。有关详细信息，请参阅运行灾难恢复到 Azure 的演练。

根据性能要求选择适当的 VM 大小。 将现有工作负荷转移到 Azure 时，首先请使用与本地服务器最匹配的 VM 大小。然后测量与 CPU、内存和磁盘 IOPS 有关的实际工作负荷的性能，并根据需要调整大小。这有助于确保应用程序在云环境中的行为符合预期。此外，如果需要多个 NIC，请注意每种大小的 NIC 限制。

为 VHD 使用托管磁盘。托管磁盘为可用性集中的虚拟机提供更高的可靠性，因为这些磁盘彼此充分隔离，可避免单一故障点。此外，托管磁盘不受存储帐户中创建的 VHD 的 IOPS 限制。有关详细信息，请参阅在 Azure 中管理 Windows 虚拟机的可用性。

将应用程序安装在数据磁盘而不是 OS 磁盘上。 否则，可能会达到磁盘大小限制。

使用 Azure 备份来备份 VM。 备份可防范意外的数据丢失。有关详细信息，请参阅使用恢复服务保管库保护 Azure 虚拟机。

启用诊断日志。 包括基本运行状况指标、基础结构日志和启动诊断。如果 VM 陷入不可启动状态，启动诊断可帮助诊断启动失败的原因。有关详细信息，请参阅 Azure 诊断日志概述。

配置 Azure Monitor。 收集和分析来自 Azure 虚拟机的监视数据，包括来宾操作系统以及在其中运行的工作载荷，请参阅 Azure 监视器与快速入门：Azure 监视器。

虚拟网络

若要允许或阻止公共 IP 地址，请向子网添加网络安全组。 阻止恶意用户的访问，或只允许有权访问应用程序的用户访问。

创建自定义运行状况探测。 负载均衡器运行状况探测可以测试 HTTP 或 TCP。如果 VM 运行 HTTP 服务器，HTTP 探测的运行状况指示效果比 TCP 探测更好。对于 HTTP 探测，请使用自定义终结点来报告应用程序（包括所有关键依赖项）的总体运行状况。有关详细信息，请参阅 Azure 负载均衡器概述。

不要阻止运行状况探测。 负载均衡器运行状况探测信息从已知 IP 地址 168.63.129.16 发送。不要在任何防火墙策略或网络安全组规则中阻止与此 IP 之间的流量。阻止运行状况探测会导致负载均衡器从轮转项目中删除 VM。

启用负载均衡器日志记录。 这些日志显示后端有多少个 VM 由于失败的探测响应而未收到网络流量。有关详细信息，请参阅 Azure 负载均衡器的 Log Analytics。