多区域基础知识 3：了解您的工作负载依赖关系

特定工作负载在一个区域中可能有多个依赖关系，例如已 AWS 服务 使用的依赖关系、内部依赖关系、第三方依赖关系、网络依赖关系、证书、密钥、密钥和参数。为了确保工作负载在故障情况下运行，主区域和备用区域之间不应存在任何依赖关系；每个区域都应能够独立运行。为此，请仔细检查工作负载中的所有依赖关系，以确保它们在每个区域中都可用。这是必需的，因为主区域的故障不会影响备用区域。此外，您必须了解当依赖关系处于降级状态或完全不可用时工作负载是如何运行的，这样您才能设计出适当的解决方案来处理这个问题。

3.a: AWS 服务

在设计多区域架构时，重要的是要了解将要使用的架构、这些服务的多区域功能，以及需要设计哪些解决方案才能实现多区域目标。 AWS 服务 例如，Amazon Aurora 和 Amazon DynamoDB 可以将数据异步复制到备用区域。所有 AWS 服务 依赖关系都需要在运行工作负载的所有区域中都可用。要确认您使用的服务在所需区域中可用，请查看AWS 服务 按区域列出的列表。

3.b: 内部依赖关系和第三方依赖关系

确保每个工作负载的内部依赖关系在其运行区域中都可用。例如，如果工作负载由许多微服务组成，请识别构成业务功能的所有微服务，并验证所有这些微服务是否部署在工作负载运行的每个区域。或者，定义一种策略来优雅地处理不可用的微服务。

不建议在工作负载内的微服务之间进行跨区域调用，并且应保持区域隔离。这是因为创建跨区域依赖关系会增加相关故障的风险，这抵消了工作负载的孤立区域实施的好处。本地依赖关系也可能是工作负载的一部分，因此重要的是要了解如果主区域发生变化，这些集成的特征会如何变化。例如，如果备用区域距离本地环境更远，则延迟增加可能会产生负面影响。

了解软件即服务 (SaaS) 解决方案、软件开发套件 (SDKs) 和其他第三方产品依赖关系，并能够演练这些依赖关系降级或不可用的场景，可以更深入地了解系统链在不同故障模式下的运行和行为。这些依赖关系可能存在于您的应用程序代码中，例如使用在外部管理机密 AWS Secrets Manager，也可能涉及第三方保管库解决方案（例如 HashiCorp），或者依赖于AWS IAM Identity Center联合登录的身份验证系统。

在依赖关系方面拥有冗余可以提高弹性。如果 SaaS 解决方案或第三方依赖项使用与工作负载相同的主 AWS 区域 服务器，请与供应商合作，确定他们的弹性状况是否符合您对工作负载的要求。

此外，请注意工作负载及其依赖关系（例如第三方应用程序）之间的共同命运。如果故障转移后在辅助区域（或来自辅助区域）的依赖关系不可用，则工作负载可能无法完全恢复。

3.c: 故障转移机制

DNS 通常用作故障转移机制，用于将流量从主区域转移到备用区域。严格审查和仔细检查故障转移机制所需要的所有依赖关系。例如，如果您的工作负载使用 Amazon Route 53，则了解控制平面托管在中us-east-1意味着您依赖该特定区域的控制平面。如果主区域也是us-east-1因为会造成单点故障，则不建议将其作为故障转移机制的一部分。如果您使用其他故障转移机制，则应深入了解故障转移无法按预期运行的情况，然后根据需要做好应急计划或开发新的机制。查看博客文章使用 Amazon Route 53 创建灾难恢复机制，了解可用于成功进行故障转移的方法。

如上一节所述，作为业务能力一部分的所有微服务都需要在部署工作负载的每个区域中可用。作为故障转移策略的一部分，作为业务功能一部分的所有微服务都应一起进行故障转移，以消除跨区域调用的机会。或者，如果微服务独立进行故障转移，则可能会出现不良行为，例如微服务可能会进行跨区域调用。这会带来延迟，并可能导致工作负载在客户端超时期间变得不可用。

3.d: 配置依赖关系

证书、密钥、机密、Amazon 系统映像 (AMIs)、容器映像和参数是设计多区域架构时所需的依赖关系分析的一部分。只要有可能，最好在每个区域内对这些组件进行本地化，这样它们就不会因为这些依赖关系而在区域之间共享命运。例如，您应该更改证书的到期日期，以防止即将到期的证书（警报设置为 “提前通知”）影响多个区域。

加密密钥和机密也应特定于区域。这样，如果密钥或密钥的轮换出现错误，则影响仅限于特定区域。

最后，所有工作负载参数都应存储在本地，以便在特定区域中检索工作负载。

关键指导

• 多区域架构受益于区域间的物理和逻辑分离。在应用层引入跨区域依赖关系会破坏这一好处。避免此类依赖。

• 故障转移控制应在不依赖于主区域的情况下运行。

• 应在用户旅程中协调故障转移，以消除延迟增加和跨区域呼叫依赖性的可能性。