负载均衡器Load Balancers

描述

负载均衡器的工作是公平地将所有客户端的请求分配到可用服务器池中。负载均衡器执行此工作以避免服务器过载或崩溃。它还可以减轻负载并绕过失败的服务器。

负载均衡层是防火墙之后数据中心内的第一个接触点。如果一个服务每秒只处理几百甚至几千个请求，可能不需要负载均衡器。但是，对于增加的客户请求，负载均衡器提供以下功能：

可伸缩性：通过添加服务器，应用程序/服务的容量可以无缝增加。负载均衡器使这种升级或降级对最终用户透明。
可用性：即使一些服务器宕机或出现故障，系统仍然保持可用。负载均衡器的工作之一是隐藏服务器的故障和故障。
性能：负载均衡器可以将请求转发到负载较小的服务器，使用户可以获得更快的响应时间。这不仅提高了性能，还提高了资源利用率。

这是负载均衡器工作原理的抽象描述：

放置负载均衡器

通常，负载均衡器位于客户端和服务器之间。请求通过负载均衡层传递到服务器，然后再返回到客户端。然而，负载均衡器并不仅仅在这一点上被使用。

让我们考虑三个众所周知的服务器组。即 Web 服务器、应用服务器和数据库服务器。为了在这三种服务的服务器实例之间分配流量负载，可以使用负载均衡器的方式：

将负载均衡器放置在应用程序的最终用户和 Web 服务器/应用程序网关之间。
将 LBs 放置在运行业务/应用逻辑的 Web 服务器和应用服务器之间。
将负载均衡器放置在应用服务器和数据库服务器之间。

实际上，负载均衡器可以在系统设计中的任何两个具有多个实例的服务之间潜在地使用。

负载均衡器提供的服务

LBs 不仅使服务具有可伸缩性、可用性和高性能，还提供以下一些关键服务：

健康检查：LB 使用心跳协议来监视终端服务器的健康状况，从而提高其可靠性。健康检查的另一个优点是改善用户体验。
TLS 终止：负载均衡通过处理与客户端的 TLS 终止，减轻终端服务器的负担。
预测分析：负载均衡器可以通过对通过它们的流量进行分析或使用随时间获得的流量统计来预测流量模式。
减少人为干预：由于 LB 自动化，处理故障时需要的系统管理工作量减少。
服务发现：LB 的一个优势是通过查询服务注册表将客户端的请求转发到适当的托管服务器。
安全性：LB 也可以通过在 OSI 模型的不同层（层 3、4 和 7）上缓解拒绝服务（DoS）等攻击来提高安全性。

总的来说，负载均衡器为系统的整体设计提供了灵活性、可靠性、冗余性和效率。

负载均衡器分类

全局负载均衡器Global server load balancing-GSLB

GSLB 确保全球到达的流量智能地转发到数据中心。例如，数据中心的电力或网络故障需要将所有流量重新路由到另一个数据中心。GSLB 基于用户的地理位置、不同位置的托管服务器数量、数据中心的健康状况等进行转发决策。

下面的插图显示，GSLB 可以将请求转发到三个不同的数据中心。每个数据中心内的本地负载均衡层将与 GSLB 保持控制平面连接，向 GSLB 提供有关 LB 和服务器群的健康状况的信息。GSLB 使用这些信息来驱动流量决策，并根据每个区域的配置和监控信息转发流量负载。

本地负载均衡器

本地负载均衡器位于数据中心内。它们的行为类似于反向代理，并尽最大努力将传入请求分配给可用服务器池中。传入客户端的请求无缝连接到使用虚拟 IP 地址（VIP）的负载均衡器。

负载均衡在DNS中的应用

DNS 使用一种简单的技术，对每个 DNS 查询的 IP 地址列表进行重新排序。因此，不同的用户会得到一个重新排序的 IP 地址列表。这导致用户访问不同的服务器来处理他们的请求。这样，DNS 将请求的负载分布在不同的数据中心上。这就是执行 GSLB。特别是，DNS 使用轮询来执行负载平衡，如下所示：

如上所示，DNS 中的轮询将客户端严格按照循环顺序转发到数据中心。然而，轮询有以下限制：

不同的 ISP 有不同数量的用户。为许多客户提供服务的 ISP 将向其客户提供相同的缓存 IP，导致终端服务器上的负载分布不均匀。
由于循环负载均衡算法不考虑任何终端服务器崩溃，它会继续分发已崩溃服务器的 IP 地址，直到缓存条目的 TTL 到期。在这种情况下，由于 DNS 级别的负载均衡，服务的可用性可能会受到影响。

尽管有其局限性，轮询仍然被许多 DNS 服务提供商广泛使用。此外，DNS 使用短 TTL 来对缓存条目进行有效的负载均衡，以在不同数据中心之间实现负载均衡。

注意：DNS 并不是唯一的 GSLB 形式。应用交付控制器（ADCs）和基于云的负载均衡（稍后讨论）是更好的 GSLB 执行方式。

负载均衡算法

常用算法

负载均衡器根据算法分发客户端请求。以下是一些知名算法：

循环调度Round-robin：在这种算法中，每个请求以重复顺序方式转发到池中的服务器。
加权轮询Weighted Round-robin：如果一些服务器具有更高的服务客户请求能力，则最好使用加权轮询算法。在加权轮询算法中，每个节点被分配一个权重。负载均衡器根据节点的权重转发客户请求。权重越高，分配数量越多。
最少连接Least connection：在某些情况下，即使所有服务器具有相同的客户服务能力，某些服务器上的负载不均匀仍然是可能的。例如，一些客户可能有一个需要更长时间来服务的请求。或者一些客户可能在同一连接上有后续请求。在这种情况下，我们可以使用像最少连接这样的算法，其中新到达的请求被分配给具有较少现有连接的服务器。负载均衡器在这种情况下保持现有连接的数量和映射的状态
最小响应时间Least reponse time：在对性能敏感的服务中，需要使用最小响应时间等算法。该算法确保请求具有最小响应时间的服务器为客户端提供服务。
IP 哈希IP Hash：一些应用程序根据用户的 IP 地址提供不同级别的服务。在这种情况下，对 IP 地址进行哈希处理以将用户的请求分配给服务器。
URL 哈希URL Hash：应用程序中的某些服务可能仅由特定服务器提供。在这种情况下，从 URL 请求服务的客户端被分配到某个集群或一组服务器。在这些情况下使用 URL 哈希算法。

还有其他算法，比如随机或加权最少连接算法。

静态与动态算法

算法可以根据机器的状态分为静态或动态。

静态算法不考虑服务器状态的变化。因此，任务分配是基于对服务器配置的现有认知进行的。这些算法自然不复杂，并且它们在单个路由器或商品机器中实现，所有请求都到达该机器。

动态算法是考虑服务器当前或最近状态的算法。动态算法通过与服务器通信来维护状态，这会增加通信开销。状态维护使算法设计变得更加复杂。

态算法需要不同的负载均衡服务器彼此通信以交换信息。因此，动态算法可以是模块化的，因为没有单一实体会做决策。尽管这给动态算法增加了复杂性，但却导致了改进的转发决策。最后，动态算法监视服务器的健康状况，并仅将请求转发到活动服务器。

有、无状态负载均衡器

静态和动态算法需要考虑托管服务器的健康状况，维护一个状态以保存不同客户端与托管服务器的会话信息。

如果会话信息没有保存在较低层（分布式缓存或数据库）中，负载均衡器将用于保存会话信息。下面，我们描述了通过负载均衡器处理会话维护的两种方式：

Stateful有状态
Stateless无状态

有状态负载均衡器

有状态负载均衡涉及维护客户端和托管服务器之间建立的会话状态。有状态负载均衡在其算法中包含状态信息以执行负载均衡。

基本上，有状态的负载均衡器保留一个数据结构，将传入的客户端映射到托管服务器。有状态的负载均衡器增加了复杂性并限制了可扩展性，因为所有客户端的会话信息都在所有负载均衡器之间维护。也就是说，负载均衡器会相互共享它们的状态信息以做出转发决策。

无状态负载均衡器

无状态负载均衡不维护状态，因此更快速和轻量级。无状态负载均衡使用一致性哈希来做转发决策。然而，如果基础设施发生变化（例如，新的应用服务器加入），无状态负载均衡可能不像有状态负载均衡那样具有弹性，因为仅仅使用一致性哈希并不足以将请求路由到正确的应用服务器。因此，除了一致性哈希外，可能仍然需要本地状态。

因此，跨不同负载均衡器维护的状态被视为有状态负载平衡。而在负载均衡器内部维护的状态被认为是无状态负载平衡。

负载均衡的方式

负载均衡可以在开放系统互联（OSI）层的网络/传输和应用层进行。

第 4 层负载均衡器：第 4 层指的是基于传输协议（如 TCP 和 UDP）进行的负载均衡。这些类型的负载均衡器与客户端保持连接/会话，并确保相同的（TCP/UDP）通信最终被转发到同一后端服务器。尽管 TLS 终止是在第 7 层负载均衡器上执行的，但一些第 4 层负载均衡器也支持它。
第 7 层负载均衡器：第 7 层负载均衡器基于应用层协议的数据。可以根据 HTTP 头、URL、Cookie 和其他应用程序特定数据（例如用户 ID）做出应用感知的转发决策。除了执行 TLS 终止外，这些负载均衡器还可以承担诸如限制用户速率、HTTP 路由和头部重写等责任。

注意：第 7 层负载均衡器在检查方面很全面。但是第 4 层负载均衡器在处理方面更快。

负载均衡部署

在实践中，单层 LB 对于大型数据中心来说是不够的。事实上，多层负载均衡器协调进行明智的转发决策。如下所示，传统数据中心可能有一个三层 LB：

0、1层负载均衡

如果将 DNS 视为零层负载均衡器，那么等成本多路径（equal cost multipath，ECMP）路由器就是一层负载均衡器。从 ECMP 的名称可以看出，这一层根据 IP 或其他算法（如轮询或加权轮询）来划分传入流量。一层负载均衡器将在不同路径上平衡负载，以传递给更高层的负载均衡器。

ECMP 路由器在高层负载均衡器的水平可伸缩性中发挥着至关重要的作用。

2层负载均衡

第二层的负载均衡器包括第 4 层负载均衡器。第二层负载均衡器确保对于任何连接，所有传入数据包都会被转发到相同的第三层负载均衡器。为了实现这个目标，可以利用一种技术，比如一致性哈希。但是在基础设施发生任何变化的情况下，一致性哈希可能不足够。

3层负载均衡

第 7 层负载均衡器在第 3 层提供服务。由于这些负载均衡器直接与后端服务器接触，它们在 HTTP 级别执行服务器的健康监控。这一层通过将请求均匀分配给一组健康的后端服务器来实现可伸缩性，并通过直接监控服务器的健康状况提供高可用性。这一层还通过处理 TCP 拥塞控制协议、发现路径 MTU（最大传输单元）、客户端和后端服务器之间的应用协议差异等低级细节，减轻了终端服务器的负担。其思想是将计算和数据服务留给应用服务器，并有效利用负载均衡的通用机器处理琐碎任务。在某些情况下，第 7 层负载均衡器与服务主机处于同一级别。

总结一下，层 1 在负载均衡器之间平衡负载。层 2 在发生故障时实现从层 1 到层 3 的平稳过渡，而层 3 在后端服务器之间进行实际的负载均衡。每个层执行其他任务以减轻终端服务器的负担。

负责均衡的实现

根据传入请求的数量、组织和特定应用程序要求，可以实现不同类型的负载均衡器。

硬件负载均衡器

负载均衡器在 1990 年代作为硬件设备被引入。硬件负载均衡器作为独立设备运作，价格相当昂贵。尽管如此，它们具有性能优势，能够处理大量并发用户。基于硬件的解决方案的配置存在问题，因为需要额外的人力资源。因此，即使是负担得起的大型企业也不会选择它们作为首选解决方案。硬件负载均衡器的可用性可能会成为问题，因为在发生故障时需要额外的硬件进行故障切换。最后，硬件负载均衡器可能具有更高的维护/运营成本和兼容性问题，使其不够灵活。更不用说硬件负载均衡器也存在供应商锁定的问题。

可以了解一下：F5。

软件负载均衡器

软件负载均衡器因其灵活性、可编程性和成本效益而日益受到欢迎。这一切都是可能的，因为它们是在通用硬件上实现的。随着需求增长，软件负载均衡器的扩展能力很好。使用软件负载均衡器不会出现可用性问题，因为在通用硬件上实现影子负载均衡器需要很少的额外成本。此外，软件负载均衡器可以提供预测分析，有助于为未来的流量模式做准备。

云负责均衡器

随着云计算领域的出现，服务负载均衡器（LBaaS）被引入。这是云所有者提供负载均衡服务的地方。用户根据其使用情况或与云提供商的服务级别协议（SLA）付费。基于云的负载均衡器不一定会取代本地的本地负载均衡设施，但它们可以在不同区域之间执行全局流量管理。这种负载均衡器的主要优势包括易用性、管理、按量计费、使用灵活性、审计以及监控服务，以改善业务决策。下面给出了云负载均衡器如何提供全球负载均衡（GSLB）的示例：

注意：负载均衡器的另一个有趣的实现形式是客户端负载均衡。客户端负载均衡适用于存在众多服务且每个服务有多个实例的情况（例如 Twitter 中的负载均衡）。然而，我们的重点在于传统负载均衡器，因为大多数三层应用程序在设计中使用这些负载均衡器。

系统设计之负载均衡