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

# ARC 中的可用区转移最佳实践
<a name="route53-arc-best-practices.zonal-shifts"></a>

建议采用以下最佳实践在 ARC 中使用可用区转移进行多可用区恢复。

**主题**
+ [容量规划和预扩展](#ZSBestPracticeCapacityPrescaling)
+ [限制客户端与您的端点保持连接的时间](#arc-zonal-shift.existing-connections)
+ [提前测试开始区域偏移](#ZSBestPracticeTestShifting)
+ [确保所有可用区域都运行良好并占用流量](#ZSBestPracticeEnsureHealthyAZs)
+ [使用数据平面 API 操作进行灾难恢复](#ZSBestPracticeUseDataPlane)
+ [只能暂时通过区域偏移来移动交通](#ZSBestPracticeMoveTrafficTemp)

**容量规划和预扩展**  
确保您已计划好并且已经预扩展或可以自动扩展足够的容量，以适应可用区转移启动时给可用区施加的额外负载。对于面向恢复的架构，典型的建议是预扩展计算容量，保留足够的余量，以便在三个副本（典型情况下）之一离线时承担流量高峰。  
在为受支持资源启动可用区转移且流量从某个可用区转出后，您的应用程序用于处理请求的容量就会被移除。您必须确保已计划将流量从可用区转移出去，并且可以继续处理其余可用区的请求 AZs。

**限制客户端与您的端点保持连接的时间**  
当 Amazon 应用程序恢复控制器（ARC）将流量从受影响的可用区中转移出去时（例如使用可用区转移或可用区自动转移），ARC 用来转移应用程序流量的机制是 DNS 更新。DNS 更新会导致所有新连接都避开受影响的位置。  
但是，先前已打开连接的客户端可能会继续向受影响的位置发出请求，直到客户端重新连接。为确保快速恢复，建议您限制客户端与您的端点保持连接的时间。

**提前测试开始区域偏移**  
通过启动可用区转移，定期测试从可用区移走应用程序的流量。最好是同时在测试和生产环境中计划和执行可用区转移，并将该过程纳入到定期的失效转移测试中，以测试发生灾难时恢复应用程序的能力。要确保您已准备好并有信心在运营事件发生时缓解问题，定期测试是一个关键环节。

**确保所有可用区域都运行良好并占用流量**  
可用区转移的工作原理是，将某可用区中的一个资源（即应用程序副本）标记为运行状况不佳。这意味着，必须要确保应用程序中的资源总体运行状况良好，并且在区域的可用区中主动接受流量。我们建议您使用仪表板来跟踪该情况，包括针对不正常目标的 Elastic Load Balancing 指标和每个可用区的 bytesProcessed 等。  
建议从另一个相邻的区域监控资源的运行状况。这种方法的优势在于，它可以更好地代表最终用户的体验，还可以降低应用程序和监控同时受到同一灾难影响的风险。

**使用数据平面 API 操作进行灾难恢复**  
要在需要快速恢复几乎没有依赖关系的应用程序时开始区域移动，我们建议使用 AWS Command Line Interface 或 API，并尽可能使用带有预存储凭据的区域移位操作和预先存储的凭据。为了便于使用 AWS 管理控制台，您也可以在中开始区域移动。但是，当快速、可靠的恢复至关重要时，数据面板操作是更好的选择。有关更多信息，请参阅[可用区转移 API 参考指南](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/Welcome.html)。

**只能暂时通过区域偏移来移动交通**  
可用区转移会暂时将流量从可用区移走，以减轻损失。在采取措施纠正问题后，应立即将应用程序资源恢复为可用。这样能确保整个应用程序恢复到原始的完全冗余的弹性状态。