LVS 负载均衡的原理与演进
工作原理概述
在 Linux 生态中，LVS（Linux Virtual Server）通过内核实现的 IPVS 子系统承担边缘的流量转发工作，属于L4 级负载均衡。它将外部请求通过一个虚拟服务器 VIP转发到后端真实服务器，核心在于在内核态完成包的分发，极大降低了上下游的额外开销并提升吞吐量。
IPVS支持多种调度算法，例如 rr（轮询）、wrr（加权轮询）、lc（最少连接） 等，开发者可以根据后端服务的特性选择合适的策略来实现流量分发公平性与性能平衡。通过选择不同的调度器，后端服务器的权重与健康状态会直接影响流量走向。
此外，LVS 支持三种工作模式：LVS NAT、LVS NAT/DR 混合、以及 LVS DR（直接路由），每种模式在数据包转发路径、网络设备压力和实现复杂度上各有取舍。理解这三种模式的差异，是实现高性能负载均衡的关键所在。
架构组件与流量分发路径
在典型的 LVS 架构中，VIP 放在负载均衡节点上，客户端请求首先到达 VIP，对应的虚拟服务再将流量分发给后端的真实服务器。真实服务器集合承载具体的应用服务，VIP 与后端服务器之间的连接通过不同的转发模式完成。
流量路径通常呈现为：客户端 -> VIP（在前端负载均衡节点） -> IPVS（内核态转发） -> 实例服务器。为确保高可用，往往会通过 keepalived 进行 VRRP VIP 的失效转移，使 VIP 即使在某台节点故障时也能切换到其他节点继续对外提供服务。
从性能角度看，LVS 的内核态实现在超高并发场景下具备极低的上下文切换开销和稳定的吞吐量，特别是在静态 TCP/HTTPS 负载以及大量连接保持时，优势明显。但在内容感知、智能路由或复杂的 HTTP 层功能方面，LVS 的能力有限，这也是为什么很多场景会沿用或迁移到像 HAProxy 这样的 L7 负载均衡器。
关键优势与局限
高吞吐、低延迟、内核级转发是 LVS 的核心优势之一，适合对性能和并发有极高要求的场景。通过 IPVS 的调度算法，管理员可以灵活控制流量分发策略，以实现对服务的均衡与可预测性。
另一方面，高可用性配置需要额外组件（如 keepalived）来实现 VIP 的故障转移，否则单点故障会导致不可用。健康检查、日志与监控等运维能力也需要额外的方案支持，以确保故障在最短时间被发现和处理。
最后，LVS 虽然在 L4 层具备出色的效率，但在处理 http 层的特性路由、应用层会话保持和更复杂的协议特性方面显得力不从心，这也是部分场景最终选择 HAProxy 的原因之一。
LVS 的部署与核心配置
环境准备与内核模块加载
部署 LVS 的第一步是确认内核具备 IPVS 模块，并且将网络转发打开以实现数据包的跳转。需要在负载均衡节点执行 modprobe 命令加载相关模块，并通过 sysctl 开启 IP 转发。
通过以下步骤可以确保基础环境就绪：加载 IPVS 模块、开启 IP 转发、并确保系统网络参数稳定配置，以避免后续的转发异常。
在生产环境中，还应对内核参数做持续监控，以应对长时间高并发情况下对连接追踪与资源分配的影响，确保不会因为资源瓶颈导致转发异常。
IPVS 配置与 ipvsadm 使用
在 LVS 中，ipvsadm 是核心的管理工具，用于创建虚拟服务器、定义前端端口与后端真实服务器，以及选择合适的 调度算法。常见的配置步骤包括创建虚拟服务器、添加真实服务器、以及查看当前状态。
通过 ipvsadm 可以实现对后端的动态加减、权重调整与健康检查的初步配置，从而实现高效的流量调度。掌握 ipvsadm 的命令模式，是实现稳定 LVS 部署的基础。以下给出一个简化的示例来展示核心操作。
# 加载模块
modprobe ip_vs
modprobe ip_vs_rr# 启用转发
sysctl -w net.ipv4.ip_forward=1# 设置虚拟服务器，轮询调度
ipvsadm -A -t 192.168.10.100:80 -s rr
ipvsadm -a -t 192.168.10.100:80 -r 192.168.10.101:80 -g
ipvsadm -a -t 192.168.10.100:80 -r 192.168.10.102:80 -g# 查看当前 LVS 配置
ipvsadm -Ln --details
使用 keepalived 实现高可用 VIP
为确保 VIP 的高可用，keepalived 提供了 VRRP 的实现，使多台节点之间能够在 VIP 层进行快速切换。配置中需要设定 VRID、优先级、认证方式以及要绑定的 VIP 地址。
通过 keepalived 的配置，可以实现节点故障自动切换，将 VIP 重新指向存活节点，从而确保外部请求的连续性。测试时应重点验证在主节点宕机后，VIP 是否能够无缝切换并重新指向备节点。
vrrp_instance VI_1 {state MASTERinterface eth0virtual_router_id 51priority 100advert_int 1authentication {auth_type PASSauth_pass 1111}virtual_ipaddress {192.168.10.100}
}
从 LVS 到 HAProxy 的迁移路线与要点
迁移策略与路线图
在逐步将业务从 LVS 迁移到 HAProxy 的过程中，可以采用两种典型策略：一是前端仍然保留 LVS 的 VIP，通过 HAProxy 作为应用层负载均衡进行反向代理，二是在保持 VIP 的前提下，将后端的转发逻辑逐步切换到 HAProxy。无论选择哪种方案，核心目标是实现最小化停机时间和平滑切换。
实施时应先在测试环境验证迁移路径的正确性，确保健康检查、会话保持、日志统计等关键能力保持一致或得到提升。为避免配置冲突，尽量实现一个阶段性的替换计划，避免一次性替换造成的风险。
在实际落地中，建议先进行 TCP 层面的迁移，逐步扩展到 HTTP 层的复杂路由，以保证在不同协议栈下的性能与稳定性。通过阶段性部署，可以实现滚动替换、灰度切换，降低业务波动。
HAProxy 的核心配置要点
HAProxy 以 frontend 和 backend 的组合来完成 L7 负载均衡，支持丰富的健康检查、会话保持策略以及灵活的路由规则。核心要点包括对两端节点的健康检查、后端服务器的权重定义，以及对应用层的智能路由能力。
在生产中，常用的配置包括：全局日志、默认超时、前端监听端口、后端服务器组、健康检查策略、以及日志/监控配置。合理的超时设置、错误恢复策略和健康检查间隔，是确保高可用的关键。
需要注意的是，HAProxy 的性能也会受制于服务器 CPU 与网络带宽，因此需要对后端应用的健康检查、连接池和并发连接进行合适的调优，以实现稳定高效的处理能力。
globallog 127.0.0.1 local0maxconn 10000daemondefaultsmode httptimeout connect 5stimeout client 50stimeout server 50sfrontend http_inbind *:80default_backend app_serversbackend app_serversbalance roundrobinserver app1 192.168.20.101:80 checkserver app2 192.168.20.102:80 check
数据平滑切换要点
迁移过程中的平滑切换可以通过运行时接口实现，例如对单个后端进行禁用、置为 drain、确保现有连接完成后再切换。这种方式有助于实现零停机的迁移策略，并尽量避免丢失正在处理的连接。
通过 HAProxy 的运行时接口，可以实现对后端服务器的动态控制，例如将某个服务器置为 drain 状态，确保新连接不再分发给该服务器，同时继续处理其现有连接。这样可以实现无缝的容量扩展或替换。
# 使用运行时 API 禁用后端
printf "disable server app1\n" | socat stdio /var/run/haproxy.sock
监控与日志
为确保 HAProxy 的可观测性，需要开启统计页面或推送指标，以便运维人员实时查看请求速率、并发连接、后端健康状态等关键指标。良好的监控能力可以帮助提早发现瓶颈并进行容量扩展。
常见做法包括在配置中添加 stats 页面、集中式日志、以及对系统指标的采集。高效的监控不仅提升可用性，也有助于进行性能调优与容量规划。
listen statsbind *:8080stats enablestats uri /haproxy_stats
实战要点与性能调优
监控指标与告警
在实际运行中，应该对 吞吐量、并发连接、后端健康状态、错误率 等关键指标进行持续监控。使用系统层工具（如 top、vmstat、iostat、sar）结合应用层指标，能够快速定位性能瓶颈。
对 LVS 与 HAProxy 的对比分析也应纳入常规运维工作，尤其关注 CPU 使用率、网络吞吐、连接建立率 与后端响应时间。合理的告警阈值有助于在问题初期就发出预警，避免影响到业务体验。
日志级别的设定也要平衡信息量与存储成本，确保在需要时能快速回溯；同时，导出可观测性数据以支撑容量规划与容量扩展决策。
会话保持与健康检查的最佳实践
为实现稳定的用户体验，需在前端代理层配置合适的会话保持策略。在 LVS 场景中，可以通过 IP 哈希、源地址亲和性或特定的会话持久化策略实现；在 HAProxy 场景中，推荐使用 基于 Cookie 的会话保持，以便跨后端服务器维持会话的一致性。
健康检查是确保后端健康的重要手段。对 LVS，通常配置 健康检查脚本和端口探测，对 HAProxy，可通过内置的健康检查或自定义脚本实现对应用层的更深度检查。通过健康状态的及时更新，可以实现更高的故障域的隔离。
此外，对于 SSL/TLS、连接复用、以及慢连接等问题，需在健康检查与超时策略上进行细化，以避免将劣化的后端错误地纳入流量池。
#!/bin/bash
# 简单的后端健康检查脚本示例
curl -sfS http://127.0.0.1:80/health || exit 1
排查常见问题与故障排除
在实际运维中，常见问题包括 VIP 无法访问、后端节点收敛慢、日志不全 等。此时需要先确认前端 VIP 的网络连通性、ARP/路由策略，以及防火墙和 NAT 相关的配置是否正确。
对于 LVS 的 ARP 问题，可通过设置 arp_announce 与 arp_ignore 等系统参数进行调优，避免 ARP 风险导致 VIP 泄露或冲突。排查时应重点检查内核参数、iptables 规则以及转发策略。
在 HAProxy 层，若遇到连接耗时或错误码增多，应分析后端健康检查结果、后端瓶颈、以及运行时资源使用情况，结合日志定位问题并进行容量扩展或路由优化。
