网络负载均衡

定义

网络负载均衡是在网络结构中引入一个承担流量调度的中间环节，把原本指向单一服务地址的请求依次或按规则交给多台后端节点处理。对使用者而言，对外呈现的往往是一个虚拟的服务地址，后端节点的数量与具体身份并不需要被感知。这一技术的直接效果是扩展服务能力、降低单台设备的压力。

负载均衡的另一个作用与故障相关。调度环节会持续探测后端节点的运行状态，一旦某个节点被判定为不可用，新的请求便不再被送往该节点，而转由其余节点承接，从而使服务的可用性不依赖任何一台具体机器^[1]。因此它在功能上兼有分流与容错两重含义^[2]。

按照覆盖范围，负载均衡通常被划分为单机房或多服务器集群内部的本地负载均衡，以及跨多个数据中心的全局负载均衡，后者多以域名系统的解析结果作为调度手段，并被称为全局服务器负载均衡(GSLB)^[3]。

原理

负载均衡的调度分为两个动作：先选定节点，再改写或引导流量的去向。选定节点的过程由调度算法完成。较早的算法是轮询与加权轮询，前者把请求按顺序依次分给各节点，后者按权重比例分配，使性能更强的节点获得更多请求^[4]。随机与加权随机则借助随机函数选取节点，调用量增大后其效果趋近于轮询^[4]。

动态类算法依据节点的实时状况决策。最少连接数算法记录每个节点当前的活跃连接数量，把新请求交给连接数最少者；加权最少连接数在此基础上乘以权重，用「当前连接数除以权重」衡量负载并取最小值^[5]。企业级设备还提供链路质量算法，把时延、路由跳数和丢包率折算为链路质量分数，质量越高获得的连接越多^[6]。

哈希类算法追求的是同一会话尽量落在同一节点。源地址散列以请求的源 IP 作为散列键，从静态表中查出对应节点，若该节点可用且未超载则转发，否则返回空^[4]。这类做法在多个节点间保持了一致性，代价是分布未必均匀。

流量改写环节的常见形式有网络地址转换与直接路由两种。以网络地址转换方式为例，负载均衡设备接收目的地址为虚拟服务 IP 的请求，选定真实服务器后改写报文目的地址，响应返回时再把源地址还原为虚拟服务 IP。直接路由方式下，服务器的响应不经过负载均衡设备，仅请求方向被改写^[7]。

按工作的协议层次，负载均衡常被划分为四层与七层。四层工作在传输层，只依据 IP 地址与端口转发，不解析报文内容，因此开销较低、可支持任意基于 TCP 或 UDP 的协议。七层工作在应用层，负载均衡器需先与客户端完成握手、收到请求报文后再依据 URL、报文头或 Cookie 等内容选择后端，因而可以按内容做更精细的分流，同时也会带来更高的处理开销。四层方式下 TCP 握手由客户端与后端服务器直接完成，七层方式下则由负载均衡器分别与两端建立连接，充当代理角色^[8]。

在多路径网络中，等价多路径与数据中心常用的哈希分流是另一种形态的负载均衡：交换机或路由器对报文的五元组等特征做哈希，把结果映射到若干条等价路径上^[9]。这种方式避免了同一数据流的报文乱序，但当流数量有限或存在少数超大流量时，哈希碰撞会使多条大流落到同一条路径上^[10]。与之相对的逐包转发理论粒度最细，却会在同一数据流内造成明显乱序，需要额外的重排机制来补偿^[9]。

发展历程

早期的流量分配依赖域名系统。把一个服务域名登记多个 IP 地址后，域名服务器在应答时轮换地址顺序，客户端便会被导向不同站点。这种做法实现成本低，但应答主机并不了解目标服务器的健康状态与负载，还受缓存生存时间约束，解析结果在缓存过期前难以改变^[2]。

20 世纪 90 年代后期，Foundry Networks、F5 Networks 等公司推出专门用于流量分发的网络设备。这类设备对外公布一个虚拟服务器地址，把客户端连接按预设算法转发给成员服务器，处理方式与地址转换类似但加入了决策逻辑^[2]。它们还能够在网络层与应用层与成员服务器交互，先确认服务确实可用，再决定是否转发；健康检查失败时，该服务器会被移出调度池^[2]。此后，会话保持、SSL 卸载与内容校验等功能陆续加入这类设备^[2]。

随着服务扩展到多个数据中心，全局服务器负载均衡在域名系统的基础上发展起来。它通常作为应用的授权域名服务器，持续监测各站点状态，把查询引导到距离较近且未过载的站点，并在站点故障时绕开该站点^[11]。同类能力在不同厂商的产品中有 3DNS、GSS 等不同名称，技术路径大体一致^[12]。

云计算普及后，负载均衡更多以服务形态交付。云平台的弹性负载均衡一般由负载均衡器、监听器和后端服务器组三部分构成，监听器按配置的协议与端口接收请求，后端服务器组则按调度策略与健康检查结果接收流量^[8]。全局调度的职能也随之从机房内部分离出来，出现了脱离具体数据中心的云化部署方式，以便统一管理分布在多个云上的应用^[11]。

近年大规模人工智能训练集群对流量均匀性提出更高要求。相关技术文献显示，此类场景的主流做法仍是基于数据流的等价多路径，研究者提出将等价多路径出接口分组、并让路由携带出口组标识，以缓解哈希碰撞导致的分配不均^[9]。

应用

网站与在线服务是最常见的应用场景。高访问量站点把请求分发到多台服务器组成的服务器池，由调度环节决定每台机器承接多少请求，并在某台机器失效时把流量转向其余在线机器；新增机器加入后也能自动开始分担请求。

云环境中，负载均衡通常与弹性伸缩配合使用。负载均衡器随时增减后端服务器数量，若与弹性伸缩组关联，伸缩组内的实例会自动加入后端列表，移出伸缩组的实例也会自动从列表中删除^[5]。云平台还按协议区分实例类型，网络型实例面向 TCP 与 UDP，应用型实例面向 HTTP 与 HTTPS 并支持基于路径和域名的转发^[13]。

在数据中心内部，负载均衡以多路径转发和链路调度的形式出现。交换机在若干条等价链路上按流做哈希分流，链路拥塞时还可以根据各路径的可用带宽与利用率调整权重，把部分流量迁移到备用路径，并在条件恢复后回切^[14]。广域网出口同样可以采用链路负载均衡，依据剩余带宽或链路质量在多个运营商链路之间分配新建连接^[6]。

跨地域服务依靠全局负载均衡实现就近接入与容灾。部署在多个地域的应用通过域名解析把用户导向较近或负载较轻的站点，从而降低访问时延，并在某个站点整体不可用时把流量转移到其他站点^[15]。

局限

负载均衡解决的是请求如何分散的问题，并不能消除后端的性能瓶颈。若所有后端节点都因慢查询、线程池耗尽或下游接口变慢而处理缓慢，调度只能把慢请求分得更均匀，系统整体并不会因此变快。

会话保持与其负载效果之间存在矛盾。为使同一用户的连续请求落在同一台服务器上，调度环节可以采用源地址保持或插入 Cookie 的方式，但这意味着持有大量会话的节点无法把负载让出去，负载不再均衡；该节点一旦失效，这些用户会被迫中断而非平滑迁移，扩容带来的新容量也只对新会话有效^[16]。云服务文档同样指出，开启会话保持可能造成后端访问量不均^[5]。

负载均衡本身不负责后端节点之间的数据同步。若后端服务保存了状态，需要由独立的数据服务或同步机制保证各节点数据一致，否则请求被分到不同节点时会出现状态不一致^[1]。

健康检查也可能带来副作用。若检查逻辑过深且所有节点依赖同一套共享资源，该资源变慢时全部节点会在同一时刻被判定为不健康并同时被移出调度池，服务由性能下降转为完全中断^[16]。检查间隔与失败阈值的乘积决定了故障发现所需的时间，阈值设置需要与恢复速度相权衡^[16]。

基于域名系统的调度方式还有其固有短板。域名记录本身不具备故障探测能力，请求可能被解析到已经失效的地址；解析结果受缓存生存时间影响，调整不能立即生效，各运营商的缓存策略不同还会造成生效时间不一致^[15]。此外，基于哈希的分流是对流空间而非实际流量做均分，某条大流所在的部分流量较重时，均分流空间并不能保证流量本身被均分^[17]。

参见

• 等价多路径 —— 在若干条等价链路上分发流量的路由技术，与负载均衡同属流量分配范畴。

• 域名系统 —— 全局服务器负载均衡常借助其解析结果实现跨站点调度。

• 内容分发网络 —— 通过分布式节点就近提供内容，常与全局负载均衡配合使用。

• 反向代理 —— 七层负载均衡的常见实现形式，按报文内容选择后端。

• 健康检查 —— 判定后端节点是否可用、决定其是否留在调度池中的机制。