Networking 基于邻近性的负载平衡

我正在做一个项目，我们在全世界拥有5台服务器。 客户端通过集中式代理连接到其中一个服务器。 我们只知道客户的原产国，其他什么都不知道。我们完全控制服务器，因此我们可以获得这些服务器上所需的所有信息。 我们不控制客户，他们必须按照标准通过该代理进行连接

代理选择一个低延迟的服务器是很重要的，因此对于我们拥有的数据，我认为接近性是我们唯一可用的标准

首先想到的是从每个服务器ping客户端，但我们没有ip，只有国家

我们的另一个想法是从每个服务器ping每个国家的根节点。这里的问题是在每个国家/地区找到一个根节点

你知道如何计算/查找“国家”之间的接近度吗？

---

你对如何用另一种方式解决这个问题有什么见解或想法吗？

我认为你需要的术语是“地理负载平衡”。大多数主要的负载平衡供应商都有一个解决方案，您的代理可以使用这些解决方案

---

谷歌搜索得到了一些有用的结果。

这很棘手，比许多人想象的要复杂得多，但我觉得有一个正确的答案

当然，天真（但很酷）的解决方案是检查客户端的IP，这是一个良好的开端，但在“现实世界”中，地理定位并不是一切

---

您刚刚要求了“低延迟”，这意味着您应该在服务器和客户端之间执行ping，并相应地分配。一个很好的例子是，我在日本工作，对我来说，台湾的服务器比美国的服务器更接近但是，日本和美国之间的延迟比台湾少很多倍（更好的响应），因为连接日本-台湾的电缆和路由器以及您拥有的东西不如日本-美国之间的电缆和路由器。所以，如果你把我和台湾联系起来，因为你认为我的IP更近，你会对我造成很大的不满。除了ping和启动时实际的小测试比保持一些不断更新的地理位置数据库更容易之外，Paul有它，你想要地理负载平衡——但我要补充的是，如果这是一个选项，你最好的选择是找到专门从事此项工作的人并向他们扔钱。这类问题比第一次出现时更难可靠地解决

ping它们并选择延迟最低的一个听起来不错，但我感觉它不会扩展（当你有100个或1000个时会发生什么？），所以也许另一个解决方案更好？有很多厂商的系统就是这样做的；DNS选播也得到了相当广泛的应用

如果只是ping它们，则需要对每个ping进行多次ping（理想情况下是并行），以确保选择的是真正低延迟的ping，而不是运气好的ping

此外，当流量非常大时，您可能需要某种方法来最终增加权重

---

最后，您可能希望通过某种方式将其中一些设备标记为管理故障（用于维护），但也许您可以通过让损坏的设备不公布当前不可用的设备来实现这一点。

ping将不起作用。大多数客户端都位于网关和/或防火墙后面，您的ping数据包无法通过。Genehack说得最好。您需要服务器负载平衡，而仅使用地理方法可能不是实现负载平衡的最佳方法。最好向专门提供SLB解决方案的人扔钱

好的，我想快速想一想。我是地理知识产权智能的创始人。几年前我离开了这家公司，但大约6年前我们用它实现了这一功能——基于地理位置的负载平衡。当然，有些边缘案例（本帖中提到的台湾/中国示例）可能无法自动工作，但该产品允许用户确定一个国家的流量将流向何处。因此，如果你认为台湾最好是从美国那里得到服务，那么它就会被推到美国之外

不幸的是，对解决方案的需求并没有我们希望的那么大，我相信该产品已经停产。我会提出建议，看看他们是否能为您提供同等的解决方案。如果没有，我想他们会对如何做你想做的事情有一些想法

另一种选择是使用类似亚马逊CloudFront的服务，这取决于您需要提供什么服务。当然，如果你需要客户端连接到一个应用程序而不是静态文件，这对你来说是行不通的

---

顺便说一句，-我不仅是Digital Emission的创始人，而且目前在Coyote Point董事会任职。

解决这一问题的最佳方案是BGP anycast（）。它是所有现代CDN的基石

有了BGP anycast，多个不同的服务器分布在世界各地，并通过使用相同IP的BGP向互联网发布。然后互联网发挥了神奇的作用——与往常一样，网络通过最短路径将流量路由到同一IP，本质上是为每个用户选择最近的服务器（从网络拓扑的角度）

不幸的是，你不能自己通过BGP发布任何消息——只有大型网络（通常是数据中心）才能做到这一点。但价格合理的解决方案是可用的，其中大多数基于DNSanycast（即根据客户端位置解析不同的web服务器IP）-这并不完美，但在许多情况下已经足够了（例如：dnsmadeeasy、Route 53、edgedirector，以及几乎所有便宜的CDN-cloudflare、maxcdn、cloudfront等）。还有一些解决方案可以实现真正的BGP选播，即通过选播（如cachefly）实际提供HTTP流量服务，或允许您这样做（如hostvirtual-不便宜）。也可能是b