目前，我在欧洲部署了一个应用程序实例。它通过Web服务（SOAP）公开了一些功能。有许多客户（数千人）在全球范围内使用它（主要是北美，欧洲和亚洲）。在当前设置中，一些客户端必须对部署在不同大陆上的应用程序进行WS调用，这会显着增加响应时间。关于呼叫字符 - 有效负载很小但是经常进行呼叫。
现在我的想法是简单地部署应用程序的更多实例，以便每个地理区域都有一个。但是，存在如何在不同实例上加载平衡/加载分配请求的问题。
方法＃1。
我在开始时想到一些HTTP级别的负载平衡 - 让一个主机暴露相同的WS方法，并将它们委托给不同的应用程序实例。但我认为在这个解决方案中，我不会在传输时间方面获得任何东西 - 整个请求必须转到一个中心位置，然后到达目的地。因此，数据包路由甚至比单个实例更长。
方法＃2。
然后我考虑了DNS级别的负载平衡。无论如何都必须完成DNS查找，如果返回的IP可以指向关闭地理位置的实例，那就是它！但是这个解决方案似乎更复杂，因为我必须部署一个新的DNS系统（或者只是配置我公司使用的那个，如果它支持这样的东西）。此外，谷歌上的快速搜索主要显示基于商业DNS的负载均衡器。
我想要一些帮助回答的问题是：
1）我是否错过了上述两种方法中的任何一种方法？
2）对于这个问题有什么更好的方法，那可能是什么？
答案 0 :(得分：1)
让我们分开两个概念：
1）负载均衡
顾名思义，这会在多个服务器之间分配负载。虽然这通常不会影响传输时间，但如果服务器位于不同的地理区域，则会发生这种情况。但不是以一种好的方式 - 比如你将服务器1放在区域A中，服务器2放在区域B中，然后在两者之间进行负载平衡，任何一个区域的客户端偶尔会最终到达最远的区域。例如。循环负载平衡将所有呼叫的一半分配给区域A，另一半分配给区域B，独立于客户端区域。
您的两种方法都是有效的负载平衡方案 - 无论您是在DNS级别执行此操作还是Web服务器都无关紧要。
2）地理位置
在您的方法＃2中提示的这种方法中，服务器尽可能靠近客户端放置。在这种情况下，您需要的是某种形式的路由。换句话说，您的DNS需要确定哪个客户端位于哪个区域，并返回相应的服务器地址，或者您的Web服务器需要告诉客户端与其他服务器通信。
根据你的情景，我认为你想要2）。有几种方法可以实现这一目标：
a）使用地理DNS提供商（搜索地理dns），DNS服务器重新路由到最近的服务器
b）如果Geo-DNS不是一个选项，您可以让客户端检查每个第一次请求或至少定期（例如每天一次，每小时一次）回到您的主Web服务器。然后，让Web服务器找出客户端的区域并要求它重定向到最近的服务器。
c）使用“地理感知”前端反向代理，例如nginx，如example
中所述