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

实现全面冗余

在应用程序中构建冗余，以避免出现单一故障点

有弹性的应用程序围绕故障路由。 标识应用程序中的关键路径。 该路径中的每个点是否都存在冗余？ 子系统出现故障时，应用程序是否会故障转移到其他组件？

建议

考虑业务需求。 在系统中生成的冗余量会影响成本和复杂度。 你的体系结构应根据业务要求进行调整，例如恢复时间目标 (RTO) 和恢复点目标 (RPO)。 你还应考虑你的性能要求，以及你的团队管理复杂资源集的能力。

请考虑多区域和多地区体系结构。 确保了解可用性区域和地区如何提供复原能力和不同的体系结构权衡集。

Azure 可用性区域是一个地区内的独立数据中心集。 通过使用可用性区域，可以灵活应对单个数据中心或整个可用性区域的故障。 可以使用可用性区域在成本、风险缓解、性能和可恢复性之间进行权衡。 例如，在体系结构中使用区域冗余服务时，Azure 在地理隔离的实例之间提供自动数据复制和故障转移，从而缓解许多不同类型的风险。

如果你有一个任务关键型工作负载，并且需要降低地区范围的中断风险，请考虑使用多地区部署。 虽然多地区部署使你免受地区性灾难的侵害，但它们需要付出代价。 多地区部署比单地区部署昂贵，其管理也更复杂。 需要使用操作过程处理故障转移和故障回复。 根据 RPO 要求，可能需要接受略低的性能才能启用跨地区数据复制。 对于某些业务场景，额外的成本和复杂性可能是合理的。

提示

对于许多工作负载，区域冗余体系结构提供了最好的一组权衡。 如果你的业务要求表明你需要缓解地区范围内中断的不太可能的风险，并且你已准备好接受这种方法所涉及的权衡，请考虑使用多地区体系结构。

若要详细了解如何设计解决方案以使用可用性区域和地区，请参阅 有关使用可用性区域和地区的建议。

将 VM 放在负载均衡器之后。 请勿将一个 VM 用于任务关键的工作负载。 而是将多个 VM 放置于负载均衡器之后。 如果任何 VM 变得不可用，负载均衡器会向其余正常运行的 VM 分配流量。 若要了解如何部署此配置，请参阅[用于提高可伸缩性和可用性的多个 VM][multi-vm-blueprint].。

复制数据库。 Azure SQL 数据库和 Azure Cosmos DB 会自动复制地区内的数据，并且可以配置为跨可用性区域复制以提高复原能力。 还可以选择启用跨地区异地复制。 Azure SQL 数据库和 Azure Cosmos DB 的异地复制在一个或多个次要区域中创建数据的可读次要副本。 如果主要地区发生中断，数据库可以故障转移到次要地区进行写入。 根据复制配置，你可能会因未复制的事务而丢失一些数据。

如果使用的是 IaaS 数据库解决方案，请选择支持复制和故障转移的解决方案，如 SQL Server AlwaysOn 可用性组。

为提高可用性而分区。 数据库分区通常用于提高可伸缩性，但它还可以提高可用性。 如果一个分片出现故障，仍可以访问其他分片。 一个分片中的故障仅中断总事务的子集。

多地区解决方案

下图显示了使用 Azure 流量管理器处理故障转移的多区域应用程序。

如果在多地区解决方案中使用流量管理器，请考虑以下建议：

同步前端和后端故障转移。 使用流量管理器将前端故障转移。 如果无法访问一个区域中的前端，流量管理器会将新请求路由到次要区域。 根据后端组件和数据库解决方案，可能需要协调对后端服务和数据库的故障转移。

使用自动故障转移，但手动进行故障回复。 将流量管理器用于自动故障转移，而不用于自动故障回复。 自动故障回复存在风险，即可能在区域尚未完全正常之前切换到主要区域。 请改为验证所有应用程序子系统均正常运行，然后再手动进行故障回复。 此外，可能需要在故障回复前检查数据一致性，具体取决于数据库。

为此，请在故障转移后禁用流量管理器的主终结点。 请注意，如果探测的监视间隔较短，并且允许的故障数量较小，则故障转移和故障回复将在短时间内发生。 在某些情况下，禁用将无法及时完成。 为了避免未经确认的故障回复，还应考虑实现一个可以验证所有子系统是否正常的运行状况终结点。 请参阅运行状况终结点监视模式。

为流量管理器包括冗余。 流量管理器是一个潜在的故障点。 查看流量管理器 SLA，然后决定仅使用流量管理器是否能满足高可用性的业务需求。 如果不能，请考虑添加另一个流量管理解决方案作为故障回复机制。 如果 Azure 流量管理器服务出现故障，请将 DNS 中的 CNAME 记录更改为指向其他流量管理服务。