想象一下，我在一个自动扩展的云环境中有一个 n 层架构，如下所示：
- 故障转移对中的负载均衡器
- 反向代理层
- Web 应用层
- 数据库层
每个层级都需要连接到下面层级的实例。
连接各层以使其能够应对各层节点故障的标准方法是什么？即，每一层如何获取下一层中每个节点的 IP 地址？
例如，如果所有反向代理都应将流量路由到所有 Web 应用程序节点，那么如何设置它们，以便它们不会将流量发送到死亡的 Web 应用程序节点，并且当新的 Web 应用程序节点上线时，它们可以向其发送流量？
- 我可以运行一个代理来更新所有节点的所有配置，但这似乎效率低下。
- 我可以在每一层之间放置一对 LB，这样上面的层只需要连接到负载均衡器，但是我该如何处理 LB 死亡的问题呢？这似乎只是将 A 层需要知道 B 层中所有节点的 IP 的问题转移到 A 层中的所有节点需要知道 A 层和 B 层之间所有 LB 的 IP 的问题。
对于某些应用程序，如果它们联系下面层中没有响应的节点，它们可以实现重试逻辑，但是是否有一些中间件可以将流量引导到下一层中仅活动节点？
如果我在 AWS 上托管，我可以在层之间使用 ELB，但我想知道如何自己实现相同的功能。
我（简要地）阅读了有关 heartbeat 和 keepalived 的内容 - 这些与此相关吗？他们谈论的虚拟 IP 是什么以及如何管理它们？使用它们是否仍存在单点故障？
答案1
像 haproxy 这样的应用程序负载均衡器就是这样做的。例如，如果它检测到来自 Web 服务器的 5xx 错误，它可以将该服务器标记为失败。此外，如果服务器未能通过三次握手，它可以将其标记为失败，并在客户端继续等待时尝试另一台服务器。
使用 keepalived 和 heartbeat，您可以拥有一对 haproxy 服务器。如果一个服务器出现故障，另一个服务器将接管。
我在这里使用 haproxy 作为示例，但几乎任何应用程序负载均衡器（又名第 4/7 层负载均衡器）都具有这些特征。
答案2
你的问题是How do I deal with failures?
答案是Redundancy，或者更具体地说
- 创建一组可以完成您需要完成的工作的节点。
- 确保它们具有通向核心的独立电源和网络路径。
- 如果您需要容忍集合中单个节点的故障，请按照您的描述将该集合放在负载均衡器后面。
- 如果您需要容忍负载均衡器的故障，请给它提供一个合作伙伴。
- 关于单独的电源和网络路径的相同警告。
- 如果您需要容忍多个节点的故障，则选择
N+S冗余
（多个备用节点随时准备介入并接管）。
您可以使用 Amazon ELB（如果您使用的是 EC2）、防火墙pf（或pfsense）使用循环虚拟 IP，或者使用各种软件负载平衡工具，例如haproxy（这可能是最好的选择，因为它们具有一些不错的故障检测功能，但它们确实需要额外的硬件）。
还有专门的商业负载平衡器解决方案，例如思科的内容交换机或内容交换模块如果你有现金。
不要忘记在测试环境中模拟故障，以确保事情按照您预期的方式失败。
答案3
LB 应该监视代理层并自动删除消失的主机（即将流量重定向到幸存的节点）。
反向代理应再次使用监控 Web 应用程序的 LB。Web 应用程序应能够接管来自其他节点的会话。
Web 应用程序应该通过 LB 连接到数据库服务器。