LVS全称Linux Virtual Server，是章文嵩博士在1998年发起的开源项目。它的关键组件IPVS位于Linux内核中，工作在OSI模型的第四层，按TCP或UDP的地址和端口转发连接。它不解析HTTP内容，只做连接调度，所以性能高、占用资源少，不少大型互联网公司把它用在入口层。
LVS有三种常用转发模式。NAT模式会改写目标地址，配置最简单，但回包也要经过调度器，调度器容易成为瓶颈。DR模式只改写MAC地址，后端直接把响应发给客户端，吞吐量最高。代价是每台后端都要配置VIP，还得处理好ARP，否则请求可能绕过调度器，或者出现地址冲突。TUN模式通过IP隧道转发，调度器和后端不在同一机房时常用它。
在阿里云上落地LVS的思路
多数开发者在阿里云上不需要自己搭LVS集群。阿里云的负载均衡产品（早期叫SLB，现在主要是CLB）在底层用的是类似的四层调度思路，你在控制台或通过API创建实例就能使用。实际配置时，下面四项最需要留意：
- 监听协议：TCP和UDP属于四层，适合数据库、游戏、长连接服务；HTTP和HTTPS属于七层，适合按域名、路径分流。协议选错了，后面的转发规则再细也没用。
- 健康检查：它决定哪台后端会被摘除。检查间隔、超时时间和失败阈值要按业务调整。间隔太短会给后端额外压力，阈值太松则故障节点迟迟下不了线。
- 调度算法：常见的有轮询、加权轮询、最少连接。用加权轮询时，权重要按后端机器的规格来设。规格不同却配同样的权重，性能强的机器闲着，弱的那台先被打满。
- 会话保持：只有业务要求同一用户固定落到同一台服务器时才开启。开启后要留意它和灰度发布的冲突，灰度版本可能只拿到很少的流量。
产品名称、功能项和默认参数会随阿里云版本变化，上线前以官网文档和控制台为准。
案例：一次促销活动的入口改造
某中小型电商团队去年准备做一次限时促销。原架构是一台Nginx直接对外，后面接三台应用服务器。运营预估活动开场的几分钟，并发请求会比平时高十几倍，单台入口明显扛不住。团队的目标有两个：入口层能横向扩展，单台后端出问题时不影响整体可用性。
架构设计
- 创建一个负载均衡实例并绑定公网IP。对外只暴露这一个入口，应用服务器不再直接对外。
- 四层监听80和443端口，流量交给后端的Nginx，由它继续处理域名和路径规则。证书和缓存策略留在自己手里，改起来方便。
- 把三台应用服务器加入后端服务器组，权重按规格设为3:3:2，健康检查路径指向一个轻量接口。
- 把原本分散在各服务器上的SSL证书统一放到负载均衡或Nginx层。配置少了，续期时漏改某台服务器的风险也小了。
踩过的坑
- 健康检查路径太重：最初检查的是首页，而首页要查数据库。促销期间，健康检查本身就拖慢了服务。换成静态的健康接口后，问题消失。
- 安全组没放行：后端安全组只允许公网访问，没有放行负载均衡的回源网段。检查全部失败，流量一度中断。排查时先看健康检查状态，再看安全组规则。
- 长连接超时：部分接口使用长连接，空闲超时设得太短，客户端频繁重连。把超时时间和Nginx的keepalive参数对齐后，连接数明显稳定。
- 会话保持与灰度冲突：开启会话保持后，新版本只分到少量用户，灰度比例严重失真。最后改由应用层通过Token识别用户，问题才解决。
活动当天入口层运行平稳。一台后端出现异常，被健康检查自动摘除，多数用户没有察觉。复盘时团队的看法很朴素：入口层稳不稳，取决于配置细节，和产品名字关系不大。
选型建议
如果服务走TCP或UDP，比如数据库代理、MQTT、游戏服务，四层负载均衡更直接，延迟也更低。如果要按域名、路径或请求头分流，或者做细粒度的限流和改写，就选七层方案，或者四层加七层组合。内网的高并发服务还可以考虑DR这类思路，减少回包经过调度器的开销。
小结
LVS把调度和业务拆开，阿里云负载均衡把这种思路做成了产品，省去了自己维护集群的工作。不过上线效果往往取决于健康检查、安全组、超时参数和会话策略这些细节。把这几项理清楚，再考虑扩容，入口层才经得起大流量。
