如何扩展这样的系统？

Question

目前，我在欧洲部署了一个应用程序实例。它通过 Web 服务 (SOAP) 公开一些功能。全世界（主要是北美、欧洲和亚洲）有许多客户（几千个）在使用它。在当前设置中，一些客户端必须对部署在不同大陆上的应用程序进行 WS 调用，这会显着增加响应时间。关于调用字符 - 有效负载很小，但调用很频繁。

现在我的想法是简单地部署应用程序的更多实例，以便在每个地理区域中都有一个。但随之而来的问题是如何在不同的实例上进行负载均衡/负载分配请求。

方法 #1。

一开始我在考虑一些 HTTP 级别的负载平衡 - 让一个主机公开相同的 WS 方法并将它们委托给不同的应用程序实例。但我认为在这个解决方案中，我不会在传输时间方面获得任何收益——整个请求必须先到达一个中心位置，然后再到达目的地。所以数据包路由会比单个实例更长。

方法 #2。

然后我想到了 DNS 级别的负载平衡。无论如何都必须完成 DNS 查找，如果返回的 IP 可以指向关闭的地理定位实例，那就是它！但是这个解决方案似乎要复杂得多，因为我必须部署一个新的 DNS 系统（或者如果它支持这样的东西，就配置我公司使用的那个）。此外，在 google 上的快速搜索显示主要是基于商业 DNS 的负载均衡器。

我希望得到帮助回答的问题是：

1) 我在上述两种方法中是否遗漏了什么？

2) 有没有更好的方法来解决这个问题？具体是什么？

Answer 1

让我们分开两个概念：

1) 负载均衡

顾名思义，这会在多个服务器之间分配负载。虽然这通常不会影响传输时间，但如果服务器位于不同的地理区域，则会影响传输时间。但不是很好 - 假设您将服务器 1 放置在区域 A 中，将服务器 2 放置在区域 B 中，然后在两者之间进行负载平衡，任一区域的客户端偶尔会往返于最远的区域。例如。循环负载平衡将所有调用的一半分配到区域 A，另一半分配到区域 B，独立于客户端的区域。

您的两种方法都是有效的负载平衡方案——无论您是在 DNS 级别还是在 Web 服务器级别执行此操作都没有那么重要。

2) 地理位置

在这种方法中，正如您在方法 2 中所暗示的那样，服务器放置在尽可能靠近其客户端的位置。在这种情况下，您需要某种形式的路由。换句话说，您的 DNS 需要确定哪个客户端位于哪个区域，并返回相应的服务器地址，或者您的 Web 服务器需要告诉客户端与不同的服务器通信。

根据您的情况，我认为您想要 2)。有几种方法可以实现这一点：

a) 使用 Geo-DNS 提供商（搜索 geo dns），由此 DNS 服务器重新路由到最近的服务器

b) 如果 Geo-DNS 不是一个选项，您可以让客户端在每次首次请求时或至少定期（例如，每天一次、每小时一次）检查回您的主 Web 服务器。然后，让 Web 服务器找出客户端所在的区域，并要求它重定向到最近的服务器。

c) 使用“地理感知”前端反向代理，如 nginx，如example 中所述