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

自我修复和自我保护的建议

  • 项目

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

RE：07 通过实施自我保护和自我修复措施，增强工作负载的复原能力和可恢复性。 使用基于基础结构的可靠性模式和基于软件的设计模式处理组件故障和暂时性错误，在解决方案中构建功能。 在系统中构建功能以检测解决方案组件故障，并自动启动纠正措施，同时工作负载继续以完全或减少的功能运行。

相关指南：后台作业 | 暂时性故障

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

自我保留功能可增强工作负载的复原能力。 它们可降低完全中断的可能性，并允许工作负载在故障组件恢复时以降级状态运行。 自我修复功能通过构建故障检测和自动纠正操作来响应不同的故障类型，从而帮助你避免停机。

本指南介绍侧重于自我保存和自我修复的设计模式。 将它们合并到工作负载中，以增强其复原能力和可恢复性。 如果不实现模式，则当不可避免的问题出现时，应用将面临失败的风险。

定义

术语 定义
自我修复 工作负载能够通过恢复受影响的组件以及根据需要故障转移到冗余基础结构来自动解决问题的能力。
自我保存 工作负载能够灵活应对潜在问题。

关键设计策略

自我保留指南

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

基础结构设计指南和模式

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

使用部署缩放单元模式或隔舱模式在出现问题时最小化爆炸半径。 当单个组件不可用时，这些模式有助于使工作负载保持可用。 将以下应用程序设计模式与自动缩放策略结合使用。

  • 部署缩放单元模式：预配、管理和监视一组不同的资源，以托管和操作多个工作负荷或租户。 每个副本称为“缩放单元”，有时称为“服务单元”或简称“单元”。

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

应用程序设计指南和模式

避免在应用程序设计中生成整体式应用程序。 使用松散耦合的服务或微服务，这些服务或微服务通过明确定义的标准相互通信，以降低单个组件发生故障时出现广泛问题的风险。 例如，可以标准化服务总线的使用来处理所有异步通信。 标准化通信协议可确保应用程序设计一致和简化，从而使工作负载更加可靠，并在发生故障时更轻松地进行故障排除。 在可行时，首选组件之间的异步通信而不是同步通信，以最大程度地减少超时问题，如死信。 以下设计模式可帮助你以最符合业务需求的方式组织工作负载并定义组件之间的通信。

  • 代表模式：将业务逻辑与网络代码和复原逻辑分开。 创建代表客户服务或应用程序发送网络请求的帮助程序服务。 可以使用此模式来实现重试机制或断路。

  • 异步 Request-Reply 模式：如果后端处理需要异步，但前端需要明确的响应，则将后端处理与前端主机分离。

  • 缓存端模式：按需将数据从数据存储加载到缓存中。 此模式可以提高性能，并帮助保持缓存中保存的数据与基础数据存储中的数据之间的一致性。

  • 断路器模式：使用断路器主动确定是允许操作继续，还是根据最近的故障数返回异常。

  • 声明检查模式：将大消息拆分为声明检查和有效负载。 将声明检查发送到消息传送平台，并将有效负载存储在外部服务中。 此模式允许处理大型消息，同时保护消息总线并防止客户端不堪重负或速度变慢。

  • 使用者竞争模式：允许多个并发使用者处理在同一消息传送通道上收到的消息。 系统可以同时处理多个消息，从而优化吞吐量、提高可伸缩性和可用性，并平衡工作负载。

  • 配置请求超时：配置对服务或数据库的调用的请求超时。 数据库连接超时通常设置为 30 秒。

  • 守护程序模式：通过使用专用主机实例在客户端与应用程序或服务之间代理请求来保护应用程序和服务。 中转站验证和清理请求，并提供额外的安全层来限制系统的攻击面。

  • 基于队列的负载调配模式：通过在任务之间使用队列将任务与解决方案中的服务分离，以便每个任务都可以异步运行。 使用队列作为任务与它调用的服务之间的缓冲区，以帮助缓解可能导致服务失败或任务超时的间歇性重负载。此模式有助于最大程度地减少需求高峰对任务和服务的可用性和响应能力的影响。

  • 限制模式：控制应用程序实例、单个租户或整个服务使用的资源消耗。 此模式允许系统继续运行并满足服务级别协议 (SLA) ，即使需求增加给资源增加了极大的负载。

  • 暂时性故障处理模式和重试模式：实施策略来处理暂时性故障，以提供工作负载的复原能力。 暂时性故障在云环境中是正常和预期的。 暂时性故障的典型原因包括网络连接暂时丢失、数据库连接断开或服务繁忙时超时。 有关开发重试策略的详细信息，请参阅本系列中的 暂时性故障处理指南 。

后台作业

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

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

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

有关详细信息，请参阅 后台作业的建议。

自我修复指南

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

基础结构设计指南

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

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

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

  • 存储：使用具有自动故障转移的 冗余存储选项 。

应用程序设计指南和模式

  • 阻止恶意参与者：如果限制客户端，并不意味着客户端是恶意的。 这可能意味着客户端超出了其服务配额。 但是，如果客户端一直超过其配额或表现不佳，则可以阻止它们。 为客户端定义带外进程，以请求解除阻止。

  • 断路器模式：如果在启动重试机制后故障仍然存在，则可能会因调用积压增加而导致级联故障。 设计用于重试机制的断路器可防止应用重复尝试运行可能失败的操作，从而限制级联失败的风险。

  • 补偿事务模式：如果使用由一系列步骤组成的最终一致性操作，请实现补偿事务模式。 如果一个或多个步骤失败，可以使用此模式撤消步骤执行的工作。

  • 正常降级：有时无法解决问题，但可以提供功能缩减。 假设某个应用程序显示图书目录。 如果该应用程序无法检索封面的缩略图图像，它可能显示占位符图像。 整个子系统可能对应用程序不重要。 例如，对于电子商务网站，显示产品建议可能不如处理订单重要。 正常降级还可以包括自动故障转移操作。 当数据库由于主实例出现问题而自动故障转移到副本 (replica) 时，性能会在短时间内降低。

  • 领导者选举模式：当需要协调任务时，请使用领导选举来选择协调器，这样一个协调器就不是单一失败点。 如果协调器失败，则选择一个新的协调器。 与其从头开始实施领导者选举算法，不如考虑现成的解决方案，如 ZooKeeper。

  • 测试模式：包括对作为标准测试过程的一部分实现的模式的测试。

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

自动自我修复操作

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

Azure 简化

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

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

注意事项

熟悉每种模式的注意事项。 在实现之前，请确保该模式适合工作负载和业务需求。

示例

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

可靠性清单

请参阅完整的建议集。

可靠性清单