你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
实现全面冗余
在应用程序中构建冗余，以避免出现单一故障点
有弹性的应用程序围绕故障路由。 标识应用程序中的关键路径。 该路径中的每个点是否都存在冗余？ 子系统出现故障时，应用程序是否会故障转移到其他组件？
在完美的实现中，添加统一冗余可能会呈指数级增加系统的可用性。 例如，假设你有 N 等效的均衡组件，其中包括：
- 可以独立故障，同时从池中删除
- 具有相同状态或无状态
- 在故障期间没有正在进行的工作，在故障期间永久丢失
- 功能相同
- 彼此之间没有依赖关系
- 处理容量减少而不出现额外故障
如果每个组件都有其可用性 A，则可以使用公式 1 - (1 - A)^N计算总体系统可用性。
建议
考虑业务需求。 在系统中生成的冗余量会影响成本和复杂度。 你的体系结构应根据业务要求进行调整，例如恢复时间目标 (RTO) 和恢复点目标 (RPO)。 你还应考虑你的性能要求，以及你的团队管理复杂资源集的能力。
请考虑多区域和多地区体系结构。 确保了解可用性区域和地区如何提供复原能力和不同的体系结构权衡集。
Azure 可用性区域是一个地区内的独立数据中心集。 通过使用可用性区域，可以灵活应对单个数据中心或整个可用性区域的故障。 可以使用可用性区域在成本、风险缓解、性能和可恢复性之间进行权衡。 例如，在体系结构中使用区域冗余服务时，Azure 在地理隔离的实例之间提供自动数据复制和故障转移，从而缓解许多不同类型的风险。
如果你有一个任务关键型工作负载，并且需要降低地区范围的中断风险，请考虑使用多地区部署。 虽然多地区部署使你免受地区性灾难的侵害，但它们需要付出代价。 多地区部署比单地区部署昂贵，其管理也更复杂。 需要使用操作过程处理故障转移和故障回复。 根据 RPO 要求，可能需要接受略低的性能才能启用跨地区数据复制。 对于某些业务场景，额外的成本和复杂性可能是合理的。
提示
对于许多工作负载，区域冗余体系结构提供了最好的一组权衡。 如果你的业务要求表明你需要缓解地区范围内中断的不太可能的风险，并且你已准备好接受这种方法所涉及的权衡，请考虑使用多地区体系结构。
若要详细了解如何设计解决方案以使用可用性区域和地区，请参阅 有关使用可用性区域和地区的建议。
将 VM 放在负载均衡器之后。 请勿将一个 VM 用于任务关键的工作负载。 而是将多个 VM 放置于负载均衡器之后。 如果任何 VM 变得不可用，负载均衡器会向其余正常运行的 VM 分配流量。
复制数据库。 Azure SQL 数据库和 Azure Cosmos DB 会自动复制地区内的数据，并且可以配置为跨可用性区域复制以提高复原能力。 还可以选择启用跨地区异地复制。 Azure SQL 数据库和 Azure Cosmos DB 的异地复制在一个或多个次要区域中创建数据的可读次要副本。 如果主要地区发生中断，数据库可以故障转移到次要地区进行写入。 根据复制配置，你可能会因未复制的事务而丢失一些数据。
如果使用的是 IaaS 数据库解决方案，请选择支持复制和故障转移的解决方案，如 SQL Server AlwaysOn 可用性组。
为提高可用性而分区。 数据库分区通常用于提高可伸缩性，但它还可以提高可用性。 如果一个分片出现故障，仍可以访问其他分片。 一个分片中的故障仅中断总事务的子集。
测试和验证冗余组件。 可靠性在简单性和添加冗余方面的许多方面都有利于提高复杂性。 若要确保添加冗余实际上会导致更高的可用性，应验证以下内容：
- 系统 能否可靠地 检测正常和不正常的冗余组件，并安全地迅速地将其从组件池中删除？
- 系统 能否可靠地 横向扩展和在冗余组件中？
- 例行、即席和紧急工作负荷操作能否处理冗余？
多地区解决方案
下图显示了使用 Azure 流量管理器处理故障转移的多区域应用程序。
如果在多区域解决方案中使用流量管理器或 Azure Front Door 作为故障转移路由机制，请考虑以下建议：
同步前端和后端故障转移。 使用路由机制对前端进行故障转移。 如果前端在一个区域无法访问，故障转移会将新请求路由到次要区域。 根据后端组件和数据库解决方案，可能需要协调后端服务和数据库的故障转移。
使用自动故障转移，但手动进行故障回复。 使用自动化进行故障转移，但不进行故障恢复。 自动故障回复存在风险，即可能在区域尚未完全正常之前切换到主要区域。 请改为验证所有应用程序子系统均正常运行，然后再手动进行故障回复。 此外，还应在故障回复之前检查数据一致性。
为此，请在故障转移后禁用主终结点。 请注意，如果探测的监视间隔较短，并且允许的故障数量较小，则故障转移和故障回复将在短时间内发生。 在某些情况下，禁用将无法及时完成。 为了避免未经确认的故障回复，还应考虑实现一个可以验证所有子系统是否正常的运行状况终结点。 请参阅运行状况终结点监视模式。
为路由解决方案提供冗余。 考虑为关键任务 Web 应用程序设计全局路由冗余解决方案。