是否可以使用多个负载平衡器将流量重定向到我的应用程序服务器？

我是负载平衡的新手，我想知道是否可以使用多个负载平衡器将流量重定向到我的应用程序服务器。我真的不明白该怎么做。域名不应该与某个服务器的IP地址（在这种情况下，是一个负载均衡器的IP）一对一匹配吗？如果每个负载平衡服务器具有不同的IP，两个负载平衡器（或10个负载平衡器或50或100）如何接收请求？

使用轮询DNS并不是高可用性的好选择-如果一台服务器脱机，客户端仍将尝试连接到该服务器并等待超时。

还有其他方法可以实现此目的。
1）主动/被动负载平衡器
基本上，一个负载平衡器处理一个IP地址的所有流量。
如果该平衡器发生故障，则被动节点会跳入并接管IP。
请记住，负载平衡器几乎只转发流量，因此对于中小型站点，这可以解决问题。

2）主动/主动负载均衡器
在两个（或更多）负载​​均衡器上配置了相同的流量IP。
传入流量被发送到所有负载均衡器，但是算法选择哪个均衡器应该响应，所有其他均衡器都丢弃该流量。
简单地考虑一下，您有两个负载均衡器：
当请求IP以偶数结尾时，负载均衡器A回答，否则负载均衡器B回答。

当然，您的基础架构必须支持这一点，并且由于流量被发送却被丢弃而产生了开销。
更多信息，例如：http : //community.brocade.com/t5/SteelApp-Docs/Feature-Brief-Deep-dive-on-Multi-Hosted-IP-addresses-in-Stingray/ta-p/73867

通常使用虚拟IP地址（VIP）协议来实现负载均衡器的高可用性，该协议允许多个主机（即负载均衡器）以几种可能的方式之一（主动/被动，主动/主动的变化）来应答一个公共ip地址。 。

这些协议有很多，我在常规负载均衡器上最常看到的是VRRP和NLB（以及设备中很多非描述性的黑盒协议）。例如，扩展到路由器和防火墙可能还会遇到CARP，HRSP，GLSP。

与DNS负载平衡相比，此策略有很多好处，DNS负载平衡是一种更简单的策略（在另一个答案中将进行介绍）。

DNS负载平衡的负担包括：

• dns缓存机制周转缓慢
• 有限的负载平衡算法（通常只是轮询）
• 将负载平衡决策外包给客户端（通过dns记录的缓存）
• 使服务器（即负载平衡器）停止旋转时，服务队列的消耗缓慢（基于ISP和客户端处理的 dns记录TTL ）
• 负载平衡器故障时的缓慢故障转移

对HA使用虚拟IP协议，例如，可以选择实现：

• 在负载均衡器中选择负载均衡算法
• 以服务器为中心的负载平衡决策（例如促进基于服务运行状况的度量和路由）
• 卸下负载平衡器时，可以更快地排空服务队列。
• 负载平衡器故障即时故障转移

只有您知道哪种策略和协议最适合您的情况。

要求：有一个适用于云或任何类型的环境的实用解决方案，在这种环境中无法访问硬件负载平衡器，BGP协议和所有其他东西。

应用程序的收入请求编号未知，但应足够高，可以毫无负担地满足增加的负载预期。

让我们找到具有类似负载性质的应用程序，例如日志存储和搜索应用程序。我找到了一个。

他们想要什么：

1. 平衡收集器之间的负载
2. 提供容错能力，使我们可以在其中一个收集器死亡或遇到问题时继续提取数据
3. 随着日志量的增长而水平扩展

他们尝试了些什么并了解到ELB：

1. 不能按预期工作
2. 负载增加导致的延迟问题
3. 监控设施不足
4. 限制太多（开放的端口和协议号）

他们为什么选择Route53：

1. “轮循机制是非常基本的负载平衡，但是从效率的角度来看，它对我们来说效果很好”
2. “我们利用Route 53故障转移运行状况检查。”
3. “如果收集器出现问题，Route 53会自动将其从服务中删除；我们的客户不会受到任何影响。”
4. 无需预热53号公路

鉴于我们庞大的日志量，不可预测的变化以及业务的持续增长，53号公路被证明是Loggly利用我们的高性能收集器的最佳方式。它符合收集器的核心目的：以零损失的网络线速度收集数据，它使我们可以从Loggly使用的所有AWS服务的弹性中受益。

该特定示例表明，在某些情况下（日志收集器，广告服务或类似服务），负载平衡器是多余的，并且“ DNS运行状况检查循环解决方案”可以很好地发挥作用。

让我们看看AWS 所说的 DNS故障转移：

借助DNS故障转移，Route 53可以检测到您的网站中断，并将最终用户重定向到您指定的备用或备份位置。Route 53 DNS故障转移依赖于运行状况检查-定期从世界各地向您的应用程序终结点发出Internet请求-确定应用程序的每个终结点是打开还是关闭。

该技术还使ELB（不是必需的，仅作说明）更加健壮，再次基于RR +运行状况检查：

Route 53 DNS故障转移通过与后台ELB集成来处理所有这些失败情况。启用后，Route 53将自动配置和管理单个ELB节点的运行状况检查。

现在让我们看看它在后台如何工作。显而易见的问题是如何处理DNS缓存：

但是，如果客户端和Route 53之间的所有层均未遵守TTL，则DNS缓存在这里仍然可能是个问题（请参阅我们以前的文章中的“长尾巴”问题）。您可以应用“缓存清除”技术：发送请求到唯一域

("http://<unique-id>.<your-domain>") 

并定义一个通配符资源

Record "*.<your-domain>" to match it.

Algolia 引入了 “客户端重试策略”，如果您的客户端（在您的情况下为JS）可以处理此问题，则该方法效果很好：

我们最终在API客户端中实施了基本的重试策略。每个API客户端都被开发为能够访问三台不同的计算机。三个不同的DNS记录代表每个用户：USERIDID-1.algolia.io，USERID-2.algolia.io和USERID-3.algolia.io。我们的第一个实现是随机选择其中一个记录，然后在失败的情况下重试另一个记录。