亿级并发下网络型负载均衡NLB的架构选型与部署实践

做运维这些年，流量问题见了不少，大的小的都有，但真要面对亿级并发这个量级，很多朋友脑子里第一反应还是“加机器”。其实加机器治标不治本，入口如果不做高性能流量分发，加了机器也打不进去。NLB（Network Load Balancer，网络型负载均衡）就是专门解决这个问题的——它工作在四层，靠协议栈和哈希调度把流量均匀分到后端服务器，单实例能扛住亿级并发连接，而且部署起来并不复杂。这篇文章我打算从原理到实操，把NLB怎么落地、怎么避坑，一次讲清楚，适合正在做架构选型、或者流量上来后已经被入口压垮的朋友参考。

因为我是直接在一线摸爬滚打过来的，所以下面的内容会带比较强的实战视角。不会只给你堆概念，而是讲清楚选择背后的为什么，以及你上了NLB之后可能遇到的那些坑。

1. 亿级并发这道坎，到底难在哪

1.1 流量分发不只是“把请求转发出去”

很多人理解负载均衡，觉得就是把请求分摊到几台机器上，听起来像一个简单的“快递分拣员”。但实际在线上环境，这个“分拣员”要做的事远远不止“转发”两个字。它需要在高并发下维持连接不中断，需要识别后端节点是否存活，需要把同一类请求固定到同一台后端，需要处理突发流量而且不能成为瓶颈。说白了，流量分发本质是一个“入口治理”问题。

举个生活化的例子。火车站进站口就是流量分发：如果只有一个安检口，后面站台再多，旅客也全堵在门口。你加再多的站台工作人员，人进不去闸机也白搭。负载均衡就是这个安检口的升级版——它不仅要让人快速过去，还要知道哪个站台人少，哪个站台已经人满为患，甚至还要识别哪些旅客必须去指定的站台。这些规则一旦复杂起来，单靠手写转发程序根本不现实。

而且流量分发还有一个容易忽略的点：它必须比后端系统更稳定、更快。因为它是所有流量的第一跳，它挂了，后端再健康也白搭。它慢了，整个系统延迟就被拉高。所以做负载均衡选型，本质上是在找一个“既快又稳还能弹性扩缩”的入口组件。

1.2 为什么传统方案在亿级并发下会崩

先说单机方案，比如自己用nginx做四层转发。单机nginx在性能调优之后，四层转发能力确实不错，但到了百万级并发连接、几十Gbps吞吐这个量级，单机就开始吃力了。原因有几个：

• CPU中断瓶颈：每个数据包到达网卡都要触发中断，CPU频繁被打断，相当一部分算力耗在“处理包”本身，而不是“转发包”上。
• 内核态和用户态切换：传统socket编程里，数据要从内核缓冲区拷贝到用户态，再拷贝回去。每次转发都有多次拷贝，内存带宽和延迟都受影响。
• 连接表 / conntrack 膨胀：四层转发需要维护连接状态，百万级别连接还能扛，千万甚至亿级并发连接时，连接表本身就要占大量内存，查找效率也会下降。
• 单点故障：一台机器扛不住，多台机器自己搞集群，又要面对会话同步、配置同步、虚拟IP漂移等问题，复杂度直线上升。

再说传统硬件负载均衡，比如F5。F5这类设备在金融、政企里是标配，性能也确实强，但它的问题是贵、扩容慢、运维重。流量涨了想加一台设备，采购流程走几个月很正常，而且硬件设备性能固定，没有办法“按需伸缩”。对于互联网业务这种流量忽高忽低的场景，硬件设备要么性能冗余浪费，要么又不够用。

自建LVS这种方案呢？LVS的性能其实不差，它在Linux内核层做转发，能扛的并发比nginx高不少。但LVS的维护难度比较高：DR模式要处理ARP问题，NAT模式要扛转发瓶颈，调度算法、VIP漂移、多机房容灾，每一块都要自己搞。我见过不少团队用LVS用得很好，但那是建立在有专门运维人力、且业务规模稳定的前提下，中小团队很难复制。

到了这里你应该理解了，传统方案要么性能不够，要么成本太高，要么运维太重。云上NLB的出现，其实是把“硬件级的性能”和“软件化的弹性”结合到一起。它底层可以用智能网卡卸载、DPDK这类技术，在数据面把转发能力做到极致，同时控制面暴露成API和配置页面，让用户可以按需创建、按量付费、秒级扩容。

2. NLB核心机制：它凭什么顶住亿级并发

2.1 四层转发和它们的性能谱系

网络模型里，四层指的是传输层（TCP/UDP），七层指的是应用层（HTTP/HTTPS）。NLB工作在四层，这意味着它不关心请求内容是GET还是POST，也不关心URL路径是什么，它只看“从哪里来、到哪里去、什么协议、什么端口”。这个特点带来的最大好处就是转发逻辑简单、性能损耗小。

从数据面实现来看，现在高性能四层负载均衡有几条技术路线：

• 内核协议栈优化：对Linux内核进行参数调优，比如打开tcp_tw_reuse、调整文件描述符上限、优化网卡多队列，在不改代码的情况下榨干性能。这条路最简单，但上限有限。
• DPDK用户态转发：绕过内核协议栈，直接在用户态轮询网卡收包，再用自研或开源的转发框架做四层转发。这种方式避免了内核态和用户态切换，单机性能大幅提升。
• 智能网卡/可编程交换机卸载：把数据包转发逻辑下放到网卡硬件或者可编程交换机上，CPU几乎不参与数据面。正规云厂商的NLB底层基本都会用到这类硬件卸载能力，才能在单实例上支撑非常高的吞吐和连接数。

所以我一直认为，云上NLB和传统自建方案的本质区别不是“谁更聪明”，而是“把转发这件事专业化了”。云厂商用专门团队、专门硬件去优化一个你平时根本不会去优化的数据面，然后以服务的形式卖给你。

2.2 并发连接与底层资源的关系

很多朋友听到“亿级并发连接”会有个误区，以为这是一秒钟同时有上亿个活跃请求。其实并发连接（Concurrent Connections）和每秒新建连接（CPS）是两个概念。一个在线用户建立TCP连接之后，不一定每秒都在发请求，连接可能是“挂着”的，只有发数据时才活跃。NLB能扛住亿级并发连接，靠的是它维护连接表的能力。一条空闲TCP连接在连接表里只占很小的内存，但表大了之后查找效率、超时处理、内存占用都会成为挑战。

NLB处理连接的方式通常是这样的：

• 新建连接：数据包到达NLB，NLB根据调度算法选择一个后端服务器，建立映射关系，然后转发。
• 存量连接：同一个连接的数据包，NLB根据连接表直接映射到同一个后端，保证连接不被拆散。
• 连接关闭：四次挥手结束后，NLB清理连接表项。

这里有一个关键参数叫“等开销负载均衡”，在一致性哈希、加权轮询这类算法里，目标就是让每个后端节点分摊的流量尽量“等开销”。如果调度不均，某台后端被打爆，其他后端空闲，整个系统还是会出问题。NLB在调度算法上做了很多优化，比如一致性哈希可以有效减少后端节点变化时连接重映射的数量，避免大规模连接抖动。

另外，四层负载均衡还有一个隐形开销：数据包转发本身。如果NLB是按NAT模式转发，每个包都要做源IP和目的IP的改写，这个计算在高速率下一点也不轻。有的NLB实现会直接在数据面用硬件改包，或者用Full-NAT + 回程直连等方式减少负载。 具体实现各家云厂商不同，但思想都是一样的：尽量把CPU从数据面解放出来。

2.3 从nginx到NLB：上层需求推动的东西

我把nginx和NLB放一起对比，是想强调它们不是替代关系，而是分层合作的关系。nginx本身是一个优秀的七层负载均衡和反向代理，但在“亿级并发”这个目标下，nginx有几个先天短板：

• 进程模型：nginx的worker进程数量受限于CPU核数，每个worker处理连接的能力有限，撑到几十万并发连接问题不大，但上千万就非常吃力了。
• HTTP协议解析开销：nginx要解析HTTP头部、处理location匹配、rewrite规则、缓存逻辑等，这些功能强大但也消耗CPU。纯四层转发比它省太多。
• 配置热加载与运维：nginx配置变更需要reload，虽然现在有openresty、nginx plus能做动态upstream，但复杂度上来了，稳定性也会受影响。

所以业界比较经典的分层架构是：NLB做入口四层转发，nginx/网关做七层路由。NLB把海量并发连接挡在入口，按IP和端口把流量拆给后端的nginx集群，nginx再做域名路由、URL匹配、鉴权、限流、缓存这一类“有脑子”的活。这样NLB负责“快”，nginx负责“聪明”，各司其职。

云上NLB相比自建还有一个隐性优势：它天生就跟云生态打通。创建NLB之后，后端服务器组可以直接挂云主机、容器实例，弹性伸缩时自动加/减服务器，健康检查自动摘除异常节点，配合云上的监控告警、日志服务，整套可观测性直接补齐。你不用再像自建LVS那样，单独搭一套监控和告警体系。

3. 部署与配置实操：把NLB用起来

3.1 创建NLB的完整流程

不同云厂商控制台布局不一样，但核心申请流程大同小异。我用一套通用步骤来描述，你对着自己云厂商的控制台找对应入口就行。

1. 创建实例：在控制台选择“负载均衡”或“网络型负载均衡”，选地域和可用区。建议优先选多可用区部署，这样单个可用区故障时不至于整体不可用。
2. 配置网络：选择VPC（虚拟私有网络）和交换机。可以把NLB放在独立的接入子网里，方便安全组管理。
3. 创建监听器：这是最核心的步骤。协议选TCP、UDP还是TLS，端口按业务需求填。如果不是强烈的UDP业务需求，大多数场景TCP就够了。
4. 添加后端服务器组：选“新建服务器组”或“已有服务器组”，把后端ECS实例或容器实例加进去。这一步要注意IP地址选择，如果NLB和后端在同一个VPC，直接填内网IP即可。
5. 配置健康检查：默认会开启。健康检查方式选TCP或HTTP，建议用TCP监听后端服务端口，简单直接。
6. 设置调度算法：按业务需求选择加权轮询、最小连接数或一致性哈希。
7. 关联安全组：放通监听端口和健康检查IP段。
8. 绑定EIP或DNS解析：如果是公网业务，可以绑定弹性公网IP（EIP），或者在DNS控制台把业务域名解析到NLB提供的域名上。

创建完实例后，我建议先用curl或telnet小流量验证连通性，确认后端能响应，再切换DNS流量。尤其是公网业务，DNS解析有生效时间，提前验证可以避免流量切过去后发现后端不通的尴尬。

3.2 监听器、后端服务器组和健康检查的关键参数

监听器的协议选择直接影响你能用到的功能，这块我把参数拆开细讲。

协议选型

• TCP：最常用。适用HTTP、HTTPS、WebSocket、数据库连接池等绝大多数TCP业务。NLB只做四层转发，源IP默认会转换成NLB的内网IP，后端要获取真实客户端IP的话，需要开启“保留客户端IP”功能。
• UDP：适用DNS、语音、视频流等UDP业务。UDP没有连接状态概念，NLB的转发逻辑会更简单，但也意味着做会话保持更困难，一般靠源IP哈希解决。
• TLS：也叫SSL监听，NLB负责终结HTTPS的TLS握手，证书统一放在NLB上，减轻后端压力。不过要注意，开了TLS终结之后，后端看到的是HTTP明文流量，链路在NLB到后端这一段是明文传输，如果走公网兜底会不安全，建议在同一VPC内使用。

调度算法

• 加权轮询（WRR）：适合后端机器配置一致、请求处理时间相近的场景。如果某台机器性能强，给它更高权重。
• 最小连接数（Least Connections）：适合长连接业务，比如WebSocket、消息推送。每次新建连接时，NLB会优先把请求发给当前活跃连接数最少的后端。
• 一致性哈希（Consistent Hashing）：适合需要把同一个客户端IP固定到同一台后端的场景，比如没有共享Session而是本地Session的旧系统。一致性哈希比普通源IP哈希的好处是，后端节点增减时，只有少量连接会被重新映射，减少“雪崩式”的缓存失效。

会话保持

四层NLB的会话保持一般靠“源IP哈希”和“一致性哈希”实现，HTTP场景如果想要基于Cookie的会话保持，建议在七层nginx或网关层做，不要指望NLB。因为NLB不看HTTP协议内容，无法解析Cookie。

健康检查参数

健康检查是NLP最容易被人忽略、也最容易踩坑的地方。几个关键参数：

• 检查间隔：每多少秒检查一次，默认一般是5秒。间隔太短会频繁向后端发探测请求，压力大；间隔太长，后端故障时摘除节点不及时，会有大量请求打到异常节点。
• 超时时间：等待后端响应多久算超时，一般2-3秒足够。如果后端接口本身需要更长时间返回，可以适当调大，但不要为了掩盖后端问题而无脑调大。
• 健康阈值/不健康阈值：连续成功多少次判定为“健康”，连续失败多少次判定为“不健康”。默认2-3次比较合理，阈值太高会导致故障发现慢。

我见过一个真实案例：某团队把健康检查配成了HTTP方式，检查路径是“/healthz”，结果后端服务这个接口需要查数据库，数据库抖动一下，健康检查就失败，NLB把后端摘除，流量全打到其他机器，其他机器也压力变大，最终引发雪崩。所以健康检查路径一定要选轻量级的，最好是后端进程内存态就能直接返回的状态接口，不要查数据库、不要查下游依赖。

3.3 配合EIP、DNS做接入层架构

公网业务最常见的一种接入方式是这样的：

客户端 -> DNS解析 -> 云NLB域名/EIP -> NLB实例 -> 后端服务器组（多可用区）

具体到云上，我建议把DNS解析到NLB的域名，而不是直接绑EIP然后解析到EIP。原因有两个：一是NLB域名自带容灾属性，当某个可用区异常时，云厂商会在解析层面做调整，而你绑EIP的话，这个容灾逻辑就要自己写；二是NLB域名可以配合云上的“网络型负载均衡”做实例级弹性伸缩，绑定EIP的话还得管理EIP的迁移。

后端服务器组建议按可用区分组。比如可用区A放2台ECS，可用区B放2台ECS，NLB会自动把流量分发到两个可用区的后端。当某个可用区整体故障时，健康检查会摘除该可用区的后端节点，流量自动转移到另一个可用区。这时你要注意容量规划：如果平时两个可用区各承担50%流量，单可用区故障时，另一个可用区的后端就要扛全部流量，所以尽量让单可用区的容量上限能够覆盖全量流量，或者依赖弹性伸缩快速补充新机器。

另外还有两个配置上的细节：

• 空闲连接超时：四层监听一般都有一段时间无数据就断开连接的设置，默认900秒左右。如果是长连接业务比如消息推送，建议把这个值调大，或者确认后端应用自己有保活机制。否则连接被NLB静默断开，客户端要等超时才能感知，影响体验。
• 连接耗尽（Connection Draining）：后端服务器从服务器组移除时，已经建立的连接是否等待处理完再断开。这个功能一定要开启，尤其是发布新版本、重启服务时，能避免正在进行的请求被突然掐断。

4. 硬件负载均衡 vs 云上NLB vs 自建nginx：怎么选

4.1 F5等硬件负载均衡的优劣

传统企业尤其是政企、金融行业，F5几乎是标配。我见过不少从F5迁到云上NLB的项目，也见过不少继续用F5的场景。F5给人最大的安全感是“性能可预期、设备专用、功能齐全”，它的硬件ASIC加速能提供非常稳定的转发能力，而且内置了丰富的应用层安全能力，比如HTTP策略、SSL卸载加速、应用防火墙等。

但F5的问题也很明显：

• 采购周期长：性能规格要提前预估，最低也得预留半年到一年的冗余，业务增长快一点，设备就过时了。
• 运维门槛高：配置同步、客户端的设备维护、版本升级，都需要专业工程师，好的F5工程师不好找。
• 弹性差：硬件设备不支持秒级扩容，流量洪峰来了只能靠现有设备硬扛，扛不住就加设备，加设备又是几个月周期。

F5适用的场景我总结为：流量模型稳定、合规要求严、预算充足、且对云原生弹性没有强烈需求。互联网业务如果走云上架构，我建议优先考虑云上NLB——成本更低，运维更省，功能上对于绝大多数业务已经够用。

4.2 nginx负载均衡适合什么场景

nginx负载均衡我觉得是每个团队都应该掌握的基础能力。它对HTTP协议层面的控制力是NLB替代不了的：URL路由、请求头改写、gzip压缩、缓存、限流、灰度发布，这些都是七层能力。

nginx适合做“业务网关”，比如对外透出HTTP API，按域名把不同业务路由到不同后端。它也适合做“边缘代理”，承载HTTPS证书的终结、WAF防护、以及简单的静态资源服务。

但nginx不适合做“超大流量的四层入口”。原因之前讲过：单机性能有限，集群化运维复杂，而且它本质是应用层软件，面对突发的TCP连接风暴，处理能力远不如专门做四层转发的NLB。把nginx放在NLB后面，让NLB先“卸掉”大部分连接压力，nginx集群只需要处理那些真正需要七层逻辑的请求，这是我觉得最合理的架构。

4.3 三种方案对比表

我把三种方案放在一起对比一遍，方便你做选型：

这个表不是绝对的，但我觉得能帮你建立一个基本的选型框架。如果预算充足、业务稳定、且有合规审计要求，硬件方案没问题。如果你已经在云上，希望快速上线并应对大促流量，NLB是首选。如果业务逻辑复杂，需要精细化控制HTTP请求，保留一层nginx在应用前面完全合理。

5. 常见问题与排查技巧实录

5.1 “拥塞但又不拥塞”的奇怪现象

有次排查一个线上问题，现象是客户端大面积报连接超时，但后端的CPU、内存、带宽看起来都不高，监控面板一片绿色。最后定位到原因是NLB的并发连接数达到上限了——云上NLB虽然支持高并发，但单实例也有规格上限。后端机器很闲，但流量进不来，NLB变成了瓶颈。这个案例给我一个教训：监控不仅要看后端，还要看入口组件的指标。NLB的并发连接数、新建连接数（CPS）、吞吐量这几个指标一定要提前配好告警。

另一次类似的现象，后端机器负载也不高，但NLB频繁把后端标记为不健康。排到最后发现是NLB的健康检查源IP被后端机器的安全组拦截了。云上NLB健康检查通常来源于一段固定的IP段，你需要把这段IP加入后端安全组白名单。这个坑很隐蔽，因为人工访问后端是通的，只有NLB的健康检查不通。所以配置后端安全组时，先看看云厂商文档里健康检查源IP的网段。

5.2 排查连接重置问题的自检顺序

客户端连接被重置，是最常见的NLB问题之一。遇到这种情况，我建议按这个顺序排查：

1. 先排除后端自身问题：直接登录后端ECS，本地telnet监听端口确认服务端口能通。后端自身如果拒绝了连接，NLB转发过去自然也是REJECT。
2. 检查NLB监听器状态：看NLB后端服务器组里的节点是否是“健康”状态。如果不健康，说明NLB已经停止往这个节点转发流量，问题多半出在健康检查配置或后端服务的健康检查接口上。
3. 检查后端安全组/防火墙：确认NLB所在VPC网段、健康检查IP段是否放通。这一点特别容易漏，一定要看。
4. 检查连接空闲超时配置：如果客户端和后端之间有较长时间没有数据交互，NLB可能主动断连。此时客户端需要能自动重连。这也是为什么移动端和服务端通信协议里一定要做心跳，不要裸奔靠TCP。
5. 看NLB和后端的TCP握手日志：开启NLB的日志功能，分析每个连接的SYN、ACK、RST。RST出现在哪个方向，就能定位是NLB主动发起的，还是后端发起的，或者是客户端中途断开的。

5.3 几条避坑经验

这几条是我在多个项目里实际踩过的坑，针对性很强，建议收藏。

• 健康检查频率别太激进：默认5秒一次就够了，不需要改成1秒。检查频率过高，NLB会频繁连接到后端端口，有些服务的连接日志会被刷爆，还会掩盖服务的真实负载情况。
• 调度算法要按业务选，不要无脑轮询：长连接业务用最小连接数更合理，短连接高吞吐用加权轮询更合适。如果后端应用有本地缓存，用一致性哈希把相同来源的请求固定到同节点，能明显提高缓存命中率。
• 多可用区部署不等于高可用：NLB多可用区只是保证“有备用”，但要确保每个可用区的后端实例都配了足够的弹性和容量。否则单可用区故障，另一个可用区立刻被打爆。
• 公网业务一定要开启DDoS防护和访问控制：NLB暴露在公网，本身就是攻击目标。接入云上的DDoS高防或WAF，能有效缓解SYN Flood这类四层攻击。别以为NLB性能高就能硬扛攻击，攻击流量也会占用带宽和连接数。
• 后端会话保持要谨慎开启：如果后端是无状态设计，尽量不要开启会话保持。会话保持会破坏负载均衡的“等开销”目标，导致某些节点连接数集中。只有在后端强依赖Session、且短期无法改造时，才考虑用它过渡。

最后再分享一个我自己的经验：上NLB之前，先把“业务容量预估”这件事做了。结合历史峰值流量、未来半年的增长预期，确定NLB的规格和后端服务器组的初始机器数。云上资源好处是可以弹性伸缩，但弹性伸缩有生效时间，不要等流量真的打过来再去扩容。提前扩容，流量洪峰过后再缩容，成本可控，稳健性和用户体验都好很多。这套思路，无论是大促、活动还是常规业务增长，都适用。