在当今互联网时代，随着流量规模的指数级增长，单台服务器往往难以承受巨大的并发请求。LVS负载均衡介绍成为了系统架构师和运维工程师必须掌握的核心技能之一。LVS（Linux Virtual Server）是由章文嵩博士发起的开源项目，它利用Linux操作系统和IPVS模块，构建了一个高性能、高可用的服务器集群系统。
与Nginx、HAProxy等七层负载均衡不同，LVS工作在传输层（四层），这意味着它不解析HTTP协议，而是直接基于IP和端口进行流量分发。这种底层级的处理机制赋予了LVS极高的吞吐量和极低的延迟，使其能够轻松应对每秒百万级的连接请求。
LVS的核心代码运行在Linux内核空间，避免了用户态与内核态之间的上下文切换开销，从而实现了接近线速的数据包转发能力。
经过阿里、腾讯、百度等大厂多年生产环境的验证，LVS集群架构能够7x24小时不间断运行，是金融、电信级应用的首选。
支持RR（轮询）、WRR（加权轮询）、LC（最少连接）、WLC（加权最少连接）等多种算法，可根据业务特性灵活配置。
在LVS负载均衡介绍中，理解其三种主要工作模式（NAT、DR、TUN）是至关重要的。每种模式都有其适用的场景和局限性，正确选择模式直接决定了集群的性能和架构复杂度。
NAT模式类似于网络地址转换，是LVS最简单的一种模式。客户端请求首先到达Director Server（调度器），调度器修改数据包的Destination IP（目标IP）为Real Server（真实服务器）的IP，并将请求转发过去。Real Server处理完响应后，将数据包发回给Director Server，Director Server再将Source IP修改为VIP（虚拟IP）发回给客户端。
# 启用IP转发
echo 1 > /proc/sys/net/ipv4/ip_forward
添加DNAT规则
ipvsadm -A -t 192.168.1.100:80 -s wrr
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.101:80 -m -w 1DR模式（直接路由）是目前生产环境中最常用的模式。其原理是：客户端请求到达Director Server后，调度器不修改目标IP，而是直接修改数据帧的MAC地址为Real Server的MAC地址，然后将数据帧在局域网内广播出去。Real Server收到后，发现目标IP是自己的VIP，于是直接处理。处理完成后，Real Server直接将响应发回给客户端，而不经过Director Server。
# 在Real Server上配置VIP
ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 broadcast 192.168.1.100 up
抑制ARP
echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce
echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore
echo "2" > /proc/sys/net/ipv4/conf/all/arp_announceTUN模式通过在原始IP数据包之外封装一个新的IP头，将请求隧道传输到Real Server。Real Server解包后处理请求，并直接将响应发回给客户端。与DR模式类似，响应也不经过调度器。
单台LVS调度器存在单点故障风险。为了解决这个问题，业界标准做法是采用LVS+Keepalived架构。Keepalived通过VRRP（虚拟路由器冗余协议）实现双机热备，当主调度器（Master）故障时，从调度器（Backup）能在毫秒级时间内接管VIP，确保业务不中断。
| 组件 | 角色 | IP地址 | 说明 |
|---|---|---|---|
| Client | 客户端 | 任意 | 发起HTTP请求 |
| LVS-Master | 主负载均衡器 | 192.168.1.10 (VIP: 192.168.1.200) | 处理流量，监控Keepalived状态 |
| LVS-Backup | 备负载均衡器 | 192.168.1.11 (VIP: 192.168.1.200) | standby状态，实时同步规则 |
| Web-Node1 | 真实服务器 | 192.168.1.101 | 部署Web服务，绑定VIP |
| Web-Node2 | 真实服务器 | 192.168.1.102 | 部署Web服务，绑定VIP |
在Keepalived配置文件中，需要定义全局参数、VRRP实例以及LVS虚拟服务器。其中，vrrp_instance负责心跳检测，virtual_server负责定义LVS的调度算法和后端服务器列表。
global_defs {
router_id LVS_DEVEL
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.1.200
}
}
virtual_server 192.168.1.200 80 {
delay_loop 6
lb_algo wlc
lb_kind DR
persistence_timeout 50
protocol TCP
real_server 192.168.1.101 80 {
weight 1
TCP_CHECK {
connect_timeout 10
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.1.102 80 {
weight 1
TCP_CHECK {
connect_timeout 10
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}在LVS负载均衡介绍的延伸讨论中，开发者常常面临选型问题。LVS、Nginx和HAProxy各有千秋，选择取决于业务的具体需求。
优势：性能最强，支持连接数极大，内核级处理，稳定性极高。
劣势：配置复杂，不支持七层URL转发，健康检查功能相对基础（需配合Keepalived或外部脚本）。
场景：超大规模流量入口，如视频网站、游戏网关。
优势：强大的反向代理功能，支持丰富的HTTP规则（Rewrite、Header修改），缓存功能强大，社区活跃。
劣势：高并发下性能略低于LVS，内存消耗较大。
场景：中小型网站，需要复杂路由规则、API网关、动静分离场景。
优势：专注负载均衡，七层功能比LVS丰富，配置简洁，监控面板友好，健康检查强大。
劣势：单进程模型，高并发下CPU利用率不如Nginx的多进程模型。
场景：对稳定性要求极高的TCP/HTTP应用，金融交易系统。
| 特性 | LVS | Nginx | HAProxy |
|---|---|---|---|
| 工作层级 | 四层（传输层） | 七层（应用层） | 四层/七层 |
| 最大连接数 | 百万级+ | 十万级 | 十万级 |
| 配置复杂度 | 高（命令行/脚本） | 中（配置文件） | 中（配置文件） |
| 健康检查 | 简单（TCP/HTTP） | 强大（HTTP/HTTPS） | 强大（TCP/HTTP/SQL等） |
| HTTP功能 | 无 | 强大（缓存/重写） | 中等（头修改/路由） |
了解LVS的历史有助于理解其设计哲学。从最初的简单轮询到如今支持复杂的持久化和健康检查，LVS经历了多次重大迭代。
章文嵩博士在Linux Kernel mailing list上发布LVS项目，最初仅支持基本的轮询调度。
IPVS（IP Virtual Server）正式成为Linux内核的一部分，标志着LVS成为Linux原生支持的负载均衡解决方案。
增加了PERSISTENT连接特性，优化了NAT模式下的性能，使其在云环境初期得到广泛应用。
LVS作为Kubernetes Service（kube-proxy iptables/ipvs模式）的底层支撑，在容器化环境中焕发新生，成为云原生负载均衡的事实标准之一。
完全可以，且这是非常经典的架构组合。通常采用 LVS (DR模式) + Nginx 的架构。LVS作为第一层负载均衡，负责将海量流量分发到后端的Nginx集群；Nginx作为第二层负载均衡，负责处理七层的HTTP请求、SSL卸载和静态资源缓存。这种架构兼顾了高性能和灵活性。
在DR模式中，Real Server直接响应客户端，响应包的源IP必须是VIP。将VIP配置在lo（本地回环）接口上，可以确保系统内核在发送响应包时，源IP是VIP。同时，通过抑制ARP（arp_ignore/arp_announce），防止Real Server响应其他主机对VIP的ARP请求，避免IP冲突，确保所有针对VIP的请求都只由Director Server响应并分发。
支持。LVS提供了-p（persistence）参数，用于实现持久连接。例如，ipvsadm -A -t 192.168.1.100:80 -s wlc -p 300表示在300秒内，来自同一客户端IP的请求将被调度到同一台Real Server。这对于需要保持用户登录状态的应用非常重要。
可以使用ipvsadm -L -n命令查看当前的虚拟服务器列表、调度算法和Real Server状态。使用ipvsadm -L --stats可以查看流量统计信息（包数、字节数）。对于更详细的实时连接监控，建议结合ss命令或Prometheus监控。
在Kubernetes中，kube-proxy组件负责服务发现和负载均衡。当配置为ipvs模式时，kube-proxy会在每个节点上通过IPVS内核模块创建规则，将Service的ClusterIP和端口映射到后端的Pod IP。这使得K8s集群内部的服务调用具有极高的性能，类似于LVS的工作方式。