负载均衡相关基本概念

负载均衡在系统架构设计中至关重要，其核心目标是合理分配负载，提升系统整体性能和可靠性。本文简要介绍了负载均衡的基本概念，包括四层和七层负载均衡、负载均衡的使用场景和实现方式、负载均衡的常用算法以及一些配置相关知识。

---

1、负载均衡基本概念

负载均衡（Load Balancing）是一种将网络流量、计算任务或数据请求动态分配到多个服务器或资源的机制，旨在优化资源使用、最大化吞吐量、减少响应时间，并避免单点故障。其核心目标是通过合理分配负载，提升系统整体性能和可靠性。负载均衡可以提升性能，避免单台服务器过载，充分利用集群资源；通过健康检查机制自动剔除故障节点并将流量转发到健康的节点，保障服务的连续性，提升系统的可用性；支持横向扩容和弹性扩展，以应对业务增长的需求和流量的变化；部分负载均衡还集成了防火墙和DDOS、黑名单等安全防护功能，提升了系统了安全防御能力。

1.1 L4和L7层负载均衡

1.1.1 OSI七层网络模型和TCPIP四层网络模型

OSI七层网络模型是一种理论框架，核心是分层解耦，将网络自底向上分为物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。

TCPIP模型是实际互联网协议栈的基础，强调的是实用性和可扩展性，分为网络接口层、网络层、传输层和应用层。

1.1.2 L4和L7层负载均衡

负载均衡包括2层、3层、4层和7层负载均衡，其中L4和L7层负载均衡使用最多。
1）L7层负载均衡
七层负载均衡器位于OSI模型的最高层，即应用层，通过对网络流量进行分析和处理，将请求分发到不同的服务器上，以实现负载均衡。在实现上七层负载均衡器能够解析应用层的内容，如HTTP头、URL路径、Cookie等，根据具体的请求信息进行更加精细的负载均衡。这种负载均衡方式不仅考虑网络数据包的源IP地址、目标IP地址和端口号，还深入到数据包的负载内容，从而做出更智能化的请求分发决策。
七层负载均衡能够实现智能路由，支持按照业务逻辑来分发流量，比如灰度发布、A/B测试等；另外还可以实现实现深度健康检查，可以检测到HTTP状态码、响应内容等；同时在安全方面也有增强，支持Web应用防火墙WAF、防DDOS攻击等。不过由于七层负载均衡需要解析和分析HTTP的数据，会带来一定的CPU开销；另外在协议支持上受限，仅支持特定的协议，比如HTTP或HTTPS。

2）L4层负载均衡
四层负载均衡工作在OSI模型的传输层，在接收到客户端请求后，通过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器。在实现上负载均衡设备接收到客户端请求后根据特定的算法转发请求，同时会将客户端的源地址转换为负载均衡设备的地址（NAT地址转换），服务器接收到请求后会处理请求并返回给负载均衡，负载均衡设备将请求返回给客户端，并将服务器的源地址改为负载均衡设备的地址。
四层负载均衡仅处理IP和端口，转发效率高；同时不解析应用层内容，处理速度快；并且支持所有基于TCP/UDP的协议。缺点是无法根据HTTP URL、Cookie等信息做智能路由；另外只能检测端口是否存活，无法判断服务实际状态。

3）四层和七层负载均衡对比如下所示

在技术实现上，像F5复制均衡设备、Nginx等均可以实现七层和四层的负载均衡。

1.2 负载均衡使用场景分类

负载均衡的应用场景很多，比如高并发的流量请求、分布式架构下的系统扩展和弹性收缩、容灾和高可用下消除单点故障等。
1）高并发流量请求
在高并发的业务流量访问时候，通过负载均衡将用户请求均匀分布到多台服务器，避免单台服务器过载。比如电商平台在双十一促销期间，通过负载均衡动态扩展后端服务器集群，处理海量订单和页面访问请求。

2）系统扩展与弹性伸缩场景
在分布式架构以及微服务使用下，随着业务的增长需要动态的调整服务器数量以应对负载的变化，实现灵活的路由负载请求。通过负载均衡设备按需添加或移除设备，无缝集成弹性扩缩容策略。比如Web服务器集群通过负载均衡实现动态扩容，应对突发流量。

3）容灾和高可用场景
基于负载均衡的故障检测机制自动屏蔽故障节点，将流量重定向至健康服务器，从而避免关键业务需避免因单台服务器故障导致服务中断。另外结合智能DNS（如云解析DNSPod），将域名解析至不同地域的负载均衡实例，实现全局流量调度。某地域故障时，暂停该地域解析即可保障业务连续性。

负载均衡技术通过流量调度、资源扩展、故障容错等机制，已成为信息系统架构的关键组件。其应用场景也从传统Web服务、数据库集群到云原生、分布式数据库、微服务等领域：

• Web应用负载均衡：将用户请求分发到多个Web服务器，确保每个服务器获得相对均衡的负载，提高整体性能和响应速度；同时增加了系统的冗余度，即使某一台服务器出现故障，其他服务器也能继续提供服务。
• 数据库负载均衡：利用负载均衡技术将读请求分发到多个数据库副本或只读实例上，减轻主数据库的压力，提高查询性能。
• 应用服务负载均衡：将客户端请求分散到多台应用程序服务器上，确保系统处理能力随业务需求弹性扩展。另外随着用户数量的增长，可以轻松地增加新的服务器来应对增长的需求，实现灵活扩展。
• 云平台负载均衡：使用负载均衡实现云资源（如虚拟机、容器）间网络流量的自动分配，实现云服务的高可用性和水平扩展。通常云提供商通常会提供内置的负载均衡解决方案，如Kubernetes Service。

1.3 负载均衡的实现

负载均衡技术根据实现方式可分为软件层面和硬件层面，两者在性能、成本、灵活性和适用场景上各有特点。

1.3.1 软件负载均衡实现

软件负载均衡通常由操作系统、应用程序或云平台实现，灵活性高且成本低，有开源的软件实现，也有商用的软件。主要有以下几种：

• LVS（Linux Virtual Server）：基于Linux内核的四层负载均衡，支持NAT、DR、TUN三种模式，具备高并发（单机可支持上万连接）和低资源消耗特性。适用于大规模TCP/UDP应用（如Web服务、数据库集群）。
• Nginx：支持四层（TCP/UDP）和七层（HTTP/HTTPS）负载均衡，提供反向代理、SSL卸载、动态路由（基于URL、Header等）功能。适用于Web服务、API网关及内容分发场景。
• HAProxy：专注于七层负载均衡，支持ACL规则、会话保持、健康检查，性能接近硬件设备（如F5）。适用于微服务架构、高并发HTTP/HTTPS服务。
• 云厂商的SLB服务：比如阿里云SLB，支持四层（TCP/UDP）和七层（HTTP/HTTPS）负载均衡，支持跨可用区容灾。
• 数据库层负载均衡：部分数据库厂商在驱动层实现负载均衡，通过在JDBC中配置连接数据库的URL串，实现数据库层负载均衡

以Nginx为例，Nginx支持三种不同的负载均衡策略：

• 轮询：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉能够被自动剔除。轮询算法适合服务器配置相当，无状态且短平快的服务使用。
• weight权重：指定轮询的几率，weight和后端的访问比例成比例，weight权重越高比例越大。通常用于后端服务器配置不均的情况。
• ip_hash：上面两种算法存在一个问题是就是无法做到会话保持，当用户登录到服务器上后，第二次请求的时候会被定位到服务器集群中的某一个，那么已经登录到某个服务器上的用户会重新定位到另一台，之前的登录信息会丢失。ip_hash算法可以解决这个问题，当用户再次访问请求时，会通过hash算法自动定位到已经登录的服务器上，这样每个客户端可以固定在某个web服务器上，解决客户端session的问题。

配置如下：

upstream myServer {    server 192.168.112.101:8080 down;   server 192.168.112.101:8090 weight=2;   server 192.168.112.101:6060;   server 192.168.112.101:7070 backup;   
}
#指定负载均衡策略为ip_hash
upstream myServer {ip_hashserver 192.168.112.101:8080;   
server 192.168.112.101:6060;   
}

• down：表示当前的server暂时不参与负载
• Weight：默认为1，weight越大，负载的权重就越大。
• max_fails：允许请求失败的次数默认为1，当超过最大次数时，返回proxy_next_upstream 模块定义的错误
• fail_timeout：max_fails 次失败后，暂停的时间。
• Backup：其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

1.3.2 硬件负载均衡实现

硬件负载均衡基于专用设备，性能卓越但成本高昂，比如传统的硬件负载均衡器F5 BIG-IP，支持四层（TCP/UDP）和七层（HTTP/HTTPS）负载均衡，提供流量管理、安全防护（如DDoS防御）、SSL加速等功能，同时提供智能化流量调度策略（如轮询、最少连接、源地址哈希等），并支持高并发场景。
随着国产化技术栈信创替换的迭代，在金融、运营商等重点行业传统的负载均衡设备也逐步由国产设备来改造替换。但是国产负载均衡设备商无论在性能还是功能稳定性上和F5等差距明显，在核心系统的替换以及国产CPU和操作系统的生态适配上任重道远。

1.4 负载均衡算法

负载均衡是将业务流量负载到不同的服务器，而负载均衡算法就是实现在不同服务器之间分配网络流量的逻辑。负载均衡算法的选择会影响负载的分配机制，从而影响到性能和业务连续性，下面将介绍几种常用的负载均衡算法。

1.4.1 Round Robin（轮询算法）

轮询算法很简单，将前端请求按照顺序轮流分配到后台服务器上，不用关心后台服务器的负载和实际连接情况。轮询算法适用于后端服务器性能大致相当的情况，如果某台机器性能异常承载不了这么多的流量，会造成业务访问异常。当然在实际的运维工作中，会采用标准化的配置相同的服务器，以减少维护成本。如下图所示流量请求安装顺序分发到后台三个节点中，保证了流量均衡。

1.4.2 Weighted Round Robin（加权轮询算法）

加权轮询算法是对轮询算法的优化，因为后台服务器在配置和性能上有差异，在负载配置上将配置高、负载低的机器分配更高的权重，使其能处理更多的请求，而配置低、负载高的机器，则给其分配较低的权重，降低其系统负载。加权轮询算法适用于后端具备不同负载容量的服务器，但是配置上更为复杂，也不利于标准化的配置。

1.4.3 Fastest Response Time（最快响应算法）

最快响应算法根据负载均衡器到每一个后端服务器节点的网络响应时间（RTT时延），并将下一个到达的连接请求动态分配给响应时间最短的节点。该算法能够实现应用请求的快速响应，提高业务请求的响应时间，但是会出现请求集中在几个响应最快的节点上。如下图所示，节点1和节点3的响应时间为20ms、节点2为30ms，根据最快响应算法，连接请求负载分发到节点1和节点3中。

1.4.4 Least Connections（最小连接算法）

像前面的轮询算法按照前端的请求次数均衡分配，实现后端服务器的负载均衡，但是实际上连接请求并不能真实反应服务器的负载情况。因此引入了最小连接算法，根据后端服务器当前的连接情况，动态的选取其中当前积压连接数最少的一台服务器来处理当前请求，尽可能的提高后台服务器利用率。最小连接算法在本质上是从后端服务器的角度来观察系统的负载，能够最大限度的利用后端服务器的资源，不足之处是负载均衡需要更多的资源来判断后端服务的连接情况。如下图所示最小连接算法的实现：

除了上面4种，负载均衡算法还有随机法、加权随机法、源地址哈希法等不多介绍，实际应用中轮询算法和最小连接算法应用的较多。

1.4.5 轮询算法和最小连接算法对比

1）轮询算法
轮询算法是静态的负载均衡算法，按照顺序依次分配请求、实现成本低。当服务器性能相近时，能够公平的分配请求。轮询算法中无需记录服务器实时状态，资源消耗较少。不过如果服务器性能差异较大，性能差的服务器可能因接收相同请求量而成为瓶颈。另外对于一些请求处理时间差异较大时（比如短连接和长连接混合的场景），分配可能不合理。

2）最小连接算法
最小连接算法根据服务器当前连接数分配请求，实时响应负载变化，适合处理时间差异大的场景（如长连接、FTP服务等）、兼容不同性能的服务器。最小连接算法会优先选择负载较轻的服务器，降低单点压力。缺点是需实时统计连接数，增加系统复杂度与资源消耗；另外会依赖连接数的准确性，如果连接数统计出现延迟，可能导致误判，并且未考虑到服务器实际处理能力，比如高配的服务器可以处理更多的连接。同时可能存在的一个潜在问题是冷启动问题，新增服务器初始连接数为0，可能被瞬间大量请求压垮。

以下是两种算法的对比：

维度	轮询算法	最小连接算法
定义	按照顺序依次分配请求	分配给连接数最少的服务器
优点	简单易实现	根据实际负载分配
缺点	无法考虑性能差异	实现相对复杂
复杂度	低（静态、无状态）	高（需实时监控连接数）
动态适应性	弱（无法响应负载变化）	强（实时调整）
性能差异兼容性	弱（需加权轮询改进）	中（需加权最小连接优化）
适用场景	短连接、服务器性能均衡	长连接、负载波动大

1.5 负载均衡常见配置

1.5.1 探测协议

负载均衡的健康探测协议有很多种类型：

• HTTP探测：通过发送HTTP请求（如GET方法）到指定路径，根据返回的状态码（如200 OK）判断服务端健康状态。适用于Web服务场景，可深度检测应用层可用性。
• HTTPS探测：在HTTP探测基础上增加SSL/TLS加密，适用于需要安全验证的场景。
• TCP探测：基于TCP三次握手建立连接，成功后立即断开（可能发送RST包）。仅检测端口可达性，不涉及应用层协议，适用于数据库、邮件服务等非HTTP场景。
• UDP探测：向目标端口发送UDP数据包，根据响应判断服务端状态。常用于DNS、流媒体等基于UDP协议的服务
• ICMP探测：通过Ping命令检测网络层连通性，适用于基础网络可达性检查，无法检测应用服务是否正常
• 数据库协议探测：如MySQL的专项协议健康检查，查询select 1 from dual返回结果

对于数据库层而言，使用兼容数据库协议探测，通过连接数据库并查询语句返回结果的方式，能更加准确的判断数据库是否健康。

1.5.2 会话保持

会话保持（Session Persistence），用于确保来自同一用户的请求在特定时间段内始终被转发到同一台后端服务器。会话保持适用于需要保存会话状态的应用场景，比如购物车、登录信息等，避免因请求被分发到不同服务器导致会话数据丢失。
会话保持在实现方式上有以下几种：

• 基于源IP地址（四层会话保持）：根据客户端IP哈希值分配请求，实现简单但存在局限性。例如，多个用户通过同一代理（NAT）访问时，可能导致服务器负载不均。
• 基于Cookie（七层会话保持）：由负载均衡器生成并插入Cookie，后续请求根据Cookie值分配服务器。此方法灵活性高，但需客户端支持Cookie。
• 基于Session存储：通过共享存储（如数据库、Redis）在多台服务器间同步Session信息，适用于高并发场景，但需额外维护存储系统。
• 长连接保持：维持TCP连接不断开，复用同一连接处理后续请求，减少连接开销，但需客户端和服务端支持，且存在连接泄漏风险。

另外需要配置会话保持时间，超时后若无新请求，会话自动终止。同时会话保持可能影响负载均衡的均匀性，并且需要防范Cookie篡改或Session劫持。

1.5.3 X-Forwarded-For

在负载均衡场景中，X-Forwarded-For（XFF）是一个关键的HTTP头部字段，用于透传客户端的原始IP地址，其核心作用是解决在反向代理或负载均衡器后端的服务器无法直接获取客户端真实IP的问题。当客户端请求经过负载均衡器（如Nginx、HAProxy）时，负载均衡器将客户端的原始IP地址添加到X-Forwarded-For头中，供后端服务器识别。但是实际使用过程中X-Forwarded-For并没有配置，因此在服务后端比如数据库层并不能看到客户端真实的IP地址，需要通过其它方法比如报文解析或NAT转换的方式获得。

---

参考资料：

1. https://blog.csdn.net/wendao76/article/details/142490846
2. https://zhuanlan.zhihu.com/p/5108202387
3. 负载均衡算法介绍及应用连接池负载不均问题分析