LVS四层负载均衡及概念
核心概念辨析
区分三个关键又容易混淆的概念：
集群：多台服务器做同样的事（如多条相同的流水线），对外像一个整体，目的是实现高可用和负载均衡。
分布式：多台服务器做一件事的不同步骤（如一条流水线上的不同工序），合起来才是一套完整业务。
负载均衡：是集群中的一种任务分配机制，把用户请求分摊到多台功能相同的服务器上。
传统架构的缺陷与演进
传统单服务器模式的三大痛点：单点故障、性能瓶颈和处理耗时。为了解决这些问题，架构逐步演进：
简单高可用：部署备份服务器，但资源利用率低。
DNS轮询：利用DNS将域名解析到多个IP，实现简单负载均衡。但存在无法健康检查、分配不均、修改生效慢等致命缺点。
多机集群模式：通过专业的负载均衡器（如LVS）加上备用机，实现了真正的高可用和可扩容，解决了DNS轮询的诸多问题。
三大集群类型
类型 | 全称 | 核心目标 | 典型场景 | 代表技术 |
|---|
LB | Load Balancing（负载均衡集群） | 将请求分发到多台服务器，提升并发处理能力 | Web 服务器集群、API 网关 | LVS、HAProxy、Nginx |
HA | High Availability（高可用集群） | 通过冗余消除单点故障，保证服务持续可用 | 数据库主从、防火墙双机热备 | Keepalived、Pacemaker、Corosync |
HPC | High Performance Computing（高性能计算集群） | 将计算任务并行拆分到多节点，追求极致算力 | 气象模拟、基因分析、AI 训练 | MPI、Slurm、Kubernetes（批处理） |
为什么要用集群？
需求 | 单机瓶颈 | 集群方案 |
|---|
高并发 | 单机 CPU/内存/带宽有上限 | 负载均衡将请求分散到多台服务器 |
高可用 | 单机宕机 = 服务中断 | 冗余节点 + 故障自动切换 |
可扩展 | 换更贵的机器成本高且仍有上限 | 随时增加节点，线性扩展 |
可维护 | 升级/维护需要停机 | 滚动发布，逐个节点下线维护 |
三种主流负载均衡软件对比
重点对比LVS、Nginx和HAProxy，并给出了选型建议：
软件 | 工作层级 | 核心优势 | 主要局限 | 典型适用场景 |
|---|
LVS | 四层（传输层） | 性能极高、稳定、抗负载能力强，无流量产生。 | 不支持正则表达式，不能做动静分离；配置相对复杂。 | 大型网站、关键业务，服务器数量多，对性能要求极高的场景（如数据库集群）。 |
Nginx | 七层（应用层） | 配置简单灵活、支持高并发、可做动静分离、支持多种负载均衡算法（如轮询、权重、IP哈希）。 | 仅支持HTTP/HTTPS/Email协议；健康检查仅支持端口检测。 | 中小型Web应用（日PV千万级以下），作为Web前端反向代理和负载均衡器。 |
HAProxy | 四层/七层 | 支持TCP和HTTP协议，可以补充Nginx的不足（如支持会话保持、基于URL的健康检查）。 | 文中提到其多进程模式不够好，且不支持某些邮件协议。 | 需要四层负载均衡（如MySQL读写分离），或需要更全面健康检查的场合。 |
总结与推荐架构
最后给出了一个流行的架构方案：
LVS四层负载均衡
它是什么？（定位）
地址角色（记4个IP）
角色 | 名称 | 说明 |
|---|
VIP | 虚拟IP | 集群对外的统一入口，客户端访问的就是这个IP。 |
DIP | 调度器IP | LVS机器上用于与后端服务器通信的IP。 |
RIP | 真实服务器IP | 后端真正处理业务的服务器的IP。 |
CIP | 客户端IP | 客户端的源IP。 |
四种工作模式（核心区别：响应数据包是否经过LVS）
模式 | 请求如何转发 | 响应如何返回 | 核心约束 |
|---|
NAT | LVS修改目标IP（VIP→RIP），转发给RS。 | 响应必须回到LVS，LVS修改源IP（RIP→VIP）再发给客户端。 | RS的网关必须指向LVS；请求和响应都走LVS，压力大。 |
DR（最常用） | LVS修改目标MAC地址，通过交换机转发给RS（IP地址不变，仍是VIP）。 | RS直接响应客户端，不经过LVS。 | RS必须在同一网段，且需要配置VIP（但不响应ARP请求）。 |
TUN | LVS把原始请求封装在一个新的IP包中，通过IP隧道发给RS。 | RS直接响应客户端，不经过LVS。 | LVS和RS可以不在同一网段（跨机房），但封装有性能开销。 |
FULL-NAT | LVS同时修改源IP（CIP→DIP）和目标IP（VIP→RIP）。 | 响应必须回到LVS，LVS做反向转换后发回客户端。 | 部署最灵活，RS无需特殊配置，但性能开销最大。LVS原生不支持，需打补丁。 |
一句话选型：没特殊需求就选DR，性能最好；跨网段选TUN；网络受限选FULL-NAT；旧系统改造选NAT。
四种模式全景对比
对比维度 | NAT | DR | TUN | FULLNAT |
|---|
转发机制 | 修改目标 IP（DNAT） | 修改目标 MAC | IP 隧道封装 | 修改源 IP + 目标 IP |
入站路径 | Client → DS → RS | Client → DS → RS | Client → DS → RS | Client → DS → RS |
出站路径 | RS → DS → Client | RS → Client（直连） | RS → Client（直连） | RS → DS → Client |
Director 瓶颈 | 高（双向流量） | 极低（单向入站） | 极低（单向入站） | 高（双向流量） |
RS 网关要求 | 必须指向 DIP | 无特殊要求 | 无特殊要求 | 无特殊要求 |
同网段要求 | 不需要（但 RS 网关指向 DS） | 必须同物理网段 | 不需要，可跨地域 | 不需要 |
端口映射 | 支持 | 不支持 | 不支持 | 支持 |
RS 额外配置 | 仅设网关 | 配置 lo:VIP + ARP 抑制 | 配置 tunl0:VIP | 需要内核补丁 |
RS 操作系统 | 任意 | 任意（需能配 lo:VIP） | 支持 IP 隧道 | Linux（需补丁） |
性能排名 | 第 3 | 第 1（最高） | 第 2 | 第 4 |
生产使用率 | 低 | 最高（90%+） | 低 | 低（阿里内部用） |
适用场景 | 小规模、需要端口映射 | 大规模高性能 Web 集群 | 跨地域/跨机房 | 需跨网段但不想改 RS 网关 |
调度算法（请求分给谁）
类型 | 算法 | 逻辑 |
|---|
静态（不看负载） | RR（轮询） | 按顺序轮流分配，不考虑服务器当前负载。 |
| WRR（加权轮询） | 按权重比例分配，权重高的多分。 |
| SH（源地址哈希） | 同一客户端IP固定分配给同一台RS，用于会话保持。 |
动态（看负载） | LC（最小连接） | 选当前活动连接数最少的RS。 |
| WLC（加权最小连接） | 用“连接数/权重”计算，选比值最小的RS。生产环境最常用。 |
简单结论：服务器配置一致用RR；配置不同用WRR；长连接业务优先WLC。
高可用：LVS + Keepalived
LVS本身有两个缺陷：
不会检查RS是否存活 —— 如果RS宕机，LVS仍会往它转发请求。
LVS自己是单点 —— 如果LVS机器宕机，整个集群不可用。
解决方案：引入 Keepalived。
LVS的边界（它做不了什么）
因为LVS只工作在四层，所以它不具备七层能力：
不能根据 URL路径 分发（比如 /api 去A，/static 去B）。
不能根据 域名 分发（比如 a.com 去A，b.com 去B）。
不能读写HTTP头（如Cookie、Header）。
这些七层功能由 Nginx / HAProxy 实现。典型的架构是：
LVS（四层）→ Nginx（七层）→ 应用服务器
生产环境快速选型表
场景 | 推荐方案 |
|---|
大多数Web/TCP业务 | DR模式 + WLC算法 + Keepalived |
后端服务器性能不一致 | 使用WRR或WLC |
需要会话保持 | 使用SH算法，或在LVS配置中开启持久连接 |
跨机房/跨网段部署 | 使用TUN模式 |
网络环境复杂，RS不便改动网关 | 使用FULL-NAT模式 |
详细对比表
对比维度 | LVS | HAProxy | Nginx |
|---|
工作层次 | 四层（传输层） | 四层 + 七层 | 七层为主，四层较弱 |
工作模型 | 内核态（ipvs 模块） | 用户态（单进程事件驱动） | 用户态（多进程事件驱动） |
性能 | 最高（内核级转发，几乎无损耗） | 高（C 语言编写，事件驱动） | 高（但略低于 HAProxy 纯四层场景） |
并发连接 | 百万级 | 数十万级 | 数万~数十万级 |
调度算法 | 10 种 | 10+ 种 | 5 种（least_conn/ip_hash 等） |
健康检查 | 弱（需配合 Keepalived） | 强（内置丰富的健康检查） | 中（被动检查为主） |
Session 保持 | 支持（持久性转发） | 支持（Cookie/Sticky Table） | 支持（ip_hash/sticky） |
SSL 终端 | 不支持 | 支持 | 支持（最常用用途之一） |
URL 路由 | 不支持 | 支持 | 支持（最常用用途之一） |
动静分离 | 不支持 | 支持 | 支持（经典用法） |
Web 服务器 | 不能 | 不能 | 可以（静态文件/反向代理） |
热重载 | 规则即时生效 | 支持（reload 无明显中断） | 支持（reload 有短暂中断） |
配置复杂度 | 低（ipvsadm 命令） | 中 | 低（语法接近自然语言） |
运维难度 | 中（需理解网络层） | 中 | 低（资料最丰富） |
适用场景 | 大规模高性能四层入口 | 中大型四/七层通用负载均衡 | Web 应用、API 网关、反向代理 |
常用缩写术语
在本系列教程中，以下缩写会频繁出现，请务必掌握：
缩写 | 全称 | 中文解释 | 角色说明 |
|---|
LB | Load Balancer | 负载均衡器 | 负责接收客户端请求并分发给后端服务器 |
HA | High Availability | 高可用 | 保证服务持续运行的架构设计理念 |
DS | Director Server | 调度器 / 负载均衡器 | LVS 术语，等同于 LB，运行 ipvs 的节点 |
RS | Real Server | 真实服务器 / 后端服务器 | 真正处理客户端请求的服务器 |
VIP | Virtual IP | 虚拟 IP 地址 | 对外暴露的服务地址，客户端访问的就是 VIP |
DIP | Director IP | 调度器 IP 地址 | DS 用于与 RS 通信的 IP |
CIP | Client IP | 客户端 IP 地址 | 发起请求的客户端 IP |
RIP | Real Server IP | 真实服务器 IP | RS 自身的 IP 地址 |
SPOF | Single Point of Failure | 单点故障 | 系统中一旦故障就导致整体不可用的组件 |
VRRP | Virtual Router Redundancy Protocol | 虚拟路由冗余协议 | Keepalived 使用的 HA 协议，实现 IP 漂移 |
ARP | Address Resolution Protocol | 地址解析协议 | 将 IP 地址解析为 MAC 地址 |
SSL/TLS | Secure Sockets Layer / Transport Layer Security | 安全套接层/传输层安全 | 加密通信协议 |
快速参考表
问题 | 答案要点 |
|---|
集群有哪三类？ | LB（负载均衡）、HA（高可用）、HPC（高性能计算） |
四层和七层负载均衡的核心区别？ | 四层看 IP+Port，七层看 URL/Cookie/Header |
LVS 的定位？ | 高性能四层负载均衡，内核级转发，需配合 Keepalived 做 HA |
HAProxy 的定位？ | 四层 + 七层通用负载均衡，性能与功能兼顾 |
Nginx 的定位？ | 七层为主，Web 服务 + 反向代理 + 负载均衡 |
什么是 SPOF？ | 单点故障，系统中一旦故障就导致整体不可用的组件 |
如何消除 SPOF？ | 冗余设计 + 故障转移（Failover） |
VIP 是什么？ | 虚拟 IP，对外暴露的服务地址，可以在节点间漂移 |
VRRP 是什么？ | 虚拟路由冗余协议，Keepalived 实现 HA 的基础协议 |
本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
评论交流
欢迎留下你的想法