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

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

3a：服务 AWS 

在设计多区域架构时，必须了解将要使用的特定AWS服务。第一个方面是了解该服务必须具备哪些功能才能启用多区域，以及是否必须设计解决方案以实现多区域目标。例如，在 Amazon Aurora 和 Amazon DynamoDB 中，有一项功能可以将数据异步复制到备用区域。任何AWS服务依赖关系都需要在运行工作负载的所有区域中都可用。为确保要使用的服务在所需区域可用，请查看AWS 区域所有服务列表。 

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

对于工作负载存在的任何内部依赖关系，请确保该工作负载将在其外运行的区域中可用。例如，如果工作负载由许多微服务组成，则应了解构成业务能力的所有微服务。然后，确保所有这些微服务都部署在工作负载将要运行的每个区域。

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

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

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

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

3c：故障转移机制

域名系统 (DNS) 通常用作故障转移机制，用于将流量从主区域转移到备用区域。严格审查和仔细检查故障转移机制所需要的所有依赖关系。例如，如果您的工作负载使用的是 Amazon Route 53，则了解控制平面托管在 US-East-1 意味着您依赖该特定区域的控制平面。如果主区域也是 US-east-1，则不建议将其作为故障转移机制的一部分。如果使用另一种故障转移机制，则需要深入了解其无法按预期运行的任何情况。一旦达成了这种谅解，就要做好应急计划或在需要时制定新的机制。查看使用 Amazon Route 53 创建灾难恢复机制，了解可用于成功进行故障转移的方法。

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

3d：配置依赖关系

证书、密钥、密钥和参数是设计多区域时所需的依赖关系分析的一部分。只要有可能，最好在每个区域内对这些组件进行本地化，这样它们就不会因为这些依赖关系而在区域之间共享命运。对于证书，证书的到期时间应各不相同，如果可能，也应在每个区域中有所不同，以避免即将到期的证书（警报设置为提前通知）影响多个区域的情况。

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

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

关键指导

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

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

• 需要在业务能力上协调故障转移，以消除延迟增加和跨区域呼叫依赖性的可能性。