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

# 控制面板和数据面板
<a name="control-planes-and-data-planes"></a>

 在了解撤离可用区时所使用的具体模式前，我们需要了解一下控制面板和数据面板的概念。在我们的服务中，AWS 对控制面板和数据面板做出了明确区分。控制面板是对系统进行更改（添加资源、删除资源、修改资源）以及将这些更改传播到任何所需位置（例如更新 ALB 的网络配置或创建 AWS Lambda 函数）所涉及的机器。

 数据面板是这些资源的主要功能，例如运行 EC2 实例，或者在 Amazon DynamoDB 表中存取项目。有关控制面板和数据面板的更多信息，请参阅[使用可用区的静态稳定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)和 [AWS 故障隔离边界](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html#control-planes-and-data-planes)。

 就本文档而言，控制面板的活动部件和依赖关系比数据面板要多。从统计学上讲，控制面板比数据面板受损的可能性更大。这对于提供 AZI 的服务（例如 Amazon EC2 和 EBS）尤为重要，因为其中部分服务的控制面板还不受区域限制，会在单可用区事件中受到损坏。

 虽然控制面板操作可用于执行可用区撤离，但根据上述信息，这些操作的成功率可能较低，尤其是在发生故障事件期间。为了提高缓解影响的成功率，可以使用两种不同的模式。第一种模式仅依靠数据面板操作，通过阻止将工作路由到受影响的可用区或停止在受影响的可用区中执行工作来缓解影响。而在第二种模式中，我们会通过控制面板操作更新资源配置，从而防止在受影响的可用区中配置容量，并停止受影响的可用区与其他可用区之间的通信。

 本部分要讨论的恢复模式是*紧急应对措施*。这种模式的机制就是快速采取大规模措施，类似于[消防站响起警铃](https://en.wikipedia.org/wiki/Andon_(manufacturing))。采用该模式，即表示已经对工作负载的代码尝试了[采用指数回退和抖动的重试](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)等策略，以克服暂时性错误。这意味着，当检测到隔离的可用区的影响时，其对可用性或延迟的影响非常严重，需要撤离该可用区才能有效缓解影响。