阿里云上搭 LVS 时，哪些坑最容易踩

在阿里云上跑四层负载均衡，很多人第一反应还是 Nginx。但如果是 TCP/UDP 层的流量分发，LVS 依然稳定、开销小，值得单独考虑。这篇文章从 LVS 的基本原理说起，结合阿里云 ECS 的网络环境，讲讲部署时的思路，以及一个大促场景下的实际改造过程。

LVS 是什么，和 SLB 怎么分

LVS（Linux Virtual Server）是基于 Linux 内核的四层负载均衡方案，真正干活的是内核里的 IPVS 模块。它工作在传输层，只看 IP 和端口，不解析 HTTP 内容，所以转发路径短，单机能扛的连接数也比较可观。常见的搭法是 LVS 在最前面负责分发，后面的 Nginx 或应用服务器再处理七层逻辑。

在阿里云上，选择一般分两条路。一条是直接用负载均衡 SLB，高可用和扩容都由云厂商托管，省心。另一条是在 ECS 上自建 LVS，转发规则和内核参数都能自己调。自建的灵活性是真的，但高可用、监控和故障切换也得自己兜底，这部分工作量常被低估。

三种转发模式怎么选

LVS 支持 NAT、DR、TUN 三种模式，选哪个主要看网络条件和性能要求。

NAT 模式：调度器改写请求和响应的目标地址。配置最简单，但回包也要经过调度器，调度器很容易成为带宽瓶颈。后端数量不多、流量不大时用它比较合适。
DR 模式：调度器只改写数据帧的 MAC 地址，回包由后端直接返回客户端，性能最好。代价是调度器和后端必须在同一个二层网络里，每台后端还要在 lo 上绑定 VIP，并关闭 ARP 响应，配错一步就会出现地址冲突。
TUN 模式：用 IP 隧道封装转发，后端可以跨网段部署，适合跨可用区。但后端内核要支持隧道模块，运维上多一层要维护的东西。

这里要特别注意阿里云 VPC 的网络限制。ARP 广播和 IP 绑定都不像物理机房那样随意，DR 模式在阿里云上往往要结合辅助私有 IP 或其他网络方案一起评估，不能照着机房文档直接搬。如果团队对这些细节还不熟，先用 NAT 模式或者直接上托管 SLB，比硬凑 DR 更稳妥。

部署的关键步骤

一套能用的 LVS 集群，大致要过下面几关：

规划 VIP，给调度器分配辅助私有 IP，并在安全组里放通对应端口。VIP 没规划好，后面改起来很麻烦。
在调度器上安装 ipvsadm，定义虚拟服务和真实服务器，并选定调度算法。常用的有轮询（rr）、加权最小连接（wlc）和源地址哈希（sh），后端机器配置不一致时，wlc 比 rr 更合理。
用 keepalived 做主备切换，并配好健康检查，让异常节点自动摘除。健康检查的超时和重试次数要按业务实际响应时间来设，设得太激进会误摘节点。
在后端节点配置回源路由和内核参数，确保回包路径正确。NAT 模式下这一步最容易漏。
接入云监控，对连接数、带宽和后端健康状态设告警。没有告警的 LVS 出了问题，往往是客户先反馈。

案例：电商大促前的入口改造

某中型电商团队在大促前遇到一个典型问题。原来的入口是两台 Nginx 直接对外，活动开始后瞬时连接数超过单机上限，TCP 连接偶尔堆积，客服那边收到不少“页面打不开”的反馈。团队想在前面加一层 LVS 做四层分发，后端 Nginx 保持不动，这样改动范围最小。

最终方案是在同一可用区部署两台 ECS 作为调度器，用 keepalived 共享一个 VIP，采用 NAT 模式，后端挂四台 Nginx，调度算法选加权最小连接。没选 DR，是因为团队的 VPC 网络配置已经比较复杂，短期内很难保证二层网络稳定。这种情况下先用 NAT 跑通，比临时冒险切换更踏实。

上线之后，入口层的连接处理能力明显好转。压测时单对调度器能稳定承接的并发，已经远高于原来的水平。更实际的收获是故障场景：有一次某台 Nginx 因为发布出了异常，健康检查在几秒内就把它摘了，用户侧基本没感觉。大促期间，团队在云监控里看到调度器的 CPU 和网卡带宽都还有余量，这为后面的扩容判断提供了依据。

这次改造的经验可以概括成一句：LVS 的价值是把四层转发做得简单稳定，复杂的业务逻辑留给后端。链路越清楚，出问题时越快定位。