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