当使用微服务并且微服务 A 想要与微服务 B 对话时，存在某种负载平衡，因为我们可以拥有 B 的多个实例。它可以是基础设施 LB（kubernetes）或客户端 LB（eureka + 功能区）。当一切都部署在单个区域和 AZ 中时，这非常简单。
当我们想要实现多区域 HA 并使用最近的区域来实现低延迟时会发生什么？
用户请求应该由云提供商路由到关闭区域吗？A 应该只在同一个 AZ 中调用 B 吗？是否应该将所有 AZ 完全隔离并在它们之间切换用户？如果 AZ X 中的所有服务 B 都死了，整个 AZ X 应该被杀死还是应该将来自 AZ X 中的服务 A 的流量定向到 AZ Y？在第二种情况下，云提供商是否提供此类功能？
或者也许 A 应该看到所有 AZ 中的所有 B 并且它应该调用它们中的任何一个？在这种情况下，当请求发送到远处的 B 时，延迟会怎样呢？
处理这种情况的模式是什么？
区域内的高可用性
没错，Region 可以有多个可用区 (AZ)，如果您使用云提供商 (AWS/Azure)，他们会在不同的可用区预配实例。
您必须记住，AZ 之间的流量不是在公共互联网上传输的，而是云提供商有自己的专用网络。云提供商 (AWS/Azure) 通常为在 AZ 之间传输的请求提供 <2 毫秒的延迟，考虑到我们具有高可用性，这非常好。如果您部署 kubernetes 集群，则节点分布在不同的 AZ 中。如果任何 AZ 或节点出现故障，则流量将移动到不同的 AZ，从而使其具有高可用性。
跨区域高可用性
跨区域管理可用性可能是一项挑战。通常，您会在不同区域复制相同的计算基础设施（另一个 Kubernetes 集群），并使用云提供商 DNS 将用户登陆最近的区域。对于无状态应用程序来说更容易。然而，当涉及到成本和数据库时，事情就变得棘手了。
数据库是非常重要的考虑因素。如果您使用的是 RDBMS（强一致性），那么您可以在所有区域中只有一个主节点，但在不同区域中有多个只读副本。因此，无论发生在哪个区域，写入操作都只能到达特定的写入节点，并且可能涉及延迟。
如果您使用 NoSQL 来实现最终一致性，那么您必须在强一致性上做出妥协。虽然一些云提供商跨区域强一致性但你不得不介意延迟。
成本是另一个因素。如果它是活动-活动区域，则跨区域拥有重复的基础架构将使您的成本增加一倍。您可以在区域关闭时启动服务的主动-被动模式，或者在流量被转移时保持最低限度和规模的主动引导模式。
跨地区拥有冗余基础设施实际上取决于您的业务应用程序和主要需求。