Keepalived 不直接集成 Java 应用，而是通过 HTTP 健康检查（如 /actuator/health）感知其真实状态，结合优雅启停、双机热备部署及出口网关特殊设计实现高可用。
Keepalived 本身不直接与 Java 应用交互，它工作在操作系统网络层（L3/L4），负责 VIP（虚拟 IP）漂移和健康检查。要让 Java 应用成为高可用出口网关，关键不是“集成 Keepalived”，而是让 Keepalived 能准确感知 Java 网关服务的存活状态，并在其故障时及时触发 VIP 切换。实际落地中，核心在于设计合理的健康检查机制和部署协同模式。
Keepalived 健康检查必须对接 Java 网关的真实状态
默认的 TCP 端口探测（如 check_tcp）只能判断端口是否监听，无法反映 Java 应用内部是否就绪（例如 Spring Boot 启动未完成、连接池未初始化、依赖服务不可达等）。必须使用 HTTP 或自定义脚本检查：
- 推荐暴露 /actuator/health（Spring Boot Actuator）或自定义 /healthz 接口，返回 200 且 body 包含
{"status":"UP"}； - Keepalived 配置中启用
http_get检查，设置url、status_code和超时参数； - 避免仅依赖进程存在或端口通断——Java 应用可能卡在 GC、死锁或线程阻塞，仍能响应 TCP SYN，但无法处理请求。
Java 网关需支持优雅启停与就绪探针联动
Keepalived 的健康检查结果必须与应用生命周期严格对齐：
- 启动时：应用完成全部初始化（数据库连接、配置加载、路由注册）后再开放健康检查接口返回 UP；
- 关闭时：收到 SIGTERM 后先关闭监听端口、拒绝新连接，等待活跃请求完成（如 Netty 的
closeAsync()或 Tomcat 的awaitTermination()），再退出进程； - 若使用 Kubernetes，可将 readinessProbe 指向同一 /healthz 接口，实现容器编排层与 Keepalived 检查逻辑统一。
双机热备部署结构需规避单点风险
典型主备模式下，Keepalived + Java 网关应部署为独立节点对（非共用物理机或宿主机）：
立即学习“Java免费学习笔记（深入）”；
- 两台服务器分别部署 Keepalived + Java 网关实例，VIP 绑定在主节点网卡；
- Keepalived 使用 vrrp_script 定期调用本地 Java 应用的健康接口，根据返回码决定权重（如检测失败则 weight -10）；
- 禁用抢占模式（
nopreempt）或合理设置 priority 差值，防止脑裂或频繁切换； - 确保两节点时间同步（chrony/NTP）、防火墙放行 VRRP 组播（224.0.0.18）及健康检查端口。
出口网关场景下的特殊考量
作为出口网关，还需关注连接保持、会话一致性与上游感知：
- Keepalived 不做负载均衡，仅提供 VIP 故障转移；若需多活，应前置 LVS 或用 DNS 轮询 + 应用层熔断；
- Java 网关自身需实现连接池复用、HTTP/HTTPS 代理超时控制、后端服务健康快照缓存，避免 Keepalived 切换后瞬间流量冲击；
- 下游系统应配置重试机制（如指数退避）和超时时间 > Keepalived failover 时间（通常 3–6 秒），避免因切换期间短暂不可用引发级联失败。
不复杂但容易忽略。Keepalived 是“守门人”，Java 网关才是“把关人”——前者只管门开没开，后者得确保开门后真能办事。
