在分布式系统高可用架构中，VIP（虚拟 IP）漂移技术是流量入口的“保险丝”。Keepalived 作为开源界最成熟的 VRRP 实现，支撑了无数企业的核心业务。但在全云原生时代，Keepalived 是否还有价值？本文从协议原理、云环境适配、替代方案对比三个维度深度剖析。
一、VRRP 协议深度解析
VRRP (Virtual Router Redundancy Protocol) 的核心思想是“虚拟路由器”。多个物理节点组成一个虚拟路由器，共享一个 VIP。主节点（Master）定期发送通告（Advertisement），备节点（Backup）监听。一旦超时（通常 3 秒），备节点即抢占 VIP。
关键机制：
– 优先级选举： 数值越大优先级越高。
– 抢占模式 vs 非抢占模式： 生产环境建议使用非抢占模式，避免网络抖动导致 VIP 频繁漂移（“乒乓效应”）。
二、云环境下的挑战与适配
在 AWS、阿里云等公有云上， Keepalived 面临两大挑战：
- 组播限制： 大部分云厂商禁止 VRRP 依赖的组播流量（224.0.0.18），导致心跳无法传输。
- 浮动 IP 管控： 云厂商的 EIP/VIP 是控制台层面的概念，无法通过 Linux 命令直接绑定。
解决方案：
– 单播模式： Keepalived 2.0+ 支持单播 VRRP，可绕过组播限制。
– 云 API 集成： 编写通知脚本，在状态切换时调用云厂商 API 解绑/绑定 EIP。例如：notify_master 脚本中执行 `aliyun ecs ModifyInstanceNetworkAttribute`。
三、真实案例：某金融交易系统的高可用演进
阶段一（传统 IDC）： 使用 Keepalived + HAProxy，双机热备。稳定性高，但扩展性差，主节点瓶颈明显。
阶段二（混合云）： 迁移部分业务上云，遇到组播问题。改为 Keepalived 单播模式 + 云 API 脚本，解决了 VIP 漂移问题。
阶段三（云原生）： 核心交易链路容器化，使用 K8s Service + LoadBalancer 替代 Keepalived。但数据库层仍保留 Keepalived 做主从切换代理。
经验总结： 应用层可用 K8s 替代，但底层基础设施（DB, Cache）的高可用，Keepalived 依然是性价比最高的方案。
四、替代方案对比
| 方案 | Keepalived | Consul + Habitat | Cloud LB (ALB/NLB) | K8s Service |
|---|---|---|---|---|
| 切换时间 | 1-3 秒 | 5-10 秒 | 30-60 秒 | 秒级 |
| 成本 | 零 (自建) | 中 (运维复杂) | 高 (按量付费) | 中 (集群成本) |
| 云适配 | 需改造 | 原生支持 | 原生支持 | 原生支持 |
| 适用场景 | 机房/混合云 | 多活/Service Mesh | 全云原生 | K8s 内部 |
五、未来展望：SDN 与 eBPF
随着 SDN（软件定义网络）和 eBPF 技术的成熟，传统的 VRRP 协议可能逐渐被取代。例如，Cilium 利用 eBPF 实现了无需 VIP 的负载均衡，直接在 IP 层进行数据包重定向。但在未来 3-5 年内，Keepalived 凭借其简单、可靠、低成本的特性，仍将在混合云和传统 IDC 中占据重要地位。
总结
Keepalived 不是过时的技术，而是需要与时俱进。在云原生时代，通过单播改造和 API 集成，它依然能发挥关键作用。架构师应根据业务场景，灵活选择“传统 VIP”或“云原生 LB”。
更多高可用架构思考：https://mjj.728.hk/