这个问题已经萦绕在我脑海大约两年了，我从未真正放慢脚步，花时间去问，主要是因为到目前为止我一直在使用云服务，而不必管理自己的服务器。
公司经常提到线性/水平扩展，当事情变得有点困难时，他们只需向服务器应用程序投入更多机器来提高吞吐量。请求将由提供给客户端并响应的众多机器之一处理。在大多数情况下，我读到的是，请求/连接和相关数据被转发到应该根据所用算法处理特定连接/请求的设备。
理论上听起来不错，但难道没有单点故障/限制? 如果有一个应用程序将所有这些请求（这里指的是 REST 请求）路由到应该处理它的机器，那么是否还有一台机器在接收和处理每个请求？如果有一台机器处理每个请求并将其交给其他机器进行处理，那么无论您有 5 台机器还是 20 台机器都无关紧要。这似乎是一种糟糕的实现，因为它在增加吞吐量方面没有任何作用，但它是我读到最多的。
我一直设想这样做的方式是，有一台服务器负责决定哪台机器应该处理您的请求，您将在启动时向该机器发起 GET 请求。此请求将使用有关您应该与之通信的服务器的信息进行解析。每隔 5 分钟左右，您将向服务器发送另一个 GET 请求，以查看是否应该更改服务器，并且始终在出现任何网络错误时发送 GET 请求以获取新服务器。这将确保您永远不会尝试与离线服务器通信，并且发送到“切换服务器”（我想称之为）的唯一请求是询问我们应该与哪个服务器通信的请求。此切换服务器应通过保持活动的 TCP 连接连接到每个单独的服务器，并确保服务器正在运行。如果服务器离线，将为客户端推荐新服务器。这样，即使机器出现故障，最终用户也不会注意到它。
我在这个问题上读到的信息和我认为它的工作方式之间存在两个核心区别，那就是“切换服务器”的请求处理量，而我的实现只需要最少量的请求，而我经常读到的请求切换服务器处理每一个请求。
答案1
多台服务器如何增加网络请求的吞吐量？
嗯，从根本上讲，这是资源可用量的计算。给定服务中使用的每个节点的 CPU 时间、RAM 和网络带宽都是有限的。
因此，多台服务器通过提供更多资源来执行相同任务来提高吞吐量。如何分配任务是一个单独的问题 - 但基本原则是，更多服务器拥有更多资源来完成给定的工作，因此当我们需要完成更多给定的工作时，我们会分配所需的资源。
水平扩展通常与以前的做法形成对比，以前我们可以轻松地用 n+1 台机器解决问题 - 也就是说，如果你当前的硬件无法跟上，你就必须订购一整套新硬件。这往往导致需要指定一台机器来处理平均负载和峰值负载之间的负载，而这又往往会导致一些未使用的容量。
不过，我怀疑答案的这部分并不是你真正想要问的。
理论上这一切听起来不错，但难道不存在单点故障/限制吗？
最终，是的，总是有一些单点故障，但上下文中的答案是，这是一种设计选择。
您描述的基本上是后端服务器池前面的某种负载均衡器或反向代理。在这种情况下，是的，如果您只有一台机器执行此操作，那么它就是单点故障。
“显而易见”的反对意见是：使用更多这样的前端机器来避免单点故障。具体如何运作取决于：
- 您可以使用 DNS（您也可以使用它在后端之间进行循环，而无需前端参与）。一个简单的例子是指向几个不同 A 记录的 CNAME 或 SRV。
- 您可以使用 HA 设置，可能基于虚拟 IP（任播可能值得归入此“类别”） - 例如，https://www.digitalocean.com/community/tutorials/how-to-set-up-highly-available-web-servers-with-keepalived-and-floating-ips-on-ubuntu-14-04。
您还可以结合这两种技术，并添加各种工具和方法来尝试避免 SPOF 实际上首先发生故障，但一般来说，单点故障就会名副其实，因此最佳实践是首先避免在您的设计中构建这样的故障点。
或者，给出一个更简短的答案：您可以像扩展运行应用程序的服务器一样扩展前端/请求路由器/负载平衡器。如果您担心可用性，我认为，说您通常至少从一对组件开始，以避免在应用程序中构建单点故障，这并不过于笼统。
答案2
它被称为负载均衡器，通常它是一个具有 HA 的集群，如果负载均衡器集群发生故障，则您可以在另一个站点获得冗余，通常使用另一组负载均衡器。
这就是为什么没有单点故障的原因，因为负载平衡器“相互检查”，同时也通过“监控探测”检查节点是否能够提供请求的服务，所以它们知道节点是否关闭。因为使用专用设备“将数据包切换”到可用节点要容易得多，所以这会增加输出。由于负载平衡器也可以在 HA 中交替使用，因此这允许更大的吞吐量而没有单点故障。