解释负载均衡器

前言

最初这是对#explainlikeimfive -像五岁小孩一样解释负载均衡器的评论，但我决定将其转换为一篇简短的解释文章。

负载均衡器的核心在于扩展性。

一般来说，缩放分为两种类型：

• 垂直式扩展——你不断地向单个系统添加资源，直到空间耗尽为止——例如，直到没有空闲的内存插槽来扩展内存，或者没有空闲的SATA/SAS端口来连接另一块硬盘。这类似于把资源堆积在一个封闭的地方——最终会堆积到屋顶vertically。
• 横向扩展——不断添加更多的小型独立系统，每个系统都拥有自己的资源份额，这些资源加起来就能提供你所需的性能和效率。只要有足够的物理空间（以及足够的电力来保证可靠运行），你就可以这样做，这对于未来的扩展来说非常高效。想象一下一个大架子，当资源耗尽时，你就把新的服务器放在上一个服务器旁边——它不断扩展horizontally。

负载均衡器在水平扩展时发挥作用。

部署在负载均衡器后面的各个系统称为节点。

通常会在这些节点前部署负载均衡器来处理管理工作。负载均衡器决定如何将负载分配到所有节点，并支持各个节点，尽可能地将任务从这些节点上卸载下来。

负载均衡器的特点

我们可以总结为：

• 在可用节点之间均衡负载——这显而易见。
• 维护所有节点的健康状况信息，以防止将请求路由到失效节点。这通过实施定期健康检查来实现——通常是向专门设计的 API 发送 HTTP 探测请求，该 API 会返回应用程序的内部状态。例如，这提供了一种绝佳的维护方式——您可以将节点标记为非活动状态（在进行维护和/或重启期间），而 Web 应用程序仍然可以通过从其他活动节点处理请求来正常运行。同样，您也可以逐步替换所有节点，逐个替换为更强大的节点，而无需任何停机时间！
• 持续记录每个节点的负载信息（CPU负载、内存使用情况、活动连接数、每秒每个节点的连接数），以防止已高负载的节点进一步过载。
• 它会跟踪会话（基于源 IP 地址 + 端口或 HTTP cookie），以便始终将同一客户端路由到同一节点（如果其他节点不具备会话感知能力，则此操作是必要的——想象一下，您登录到一个应用程序，该应用程序会为您的身份验证会话生成 cookie。然后，您的下一个请求将被重定向到另一个节点（负载均衡器会选择负载较低的节点），该节点由于没有 cookie 而不知道您已经通过身份验证——最终您将被重定向回登录屏幕，甚至可能陷入循环。
• 卸载——负载均衡器可以负责压缩资源并将其发送给最终客户端，从而为节点上的应用程序代码释放更多 CPU 资源。同样，它还可以终止和协商 HTTPS 会话，由于每个客户端都需要进行 SSL/TLS 加密，因此 HTTPS 会话的开销也很大。此外，负载均衡器还可以将常用资源缓存到内存或高速存储设备中，避免频繁地从节点检索资源，从而减轻节点的内存和高速 SSD 的负担。

负载均衡器的其他用途

• 根据路由（URL 的各个部分）拆分负载 - 您可以决定为/rest/api上下文分配 4 个节点，为应用程序代码分配 2 个节点/[css|js|img]，其余节点用于应用程序代码。

太长不看

负载均衡器可以使您的服务更可靠、更易于扩展、性能更高，并且能够更好地应对故障。