总的来说我想在分布式应用程序中理解 - 负载均衡器单点故障？
我不确定，但这可能是一个Apache负载均衡器，或者是F5 Network之类的设备/硬件负载均衡器等。
我已经看到（在论文/幻灯片上）设计可以为同一个应用程序提供多个apache负载均衡器。
我与我的同事讨论过 - 将多个IP地址/虚拟机/ unix盒（具有负载均衡器硬件设备）映射到同一DNS域（如www.amazon.com） - 但是那时谁会照顾什么基础/算法请求将转到哪个特定的IP / unix框（映射到amazon.com/DNS）
我的问题：在请求流程的开始（在第一个入口点） - 只有一台机器（根据某种算法向负载均衡器发送请求），如果这台机器发生故障，则系统被分配（具有多个负载均衡器和集群等都将下降
答案 0 :(得分：1)
对不起，如果我把它全部吹掉了。
考虑到单点故障（SPOF）的定义，如果您的LB失败，您的应用程序将无法使用，所以简而言之，是单个LB或反向代理是SPOF。
为什么会这样？，假设您只有一个LB并且它能够轻松处理您可能拥有的所有流量，您还需要确保您可以避免任何硬件故障或任何其他类型的故障。你的设备关闭（极端情况数据中心崩溃）。
如何处理这个问题？
我在这里只是提到，在应用程序服务器前面添加图层并不一定能解决所有问题，而是添加“网络跃点”，因此每次都会产生一些小的时间开销。请求。此外，有时还会使故障排除更加困难，增加成本以及复杂基础架构带来的所有其他不良后果。 这就是为什么 我需要一个很好的理由让不同的LB排成一行 。
到目前为止，我将遵循的架构（类似于您在论文中看到的那样）是在您的基础架构前面的两个LB（仅当它们难以处理您的流量时才超过两个）和DNS它们之间的负载平衡。
当然，这个解决方案有缺点，DNS对后端的状态不可知，因此您没有故障转移功能。
您可以通过与DNS合作使用强大的监控系统来解决这个问题，从而实现对DNS的自动更改，从而实现故障转移功能。 再次，您必须接受DNS绑定到生存时间（TTL），并且一些客户端将在失败时缓存“错误”的IP。
当你意识到上述情况并不完美但可能（大多数时候）是你唯一的方法。
对于停机时间容忍度更低的情况（即使对于客户端子集），我会留下几个替代方案。
全局服务器负载均衡器（GSLB），它是一项服务，您将购买它。它可以随心所欲地将流量路由到您希望的位置，或者采用主动 - 被动架构，例如主要灾难或主动 - 主动，例如美国的一个数据中心和亚洲的另一个数据中心。当然这个解决方案（除了费用很多）听起来很容易实现，但要记住你必须考虑的所有事情才能使这个工作正常我不会深入到技术我只会提到那个您将需要双硬件，必须将其配置为在您的数据中心之间独立工作，但需要完全同步。
边界网关协议（BGP），您必须使用isps实现此功能。这里的实现可能非常复杂，必须进行自定义才能根据您的需求进行优化。再次在这里，你有双重基础设施的所有头痛。但是如果你已经找到了这个解决方案，那么很可能你会在不止一个地方开始运作。
在上述所有内容中，云端托管的单个强大LB对于大多数网络应用/网站来说已经足够了。