负载均衡实战：从四层七层到算法配置与排障

做后端开发的人，大概率都遇到过这种场景：一个系统在低峰期运行得很顺，一旦活动流量进来，CPU、内存、连接数先后告警，页面开始变慢，甚至整个服务被拖垮。这时候团队能把服务部署到多台机器上，但请求来了仍然可能“挤”到某一台机器，其他机器空闲着，流量并没有真正被分摊。负载均衡解决的就是这件事：在多个服务节点前面架一层调度者，把进来的请求按照一定策略分发下去，同时负责探测节点是否健康、故障时能不能自动切换。这篇文章按“原理—分类—算法—配置—排障”的顺序，聊聊我这些年设计、部署、排查负载均衡的实战经验，给后端开发和运维同学做参考。

1. 从单机到集群，负载均衡到底解决了什么问题

1.1 单机瓶颈不只是性能问题

很多人以为单机瓶颈就是“性能不够”，加钱换更强的机器就行。但实际操作中，一台机器的处理能力是被多个维度同时限制的：CPU负责算，内存负责存，网络带宽负责传，文件描述符限制能建立的连接数，磁盘IO影响日志和持久化读写。任何一个维度先到极限，整体吞吐就上不去。举个例子，一个纯缓存接口，CPU占用可能只有10%，但TCP连接数先打满了，新请求照样进不来。你再买一台高配机器，连接数上限不调，问题依然存在。

另一个容易忽略的维度是成本和扩展性。单机能力提升通常是指数级涨价的，而且横向加机器还能带来容灾上的好处：坏了一台，其他机器还能顶上。但多台机器出现之后，新的问题也出现了：谁决定请求去哪台？如果靠DNS轮询，浏览器和本地DNS有缓存，很难做到真正均匀；如果靠客户端随机，又没法感知后端负载。于是需要在入口收敛出一层“统一调度者”，这就是负载均衡出现的根本原因。

1.2 负载均衡的核心职责

负载均衡听起来像一个“分发器”，但落到生产环境，它同时干着好几件事。最基础的是调度，也就是根据算法选择一个后端节点处理当前请求；其次是健康检查，周期性地确认哪些节点还活着，把不健康的临时移出转发列表；再次是故障转移，单个请求在后端失败时自动尝试下一个节点，提升可用性；还有一部分负载均衡器会承担弹性伸缩接口，根据CPU或请求量动态增删后端，云环境里的负载均衡服务通常都带这类能力。

另外一个容易被忽略的职责是“可观测性”。流量入口汇聚了所有请求，天然适合记录QPS、请求耗时、错误率，也适合做全局限流和灰度。很多团队的监控告警就是从负载均衡统计开始做的。如果你只把负载均衡当成转发工具，等于浪费了这个位置最大的价值。我见过不少项目花了很多精力在后端埋点，却忽视了入口层本身就能暴露问题，挺可惜的。

1.3 一次请求从进入到返回，负载均衡如何工作

为了方便理解，用一次HTTP请求来看完整路径。客户端先通过域名解析拿到负载均衡的虚拟IP，或者直接连接负载均衡的端口；负载均衡收到请求后，根据配置的调度算法选一台后端；如果是四层转发，多数情况下它会修改报文目标地址并把数据包送往后端，后续数据流直接在客户端和后端之间穿梭，负载均衡只做转发；如果是七层代理，则更像是“中间人”，负载均衡自己跟客户端建立连接，解析完HTTP内容后再与后端建立另一条连接，因此它需要维护两个连接的状态、超时和响应缓冲。

在转发过程中，负载均衡还要处理连接复用、响应超时、错误重试等细节。你从外部看，只有一个入口地址，但入口背后是一个动态变化的机器列表。节点被摘除、恢复、扩缩容，这个过程对调用方是透明的。这也是为什么几乎所有规模化系统都会在入口放一层负载均衡——它把后端的复杂变化封装了起来，调用方只需要记住一个稳定入口。

2. 四层和七层负载均衡，先分清你在给谁做分发

2.1 四层：只看IP和端口，速度快但“不识字”

四层负载均衡工作在OSI模型的传输层，通常基于TCP或UDP协议，核心信息就是源IP、源端口、目的IP、目的端口。它拿到一个包，不解析里面的业务数据，就能按五元组决定转发目标。因为逻辑简单，性能非常高，硬件设备可以做到百万级并发，软件方案也往往比七层代理占用更少的CPU和内存。

适用场景首先是各种非HTTP协议，比如内部RPC、数据库访问、消息队列、游戏长连接、WebSocket。这类流量要么不是HTTP，要么不关心URL路径，用四层一条TCP流直接分发给任意一个后端节点，非常合适。但“不识字”也是它的短板：它不知道用户请求的是 /pay 还是 /login，所以没法做内容路由、按Cookie保持会话、按Header灰度这类精细操作。

2.2 七层：能读懂HTTP，才能做业务级调度

七层负载均衡工作在应用层，最常见的就是HTTP代理。它能解析请求行、请求头、请求体，所以可以做很多四层做不到的事情：按URL路径把 /api/ 的流量打到API服务、把 /static/ 的流量打到静态文件集群；按Header中的用户标识或Cookie决定流向；在负载均衡层终止HTTPS，统一管理证书，后端只跑HTTP；甚至可以在这一层做请求重写、限流、鉴权、跨域配置。

代价是七层需要理解协议，处理每个请求都要做更多计算，同时通常采用代理模式，会占用更多的连接和内存。在高吞吐场景下，同样的硬件跑七层能支撑的QPS往往远低于四层。另一个细节是，七层代理可以发起“重试”，同一个请求可能被发送到多个后端，这在四层通常不会发生，所以下游接口的幂等性设计显得很重要。

2.3 选型的关键判断思路

实际选型时可以先问自己四个问题。第一，协议是什么？如果是HTTP，七层更顺手；如果是私有TCP协议，四层更合适。第二，需不需要按请求内容路由或做灰度？需要就选七层。第三，性能要求有多高？追求极限并发、资源占用敏感的链路，优先四层。第四，要不要做TLS终结或统一证书管理？七层更方便。

在大型架构里，二者不是互斥而是分层配合。常见做法是外层用硬件负载均衡设备或云厂商的四层服务接入流量，扛大规模连接和入口压力，内层再用Nginx这类七层代理做业务路由、限流和灰度。流量先进四层，再到七层反向代理，最后才到达应用服务。这套结构里每一层只做自己擅长的事情，扩展性最好。你可以根据团队水平、运维成本选择简单一点的两层组合，但不要把四层和七层的能力混为一谈。

3. 轮询、最少连接、哈希，怎么选才不踩坑

3.1 轮询与加权轮询

轮询是最容易理解的调度方式：所有后端节点按顺序轮流接收请求，一个接一个，谁也不特殊。它实现简单，对负载均衡器的计算压力也小，但隐含了一个前提假设：每台后端处理能力接近，每个请求消耗的资源也接近。只要某台机器配置低一些，或者某些请求本身特别慢，轮询就会让集群里出现“强者清闲、弱者排队”的闷亏现象。

所以生产环境里更常用的是加权轮询。把后端机器的规格、历史负载、网络条件折算成权重，比如一台高性能机器设 weight=3，另一台普通机器设 weight=1，那么高性能机器按比例多接收请求。这里比较关键的是权重不要拍脑袋定，我一般会先跑一轮压测，记录单机在目标RT下的吞吐量，再按吞吐量的比例去配权重，上线后再根据监控修正。

3.2 最少连接数

最少连接算法是当前谁手里的活跃连接数最少，就把新请求交给谁。它比轮询更贴近实时负载，特别适合请求处理耗时有明显差异的系统。举个例子，接口A偶尔要查复杂报表，可能占用一个连接十几秒；接口B多半是缓存查询，几毫秒就结束。如果按轮询，两个接口交替到达，一个后端可能刚好连续分到多个慢请求，另一个后端却轻松得很。最少连接能缓解这种“慢请求扎堆”的问题。

但需要注意，“连接数”并不等于“业务负载”。有些请求虽然保持连接但不干活，比如长连接池里的空闲连接，它也会被计入连接数，导致负载均衡把新请求分给一个实际上并不空闲的节点。因此我在用最少连接时，通常会同时打开后端节点的真实QPS和CPU监控，避免被连接数表象误导。

3.3 源地址哈希与一致性哈希

源地址哈希的思路是把客户端IP做哈希运算，结果落在哪个节点上，就把这个IP的请求固定发到哪个节点。它的最大好处是会话保持简单：同一个用户只要出口IP稳定，请求就会稳定落在同一台机器上，不需要单独维护Session存储。但它也有明显问题：如果某台后端挂了，那部分IP会被重新映射，而普通哈希在节点数量变化时会导致几乎所有IP的映射关系都发生漂移。

一致性哈希是对这个问题的优化。它把这些请求映射到一个环形空间，节点加入或离开时，只影响邻近的一小部分映射关系，因此大部分请求还能继续指向原来的节点。Nginx的hash $request_uri consistent就是基于这个思路，适合做带状态路由和缓存路由。实际使用中，如果用户切换网络导致IP变化，源地址哈希就不稳了，这时可以用Cookie或请求Header里的用户ID来做哈希，业务上更可控。

3.4 算法选型速查

任何算法都不是银弹。负载均衡的最终目标是让每个节点的资源使用率更均衡，而不是让“请求数量”绝对均匀。如果后端每个请求消耗差异很大，光看请求数就会产生误判。所以我在实际项目里很少只依赖一个算法，通常是“最少连接+权重”或者“一致性哈希+健康检查”组合着用。

4. 用Nginx从零搭一套七层负载均衡

4.1 为什么用Nginx做演示

很多团队一开始接触七层负载均衡，就是从Nginx反向代理开始的。它轻量、配置直白、生态资料多，几乎成了事实标准。用它做演示能让你最快看到upstream、proxy_pass、健康检查、会话保持这些概念是怎么落到配置文件里的。需要说明的是，这不是唯一的方案，其他常见软件或云服务也能实现同样效果，但Nginx适合作为理解原理的起点。

Nginx本身既可以做四层（stream模块），也擅长七层（HTTP模块）。本文演示的是七层负载均衡，也就是根据HTTP请求做转发。如果你需要在它前面再放一个四层入口，那是架构设计上的事情，不用把两者写在同一个示例里。

4.2 最小化upstream配置

假设我有一组API服务，部署在三台内网机器上，IP分别用示例地址代替。Nginx配置核心部分如下：

nginx复制upstream backend_api {
    server 172.16.10.11:8080 weight=3 max_fails=3 fail_timeout=10s;
    server 172.16.10.12:8080 weight=3 max_fails=3 fail_timeout=10s;
    server 172.16.10.13:8080 weight=1 max_fails=3 fail_timeout=10s backup;
}

server {
    listen 80;
    server_name api.example.local;

    location /api/ {
        proxy_pass http://backend_api;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_connect_timeout 5s;
        proxy_read_timeout 10s;
    }
}

这里upstream定义了一组后端和一个负载均衡组backend_api。weight=3表示这台机器默认承担三份流量，backup表示备用节点，平时不参与分发，只有当主用节点都不可用时才会顶上。max_fails和fail_timeout是Nginx的被动健康检查配置：在一个时间窗口内连续失败达到次数，就把节点标记为不可用，等待一段时间后再重新尝试。

proxy_set_header这几行非常关键，否则后端拿到的请求头会缺失真实客户端信息，导致日志里全是负载均衡的IP，排查问题会很痛苦。改完配置后记得先执行nginx -t检查语法，再nginx -s reload平滑生效。

4.3 被动健康检查与失败重试

Nginx默认的max_fails和fail_timeout是“被动健康检查”，意思是它不会主动去探测后端，而是在转发请求失败时累计错误。比如后端进程崩溃导致TCP连接拒绝，单次请求失败后Nginx才会感知到。这个方式对突发故障是够用的，但对“进程还在、响应极慢”的假死状态不够灵敏，因为只要请求最终没有抛出连接级别的错误，它不会立即把节点摘掉。

在需要主动探测的场景下，可以引入单独的检查脚本或带健康检查支持的Nginx扩展。另一个相关配置是proxy_next_upstream，它允许当前请求在上游失败后自动换下一个节点重试：

nginx复制proxy_next_upstream error timeout http_502 http_503;

这里要特别提一句：重试是有副作用的。如果是查询类接口，重试很安全；但如果是下单、扣款这类写操作，盲目重试可能导致重复处理。所以我通常只对幂等接口开启proxy_next_upstream，或者在业务侧通过唯一请求ID做去重，再配合重试。

4.4 会话保持与一致性哈希

很多服务不是天然无状态的，用户登录状态、临时购物车、验证码都可能放在后端进程内存里。这时候同样的用户请求如果被分发到不同节点，就会出现“换个机器就掉登录”的问题。解决方案之一是使用一致性哈希，让相同标识的请求尽量固定到同一台后端：

nginx复制upstream backend_api {
    hash $cookie_userid consistent;
    server 172.16.10.11:8080;
    server 172.16.10.12:8080;
}

上面的配置会把Cookie里的userid做哈希，并用consistent启用一致性哈希特性。相比ip_hash，用用户ID做标识的好处是用户换网络、换出口IP后，映射关系依然稳定；缺点是业务侧需要先种好userid这个Cookie，否则取不到值就只能退化成随机分发。

我的个人建议是：能做成无状态就不要依赖会话保持。把Session数据放到Redis或数据库里，负载均衡就可以放心使用最少连接或轮询，后端节点随时扩缩容，也不会出现“只有某个节点存着用户状态”的尴尬。会话保持只是一个兜底方案，不应成为架构上的长期依赖。

5. 真实工况下的排查与避坑清单

5.1 现象：上游偶尔出现502/504

负载均衡层最常见的报错是502和504。502通常是Nginx无法连接后端，或者后端返回了非法响应；504则是Nginx等待后端响应超时。第一次遇到时，很多人会怀疑负载均衡配置坏了，但更常见的原因是后端处理时间超过了proxy_read_timeout。

我的排查顺序是：先用curl -v直接访问Nginx和后端，对比两者响应时间；再看Nginx的error.log里有没有upstream timed out关键字；接着确认后端是否有慢SQL、锁等待或线程池排队。如果后端平均响应需要8秒，而proxy_read_timeout只设置了5秒，那么直接调长超时时间就能解决。但不要无脑调成300秒，那会把后端故障隐藏起来，最终拖垮整个集群。

5.2 现象：后端服务明明健康，流量却一直打到一个节点

这种情况通常不是负载均衡坏了，而是你选择的调度策略本身带有“粘性”。最常见的是哈希类策略，同一个用户或同一个键的请求会固定到达同一节点，容易造成某节点流量明显偏高。另一个容易被忽略的是连接复用：Nginx到后端的长连接会保持一段时间，长时间复用后，新请求可能继续复用已经建立的连接，即使另一些节点处于空闲状态。

排查时我会先看配置文件里用了什么算法，再看后端各节点的活跃连接数。方法很朴素，在每台后端上用ss -tan | grep :8080 | wc -l统计连接数，对比Nginx的upstream状态页。如果是哈希不均，可以换用一致性哈希或根据实际业务键重新设计；如果是连接复用问题，可以适当调低keepalive数量，或者改用最少连接策略来平衡连接数。

5.3 现象：集群扩容后负载并没有变均匀

扩容最怕的就是机器加上了，流量却不到新节点。先检查配置里新节点有没有被backup标记，因为备用节点平时不承担流量；再看权重是否太高或太低，如果新机器权重是1，老机器是3，流量打到新机器的比例本来就低；最后如果是哈希算法，节点数量变化时，只有一部分键会迁移到新节点，短时间内看起来不够均匀。

更隐蔽的一个问题是后端服务还没完全就绪。Java或Node服务启动后需要JIT预热或依赖连接初始化，如果负载均衡立刻把大量流量放进去，新节点可能反复超时，然后被健康检查标记为失败掉出集群，结果老节点压力更大。正确做法是先让少量流量进入新节点，观察CPU、GC、错误率，确认稳定后再逐步调大权重。

5.4 一套稳定的排查顺序与个人体会

我给自己定了一套固定的负载均衡排查顺序：先确认请求到底有没有到达负载均衡，再确认负载均衡转发到了哪台后端，然后对比各节点的监控指标，最后才去调参数。如果跳过了中间某一步，很容易把问题归因到配置上，结果翻半天代码发现是后端接口本身变慢了。

还有一个经验是：任何一次负载均衡配置变更都要做小流量验证，再全量上线。负载均衡是流量的总入口，改错一个权重、多写一个重试，影响的是所有调用方。线上出问题时，也先看节点分布和错误日志，不要一上来就调权重。我在多次扛过压测之后越来越觉得，负载均衡设计得好，系统不一定跑得最快，但一定跑得最稳；它不负责让业务变得聪明，只负责让整个集群在流量面前不崩溃。这就足够了。