大部分 Web 业务直接选 Nginx 就够了，只有遇到超大流量入口或纯 TCP/UDP 服务（如数据库、游戏网关）时，才需要考虑 LVS。

快速处理思路

选型不是做实验，先看业务特征再定方案，避免过度设计：

1. 看协议：如果是 HTTP/HTTPS 业务，Nginx 是首选；如果是 MySQL、Redis、游戏 TCP 包，LVS 更合适。
2. 看流量：公开资料中常见评估范围为 Nginx 单机数万 QPS，LVS 可达十万级以上，若业务量级未达瓶颈，勿盲目上 LVS。
3. 看功能：需要基于 Cookie、URL 路径分发流量，必须用 Nginx；仅需 IP+ 端口转发，LVS 性能更优。

核心区别

核心区别在于工作层级不同，导致处理效率和功能灵活性有差异：

• LVS（四层）：工作在内核态，基于 IP 和端口转发数据包，不解析应用层内容。就像高速交警只查车牌不查车厢，效率极高但无法做业务逻辑判断。
• Nginx（七层）：工作在用户态，解析 HTTP 协议内容。就像前台接待员，看完信件内容再决定分给谁，功能丰富但消耗更多 CPU 资源。

在高性能场景下，LVS 的优势在于内核转发带来的低延迟和高并发承载能力；Nginx 的优势在于能处理 SSL 卸载、跨域、缓存等应用层需求，减少后端压力。

分步处理与配置

按以下步骤评估并落地，确保选型符合实际：

1. 评估业务协议：
   确认服务是 TCP/UDP 还是 HTTP。若是数据库或中间件集群，直接倾向 LVS；若是 Web 服务，倾向 Nginx。
2. 规划高可用架构：
   LVS 内核模块本身无健康检查功能，必须搭配 Keepalived 实现 VIP 漂移及后端健康检查。Nginx 开源版仅支持被动健康检查（通过 max_fails 参数），主动检查需配合第三方模块（如 lua-resty-upstream-healthcheck）或商业版，建议同样配置 Keepalived 防单点故障。
3. 配置网络模式（若选 LVS）：
   生产环境常用 DR 模式。需在真实服务器上配置 VIP 并抑制 ARP 响应，避免地址冲突。
   临时生效：
   

   echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
   echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

   持久化配置（推荐）：
   编辑 /etc/sysctl.conf 添加以下内容，防止重启失效：
   

   net.ipv4.conf.all.arp_ignore = 1
   net.ipv4.conf.all.arp_announce = 2

   执行 sysctl -p 生效。
4. 配置负载均衡规则：
   LVS 配置示例（ipvsadm）：
   

   # 添加虚拟服务
   ipvsadm -A -t 192.168.1.100:80 -s rr
   # 添加真实服务（DR 模式用 -g）
   ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.101:80 -g
   ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.102:80 -g
   # 保存规则（根据发行版不同，可能是 ipvsadm-save）
   ipvsadm-save > /etc/sysconfig/ipvsadm

   Nginx 配置示例（upstream）：
   

   upstream backend {
       server 192.168.1.101:80 max_fails=3 fail_timeout=30s;
       server 192.168.1.102:80 max_fails=3 fail_timeout=30s;
   }
   server {
       listen 80;
       location / {
           proxy_pass http://backend;
       }
   }

   确保权重设置合理，避免单台后端过载。

怎么验证是否生效

部署后不要只看状态，要通过流量验证：

• 连接测试：使用 curl 或 telnet 访问 VIP，确认能通且返回正确内容。
• 状态查看：
  LVS 使用 ipvsadm -ln 查看连接计数分布。
  Nginx 查看 access.log 确认请求被分发到不同后端 IP。
• 会话保持：若配置了 IP 哈希或 Cookie 保持，多次请求应落到同一后端（可通过后端日志查看来源 IP）。
• 故障切换：手动停止一台后端服务，观察负载均衡器是否自动剔除该节点，业务是否无感知。对于 LVS，需确认 Keepalived 脚本是否正确剔除节点。
• 压力测试：使用工具模拟并发，监控负载均衡器 CPU 和网络带宽，确认未达到瓶颈。

常见坑

以下是生产环境中容易踩的雷，提前规避：

• LVS 的 ARP 问题：DR 模式下，若真实服务器未抑制 ARP，会导致 VIP 地址冲突，流量无法回包。务必确认 /etc/sysctl.conf 配置已生效。
• 健康检查缺失：LVS 本身无健康检查功能，需依赖 Keepalived 或外部脚本。若后端服务进程假死但端口通，流量仍会转发过去，需配合脚本或使用 Keepalived 高级检查。
• Nginx 被动检查局限：开源版 Nginx 的 max_fails 是被动检查，只有请求失败才标记不可用。若需要主动探测，需引入 lua 模块或升级商业版。
• SSL 性能损耗：若在 Nginx 上终止 HTTPS，CPU 消耗会显著增加，高并发下可能成为瓶颈，需评估是否卸载到专用设备或改用 HTTP 内部通信。
• 日志记录：LVS 默认不记录访问日志，排查问题困难，建议在真实服务器上记录完整访问日志。

参考来源

• Nginx Official Documentation - Module ngx_http_upstream_module
• Linux Virtual Server Project - Documentation
• Keepalived Official Documentation - Load Balancing Infrastructure