本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 容错能力和故障隔离
<a name="fault-tolerance-and-fault-isolation"></a>

 这是与可用性有关的两个重要概念。容错能力是[承受子系统故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html)并保持可用性（满足已有 SLA 的要求）的能力。为了实现容错能力，工作负载会使用备用（或冗余）子系统。当冗余中的一个子系统出现故障时，另一个子系统通常会以几乎无缝的方式接手其工作。在这种情况下，备件是真正的备用容量，可以承担故障子系统的 100% 的工作。使用真正的备件时，需要多个子系统故障才能对工作负载产生不利影响。

 故障隔离可以尽可能缩小故障发生时的影响范围。这一结果通常通过模块化来实现。工作负载被分解为多个小型子系统，这些子系统的故障互不影响，可以单独修复。一个模块的故障[不会传播到模块之外。](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html)这种效果既可以在一个工作负载中的不同功能之间纵向实现，也可以在提供相同功能的多个子系统之间横向实现。这些模块充当故障容器，可以限制事件的影响范围。

 控制平面、数据平面和静态稳定性架构模式可以直接支持容错能力和故障隔离的实现。Amazon Builders Library 文章[使用可用区的静态稳定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)针对这几个术语给出了准确的定义，并介绍了它们如何应用于具有韧性和高可用性的工作负载的构建过程。本白皮书在[设计高可用性分布式系统AWS一节中使用了这些模式，](designing-highly-available-distributed-systems-on-aws.md#designing-highly-available-distributed-systems-on-aws.title)并在这里总结了它们的定义。
+  **控制平面** — 工作负载中涉及做出更改的部分：添加资源、删除资源、修改资源以及将这些更改传播到所需位置。与数据平面相比，控制平面通常更加复杂并具有更多活动部件，因此从统计学上讲，控制平面失效的可能性更大，可用性也更低。
+  **数据平面** — 工作负载中提供日常业务功能的部分。与控制平面相比，数据平面往往更加简单，运行容量也更高，因此可用性更高。
+  **静态稳定性** — 工作负载在依赖项受损的情况下继续正常运行的能力。一种实现方式是从数据平面中移除控制平面依赖项。另一种方式是松散地耦合工作负载依赖项。工作负载可能看不到其依赖项本应提供的任何更新信息（例如新内容、删除的内容或修改过的内容）。但是，它在依赖项受损之前所做的一切仍然在发挥作用。

 当工作负载受损时，我们可以考虑两种恢复方式。第一种是在损伤发生后对其做出反应，比如用 AWS Auto Scaling 来增加新的容量。第二种是在损伤发生之前做好准备，比如超额配置工作负载的基础架构，让它不需要额外资源就可以继续正常运行。

 静态稳定的系统采用后一种方式。它预先配置了备用容量，以便在故障期间保持可用性。采用这种方式，我们就不需要在工作负载恢复路径中在控制平面上创建依赖项以便配置新容量，从而从故障中恢复。此外，为各种资源配置新容量需要耗费时间。在等待新容量时，工作负载可能会因现有需求而超负荷并进一步降级，从而降低或完全失去可用性。但是，您还应该对照可用性目标，考虑使用预配置容量所产生的成本影响。

 静态稳定性针对高可用性工作负载提出了以下两项规则。

**规则 7**  
 不要在数据平面中的控制平面上设置依赖项，尤其是在恢复期间。

**规则 8**  
 尽可能松散地耦合依赖项，让工作负载在依赖项受损时也能正常运行。