分布式应用——负载均衡器是单点故障吗？
Distributed application - is load balancer single point of failure?
总的来说，我想在分布式应用程序中了解 - 负载均衡器是单点故障吗？
我不确定，但这可以是 Apache 负载均衡器，或者在 device/harware 负载均衡器之上 F5 Network 等
我已经看到（在 papers/slides）设计可以为同一个应用程序使用多个 Apache 负载平衡器。
我和我的同事进行了讨论——将多个 IP Address/VMs/unix 框（具有负载平衡器硬件设备）映射到同一个 DNS 域（比如 www.amazon.com）——但是谁来处理什么 basis/algorithm 请求将转到哪个特定的 IP/unix 盒子（映射到亚马逊。com/DNS）
我的问题：在请求流的开始（在第一个入口点）——只有一台机器（它根据某种算法将请求发送到底层负载均衡器），如果这台机器发生故障，则分布式系统（有多个负载均衡器和集群等）将会宕机
对不起，如果我夸张了。
考虑到单点故障 (SPOF) 的定义，如果您的 LB 出现故障，您的应用程序将不可用，因此简而言之，是 单个 LB 或反向代理是单点故障。
为什么会这样？假设您只有一个 LB，并且它能够轻松处理您可能拥有的所有流量，您还需要确保您不会受到任何硬件故障或任何其他类型故障的影响可能会使您的设备宕机（极端情况数据中心崩溃）。
如何处理问题？
我只是在这里提一下，仅仅在你的应用程序服务器前面添加层并不一定能解决你所有的问题，相反你添加了 "network hops" 结果，即使是次要的，时间每个请求的开销。有时还会使故障排除变得更加困难，增加成本以及复杂基础架构带来的所有其他坏事。
这就是为什么 i 需要一个很好的理由在 line 中使用不同的 LB。
就这一点而言，我将遵循的架构（类似于您在论文中看到的那样）是在您的基础设施前面的两个 LB（仅当它们难以处理您的流量时才超过两个）以及它们之间的 DNS 负载平衡。
当然这个解决方案有缺点，DNS 不知道后端的 state 所以你没有 failover 功能.
您可以解决这个问题，方法是使用强大的监控系统与您的 DNS 合作，以实现对 DNS 的自动更改，从而实现故障转移功能。 同样，您必须接受 DNS 绑定到生存时间 (TTL) 并且某些客户端会在出现故障时缓存 "wrong" ip。
虽然您意识到上述内容并不完美，但可能（大多数时候）是您唯一的解决方法。
对于停机时间容忍度更低的情况（即使对于一部分客户），我将留下几个备选方案。
Global Server Load Balancer (GSLB)，这是一项服务，您会喜欢它。它总是按照您的意愿进行艰苦的工作，将流量路由到主动-被动架构，比如主-灾难或主动-主动，例如美国的一个数据中心和亚洲的另一个数据中心。当然，这个解决方案（除非它会花费很多）听起来很容易实施，尽管请记住你必须考虑的所有事情才能正常工作我不会深入技术我只是提一下您将需要双重硬件，这必须将其配置为在您的数据中心之间独立工作，但在需要的地方完全同步。
边界网关协议 (BGP)，您必须使用您的 isp 来实现它。此处的实现可能相当复杂，并且必须自定义才能根据您的需求进行优化。和以前一样，这里再次让您头疼双重基础设施。但是，如果您归结为这个解决方案，很可能您会在多个地方 运行。
综上所述，在云中托管一个功能强大的 LB 足以满足大多数 Web apps/sites。
2021 年我也在研究这个问题。尽管像 NGINX 这样的简单选项确实很方便，但它们似乎确实提供了单点故障。
今天的解决方案是使用 Kubernetes 或 Docker Swarm 方法，这似乎变得非常复杂，但每个节点或至少一个故障转移的主节点都内置了负载平衡。
否则，来自 Google、AWS 或 Azure 等大公司之一的基于云的负载均衡器可能会提供必要的正常运行时间。
总的来说，我想在分布式应用程序中了解 - 负载均衡器是单点故障吗？
我不确定，但这可以是 Apache 负载均衡器，或者在 device/harware 负载均衡器之上 F5 Network 等
我已经看到（在 papers/slides）设计可以为同一个应用程序使用多个 Apache 负载平衡器。
我和我的同事进行了讨论——将多个 IP Address/VMs/unix 框（具有负载平衡器硬件设备）映射到同一个 DNS 域（比如 www.amazon.com）——但是谁来处理什么 basis/algorithm 请求将转到哪个特定的 IP/unix 盒子（映射到亚马逊。com/DNS）
我的问题：在请求流的开始（在第一个入口点）——只有一台机器（它根据某种算法将请求发送到底层负载均衡器），如果这台机器发生故障，则分布式系统（有多个负载均衡器和集群等）将会宕机
对不起，如果我夸张了。
考虑到单点故障 (SPOF) 的定义，如果您的 LB 出现故障，您的应用程序将不可用，因此简而言之，是 单个 LB 或反向代理是单点故障。
为什么会这样？假设您只有一个 LB，并且它能够轻松处理您可能拥有的所有流量，您还需要确保您不会受到任何硬件故障或任何其他类型故障的影响可能会使您的设备宕机（极端情况数据中心崩溃）。
如何处理问题？
我只是在这里提一下，仅仅在你的应用程序服务器前面添加层并不一定能解决你所有的问题，相反你添加了 "network hops" 结果，即使是次要的，时间每个请求的开销。有时还会使故障排除变得更加困难，增加成本以及复杂基础架构带来的所有其他坏事。 这就是为什么 i 需要一个很好的理由在 line 中使用不同的 LB。
就这一点而言，我将遵循的架构（类似于您在论文中看到的那样）是在您的基础设施前面的两个 LB（仅当它们难以处理您的流量时才超过两个）以及它们之间的 DNS 负载平衡。
当然这个解决方案有缺点，DNS 不知道后端的 state 所以你没有 failover 功能.
您可以解决这个问题，方法是使用强大的监控系统与您的 DNS 合作，以实现对 DNS 的自动更改，从而实现故障转移功能。 同样，您必须接受 DNS 绑定到生存时间 (TTL) 并且某些客户端会在出现故障时缓存 "wrong" ip。
虽然您意识到上述内容并不完美，但可能（大多数时候）是您唯一的解决方法。
对于停机时间容忍度更低的情况（即使对于一部分客户），我将留下几个备选方案。
Global Server Load Balancer (GSLB)，这是一项服务，您会喜欢它。它总是按照您的意愿进行艰苦的工作，将流量路由到主动-被动架构，比如主-灾难或主动-主动，例如美国的一个数据中心和亚洲的另一个数据中心。当然，这个解决方案（除非它会花费很多）听起来很容易实施，尽管请记住你必须考虑的所有事情才能正常工作我不会深入技术我只是提一下您将需要双重硬件，这必须将其配置为在您的数据中心之间独立工作，但在需要的地方完全同步。
边界网关协议 (BGP)，您必须使用您的 isp 来实现它。此处的实现可能相当复杂，并且必须自定义才能根据您的需求进行优化。和以前一样，这里再次让您头疼双重基础设施。但是，如果您归结为这个解决方案，很可能您会在多个地方 运行。
综上所述，在云中托管一个功能强大的 LB 足以满足大多数 Web apps/sites。
2021 年我也在研究这个问题。尽管像 NGINX 这样的简单选项确实很方便，但它们似乎确实提供了单点故障。
今天的解决方案是使用 Kubernetes 或 Docker Swarm 方法，这似乎变得非常复杂，但每个节点或至少一个故障转移的主节点都内置了负载平衡。
否则，来自 Google、AWS 或 Azure 等大公司之一的基于云的负载均衡器可能会提供必要的正常运行时间。