你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
自我修复和自我保护的建议
适用于此 Azure 架构良好的框架可靠性清单建议：
| RE：07 | 通过实施自我维持和自我修复措施，增强工作负载的复原能力和可恢复性。 使用基于基础结构的可靠性模式和基于软件的设计模式来处理组件故障和暂时性错误，将功能构建到解决方案中。 将功能构建到系统中，以检测解决方案组件故障，并在工作负荷继续完全或减少功能时自动启动纠正措施。 |
|---|
本指南介绍了在应用程序体系结构中生成自我修复和自我保存功能以优化可靠性的建议。
自我保护功能可增强工作负荷的复原能力。 它们降低了完全中断的可能性，并允许工作负荷在发生故障的组件恢复时以降级状态运行。 自我修复功能通过构建故障检测和自动纠正措施来应对不同的故障类型，从而帮助你避免停机。
本指南介绍专注于自我保存和自我修复的设计模式。 将它们合并到工作负荷中，以增强其复原能力和可恢复性。 如果未实现模式，则当出现不可避免的问题时，你的应用面临失败的风险。
定义
| 术语 | 定义 |
|---|---|
| 自我修复 | 工作负荷通过恢复受影响的组件以及根据需要故障转移到冗余基础结构来自动解决问题的能力。 |
| 自我保护 | 工作负荷能够应对潜在问题。 |
关键设计策略
自我保存设计
若要设计工作负荷以自我保存，请遵循基础结构和应用程序体系结构设计模式来优化工作负荷的复原能力。 若要最大程度地减少遇到完整应用程序中断的可能性，请通过消除单一故障点并最大程度地减少故障的爆破半径来提高解决方案的复原能力。 本文中的设计方法提供了多种选项，用于增强工作负荷的复原能力，并满足工作负荷定义的 可靠性目标。
基础结构设计指南和模式
在基础结构级别，冗余体系结构设计应支持关键流，同时跨可用性区域或区域部署资源。 尽可能实现 自动缩放 。 自动缩放有助于保护工作负荷免受活动意外的突发，进一步强化基础结构。
使用部署标记模式或大容量头模式，在出现问题时最大程度地减少爆炸半径。 如果单个组件不可用，这些模式有助于保持工作负荷可用。 将以下应用程序设计模式与自动缩放策略结合使用。
部署戳模式：预配、管理和监视各种资源组，以托管和操作多个工作负荷或租户。 每个副本被称为缩放单元，有时也被称为服务单元或单元。
大容量模式：根据使用者负载和可用性要求，将服务实例分区到不同的组（称为 池）。 此设计有助于隔离故障，并允许某些使用者维持服务功能，即使在故障期间也是如此。
应用程序设计指南和模式
避免在应用程序设计中构建整体式应用程序。 使用通过明确定义的标准相互通信的松散耦合服务或微服务，以减少单个组件发生故障时出现广泛问题的风险。 例如，可以标准化使用服务总线来处理所有异步通信。 标准化通信协议可确保应用程序设计一致和简化，这使得工作负载在发生故障时更易于故障排除。 在实际情况下，首选组件之间的异步通信而不是同步通信，以最大程度地减少超时问题，例如死信。 以下设计模式可帮助你组织工作负荷，并定义组件之间的通信，以最符合业务需求的方式。
大使模式：将业务逻辑与网络代码和复原逻辑分开。 创建代表客户服务或应用程序发送网络请求的帮助程序服务。 可以使用此模式实现重试机制或断路器。
异步请求-回复模式：如果后端处理需要异步，则从前端主机分离后端处理，但前端需要明确的响应。
缓存端模式：按需将数据从数据存储加载到缓存中。 此模式可以提高性能，并帮助保持缓存中保存的数据与基础数据存储中的数据之间的一致性。
断路器模式：使用断路器主动确定是否允许操作继续操作，还是根据最近的故障数返回异常。
声明检查模式：将大型消息拆分为声明检查和有效负载。 将声明检查发送到消息传送平台，并将有效负载存储在外部服务中。 此模式允许处理大型消息，同时保护消息总线，并防止客户端不知所措或减慢。
竞争使用者模式：允许多个并发使用者处理在同一消息通道上接收的消息。 系统可以同时处理多个消息，从而优化吞吐量、提高可伸缩性和可用性，并平衡工作负荷。
配置请求超时：为对服务或数据库的调用配置请求超时。 数据库连接超时通常设置为 30 秒。
守护程序模式：通过使用专用主机实例在客户端和服务之间代理请求来保护应用程序和服务。 中转站验证和清理请求，并提供额外的安全层来限制系统的攻击面。
基于队列的负载调配模式：使用解决方案中的队列将任务与解决方案中的服务分离，以便每个任务都可以异步运行。 使用队列作为任务与它调用的服务之间的缓冲区，以帮助平滑间歇性负载，导致服务失败或任务超时。此模式有助于最大程度地减少需求高峰对任务和服务的可用性和响应能力的影响。
限制模式：控制应用程序实例、单个租户或整个服务使用的资源消耗。 这种模式允许系统继续正常运行并满足服务级别协议（SLA），即使需求增加会给资源增加一个极端负载。
暂时性故障处理模式和重试模式：实现处理暂时性故障的策略，以在工作负荷中提供复原能力。 暂时性故障在云环境中正常且预期出现。 暂时性故障的典型原因包括暂时性网络连接丢失、已删除的数据库连接或服务繁忙时的超时。 有关开发重试策略的详细信息，请参阅 本系列中的暂时性故障处理指南 。
后台作业
后台作业是通过将任务与用户界面（UI）分离来增强系统可靠性的有效方法。 如果任务不需要用户输入或反馈，并且不会影响 UI 响应能力，则将其实现为后台作业。
后台作业的常见示例包括：
- CPU 密集型作业，例如执行复杂计算或分析结构模型。
- I/O 密集型作业，例如运行多个存储操作或为大型文件编制索引。
- 批处理作业，例如定期更新数据或在特定时间处理任务。
- 长时间运行的工作流，例如完成订单或预配服务和系统。
有关详细信息，请参阅 后台作业的建议。
自我修复设计
若要为自我修复设计工作负荷，请实现故障检测，以便触发自动响应并正常恢复关键流。 启用日志记录以提供有关失败的性质和恢复成功的操作见解。 为关键流实现自我修复所要采用的方法取决于 为该流和流组件和依赖项定义的可靠性目标 。
基础结构设计指南
在基础结构级别，关键流应受 冗余体系结构设计 的支持，并为支持它的组件启用自动故障转移。 可以为以下类型的服务启用自动故障转移：
计算资源：Azure 虚拟机规模集和大多数平台即服务（PaaS）计算服务都可以配置为自动故障转移。
数据库：可以使用 Azure SQL 故障转移群集、AlwaysOn 可用性组或 PaaS 服务的内置功能等解决方案为关系数据库配置自动故障转移。 NoSQL 数据库具有类似的群集功能和 PaaS 服务的内置功能。
存储：通过自动故障转移使用 冗余存储选项 。
应用程序设计指南和模式
阻止错误的执行组件：如果限制客户端，这并不意味着客户端正在恶意行为。 这可能意味着客户端超出了其服务配额。 但是，如果客户端一直超出其配额或者行为不佳，你可能会阻止它们。 定义客户端请求取消阻止的带外进程。
断路器模式：如果重试机制启动后失败仍然存在，则存在因调用积压而引发的级联失败的风险。 用于处理重试机制的断路器通过阻止应用反复尝试运行可能失败的操作来限制级联失败的风险。
补偿事务模式：如果使用由一系列步骤组成的最终一致性操作，请实现补偿事务模式。 如果一个或多个步骤失败，可以使用此模式撤消执行步骤的工作。
正常降级：有时无法解决问题，但可以提供减少的功能。 假设某个应用程序显示图书目录。 如果该应用程序无法检索封面的缩略图图像，它可能显示占位符图像。 整个子系统可能对应用程序不重要。 例如，对于电子商务网站，显示产品建议可能小于处理订单的关键。 正常降级还可以包括自动故障转移操作。 当数据库由于主实例出现问题而自动故障转移到副本时，性能会缩短一段时间。
领导选举模式：需要协调任务时，请使用领导选举来选择协调器，这样一个协调器就不是一个失败点。 如果协调器失败，则选择一个新的协调器。 考虑现成的解决方案（如 ZooKeeper），而不是从头开始实现领导者选举算法。
测试模式：包括测试作为标准测试过程的一部分实现的模式的测试。
对长时间运行的事务使用检查点：如果长时间运行的操作失败，检查点可以提供复原能力。 当操作重新启动时，例如，如果另一个虚拟机选取了该操作，则可以从最后一个检查点恢复。 请考虑实现一种机制，以定期记录有关任务的状态信息。 将此状态保存在持久存储中，该存储可由运行任务的进程的任何实例访问。 如果进程关闭，则可以使用另一个实例从最后一个检查点恢复它正在执行的工作。 有一些库提供此功能，例如 NServiceBus 和 MassTransit。 它们以透明方式保留状态，其中间隔与 Azure 服务总线队列中的消息处理保持一致。
自动自我修复操作
自我修复的另一种方法是使用监视解决方案在检测到预先确定的运行状况更改时触发的自动操作。 例如，如果监视检测到 Web 应用未响应请求，则可以通过 PowerShell 脚本生成自动化来重启应用服务。 根据团队的技能集和首选开发技术，使用 Webhook 或函数生成更复杂的自动化操作。 有关使用函数响应数据库限制的示例，请参阅基于事件的云自动化参考体系结构。 使用自动化操作可帮助你快速恢复，并最大程度地减少人工干预的必要性。
Azure 便利化
大多数 Azure 服务和客户端 SDK 都包括重试机制。 但它们有所不同，因为每个服务都有不同的特性和要求，因此每个重试机制都会优化到特定的服务。 有关详细信息，请参阅 有关暂时性故障处理的建议。
对通知（如电子邮件、语音或短信）使用 Azure Monitor 操作组 ，并触发自动操作。 收到失败通知时，触发Azure 自动化 Runbook、Azure 事件中心、Azure 函数、逻辑应用或 Webhook 以执行自动修复操作。
注意事项
熟悉每个模式的注意事项。 在实施之前，请确保该模式适用于工作负荷和业务要求。
- 代表模式
- 异步请求-答复模式
- 隔舱模式
- 缓存端模式
- 声明检查模式
- 补偿事务模式
- 使用者竞争模式
- 配置请求超时
- 守护程序模式
- 领导选拔模式
- 基于队列的负载调节模式
- 重试模式
- 限制模式
- 暂时性故障处理模式
示例
有关某些模式的示例用例，请参阅适用于 .NET 的可靠 Web 应用模式。 按照以下步骤 部署引用实现。
相关链接
可靠性清单
请参阅完整的建议集。