不靠谱的糖饼先说一个我实际踩过的坑。几年前给一套内部系统做高可用改造，后端应用和数据库都做了双节点，唯独最前面的入口是单台机器跑 IPVS（Linux 内核自带的 L4 负载均衡）。当时觉得 IPVS 是内核模块，转发性能强也稳定，单点就单点吧。结果有一天那台机器因为内存故障直接重启，整个入口断了快十分钟，业务方电话一个接一个。IPVS 再稳定，跑在单台机器上就一定有单点风险。
所以我后来做的方案，就是标题里这套组合：IPVS 负责四层转发，VRRP 负责 VIP 漂移，VRRP Script 负责把业务健康状况转化为优先级，三者配合，才算把“入口可用性”补齐。这篇文章不玩虚的，直接讲架构、配置、验证，以及我实际遇到的坑。适合正在用 LVS/IPVS 但又担心入口单点的朋友，也适合准备把 keepalived 从只做 VIP 漂移升级到业务感知漂移的团队。
1. IPVS单点之痛：为什么纯IPVS不够高可用
1.1 先看一眼IPVS做负载均衡的样子
IPVS 是 Linux 内核原生实现的四层负载均衡，跑在内核态，性能很高，单机轻松把几万到几十万并发连接扛下来。它本质上维护一张转发表：当你访问某个 VIP（虚拟服务地址）的端口时，内核根据调度算法（rr、wrr、lc、wlc 等）从真实服务器列表里选一台，把包按 NAT、DR、TUN 其中一种方式转过去。
典型结构是这样的：
text复制客户端
|
| 访问 VIP: 192.168.1.100:80
v
+-----------------+ IPVS 表 +-----------------+
| LB-01 | --------> | RS-01 (业务) |
| 内核 ip_vs | +-----------------+
+-----------------+ +-----------------+
| RS-02 (业务) |
+-----------------+
这套东西做“可用”很容易，但离“高可用”差得远。问题不在转发性能，而在宿主机的单点风险：机器重启、内核崩溃、网卡损坏、机房断电，任何一个发生，VIP 就没人应答了。更麻烦的是，后端业务节点越多、链路上依赖越复杂，没人愿意因为入口单点毁掉整条链路。
1.2 高可用要解决的三个问题
把 IP