自我修复和自我保护的体系结构策略

适用于此 Azure Well-Architected 框架可靠性清单建议：

本指南介绍了将自我保存和自我修复功能构建到应用程序体系结构中以优化可靠性的建议。

自我保留功能可增强工作负荷的复原能力。 它们可降低完全中断的可能性，并允许工作负荷在发生故障时正常运行或处于降级状态。 自我修复功能通过生成故障检测和自动纠正措施来应对故障，从而帮助你避免停机。

定义

冗余设计

保护工作负荷免受故障的最有效策略之一是将冗余构建到其所有组件中，并避免单一故障点。 能够将组件或整个工作负荷故障故障转移到冗余资源，这为处理系统中大多数故障提供了一种高效方法。

在不同级别生成冗余，考虑冗余基础结构组件，例如计算、网络和存储，并考虑部署解决方案的多个实例。 根据业务需求，可以在单个区域或跨区域生成冗余。 还可以确定是需要主动-主动还是主动-被动设计来满足恢复要求。 有关详细信息，请参阅用于 设计冗余的体系结构策略 ，以及 使用可用性区域和区域的体系结构策略。

自我保存设计

若要设计工作负荷以自我保存，请遵循基础结构和应用程序体系结构设计模式来优化工作负荷的复原能力。 若要最大程度地减少遇到完整应用程序中断的可能性，请通过消除单一故障点并最大程度地减少故障的爆破半径来提高解决方案的复原能力。 本文中的设计方法提供了多种选项，用于增强工作负荷的复原能力，并满足工作负荷定义的 可靠性目标。

基础结构设计指南和模式

在基础结构级别， 冗余体系结构设计 应支持关键流，同时跨 可用性区域或区域部署资源。 尽可能实现 自动缩放 。 自动缩放有助于保护工作负荷免受活动意外的突发，进一步强化基础结构。

使用部署标记模式或大容量头模式，在出现问题时最大程度地减少爆炸半径。 如果单个组件不可用，这些模式有助于保持工作负荷可用。 将以下应用程序设计模式与自动缩放策略结合使用。

• 部署戳模式：预配、管理和监视各种资源组，以托管和作多个工作负荷或租户。 每个副本称为 戳记，有时称为 服务单元、 缩放单元或 单元。

• 大容量模式：根据使用者负载和可用性要求，将服务实例分区到不同的组（称为 池）。 此设计有助于隔离故障，并允许某些使用者维持服务功能，即使在故障期间也是如此。

应用程序设计指南和模式

避免在应用程序设计中生成整体应用程序。 使用通过明确定义的标准相互通信的松散耦合服务或微服务，以减少单个组件发生故障时出现广泛问题的风险。 例如，可以标准化使用服务总线来处理所有异步通信。 标准化通信协议可确保应用程序设计一致和简化，这使得工作负载在发生故障时更易于故障排除。 在实际情况下，首选组件之间的异步通信而不是同步通信，以最大程度地减少超时问题，例如死信。

使用行业证明的模式来帮助你制定设计标准并简化体系结构的各个方面。 可以在 可靠性模式 文章中找到有助于支持可靠性的设计模式。

自我修复设计

若要为自我修复设计工作负荷，请实现故障检测，以便触发自动响应并正常恢复关键流。 启用日志记录以提供有关失败的性质和恢复成功的作见解。 为关键流实现自我修复所要采用的方法取决于为该流和流组件和依赖项定义 的可靠性目标 。

基础结构设计指南

在基础结构级别，关键流应受冗余体系结构设计的支持，并为支持它的组件启用自动故障转移。 可以为以下类型的服务启用自动故障转移：

• 计算资源：Azure 虚拟机规模集和大多数平台即服务（PaaS）计算服务都可以配置为自动故障转移。

• 数据库：可以使用 Azure SQL 故障转移群集、AlwaysOn 可用性组或 PaaS 服务的内置功能等解决方案为关系数据库配置自动故障转移。 NoSQL 数据库具有类似的群集功能和 PaaS 服务的内置功能。

• 存储：通过自动故障转移使用 冗余存储选项 。

应用程序设计指南

除了使用支持可靠性 的设计模式 外，其他可帮助开发自我修复机制的策略包括：

• 对长时间运行的事务使用检查点：如果长时间运行的作失败，检查点可以提供复原能力。 当作重新启动时，例如，如果另一个虚拟机选取了该作，则可以从最后一个检查点恢复。 请考虑实现一种机制，以定期记录有关任务的状态信息。 将此状态保存在持久存储中，该存储可由运行任务的进程的任何实例访问。 如果进程关闭，则可以使用另一个实例从最后一个检查点恢复它正在执行的工作。 有一些库提供此功能，例如 NServiceBus 和 MassTransit。 它们以透明方式保留状态，其中间隔与 Azure 服务总线中队列中的消息处理保持一致。

• 实现自动自我修复作： 检测到预先确定的运行状况更改时，使用监视解决方案触发的自动作。 例如，如果监视检测到 Web 应用未响应请求，则可以通过 PowerShell 脚本生成自动化来重启应用服务。 根据团队的技能集和首选开发技术，使用 Webhook 或函数生成更复杂的自动化作。 有关使用函数响应数据库限制的示例，请参阅 基于事件的云自动化 参考体系结构。 使用自动化作可帮助你快速恢复，并最大程度地减少人工干预的必要性。

实现正常降级模式

尽管自我保存和自我修复机制，但仍可能会遇到一个或多个组件在一定时间内变得不可用的情况。 在这些情况下，理想情况下，工作负荷可以保持足够的功能，使业务继续处于降级状态。 若要确保这是可能的，请设计和实现正常降级模式。 这是一个不同的工作流，在响应失败的组件时启用。 设计和实现的注意事项包括：

• 故障检测和自动启动： 监视和警报系统应检测到降级和失败的组件，因此请使用这些信号生成一个工作流，以确定何时切换到正常降级模式。 然后，工作流应自动将调用重新路由到受影响的组件以及从受影响的组件重新路由到备用组件或其他类似的作。
• 实现降级的用户体验： 在正常降级模式下为用户包括通知机制，以确保他们知道保留哪些功能以及更改的内容。 这通常反映在绑定到工作负荷不同功能的消息中，例如，将项目添加到购物车时弹出。
• 生成替代路径以完成工作负荷的基本功能： 反思工作负荷 的关键流 ，并确定在核心组件不可用时如何维护这些流。 例如，如果数据库关闭，应用程序可能会使用缓存数据切换到只读模式。 为了进一步说明此示例，如果付款网关已关闭，则使用缓存的数据可能允许用户保存购物车，并在以后完成购买。

实现处理暂时性故障的机制

暂时性故障（如网络超时）是云工作负荷的常见问题，因此，在生产环境中运行工作负荷时，具有处理这些故障的机制可以最大程度地减少停机时间和故障排除工作。 由于大多数由于暂时性故障而失败的作在重试作之前允许足够的时间会成功，因此使用重试机制是处理暂时性故障的最常见方法。 设计重试策略时，请考虑以下事项：

有关建议和注意事项的完整回顾，请参阅 暂时性故障 设计指南。

实现后台作业

后台作业是通过将任务与用户界面（UI）分离来增强系统可靠性的有效方法。 如果任务不需要用户输入或反馈，并且不会影响 UI 响应能力，则将其实现为后台作业。

后台作业的常见示例包括：

• CPU 密集型作业，例如执行复杂计算或分析结构模型。
• I/O 密集型作业，例如运行多个存储作或为大型文件编制索引。
• 批处理作业，例如定期更新数据或在特定时间处理任务。
• 长时间运行的工作流，例如完成订单或预配服务和系统。

有关建议和注意事项的完整审查的详细指南，请参阅 后台作业 设计指南。

Azure 便利化

大多数 Azure 服务和客户端 SDK 都包含重试机制。 但它们有所不同，因为每个服务都有不同的特性和要求，因此每个重试机制都会优化到特定的服务。 有关详细信息，请参阅 有关暂时性故障处理的建议。

对通知（如电子邮件、语音或短信）使用 Azure Monitor作组 ，并触发自动作。 收到失败通知时，触发 Azure 自动化 Runbook、Azure 事件中心、Azure 函数、逻辑应用或 Webhook 以执行自动修复作。

Example

有关某些模式的示例用例，请参阅 适用于 .NET 的可靠 Web 应用模式。 按照以下步骤 部署引用实现。

相关链接

• 可靠性模式
• 处理暂时性故障
• 开发后台作业
• 云设计模式
• 自我修复设计

可靠性清单

请参阅完整的建议集。