nginx 与 keepalived 是企业级负载均衡的标配搭档：nginx 负责应用层精细治理（反向代理、ssl 卸载、健康检查等），keepalived 通过 vrrp 管理 vip 实现高可用入口，二者职责解耦、协同构建稳定可观测的前端架构。
企业级负载均衡中，Nginx 与 Keepalived 不是“可选组合”，而是生产环境的标配搭档——前者负责应用层流量调度与灵活转发，后者保障接入入口不中断。单靠 Nginx 无法解决单点故障；只用 Keepalived 又缺乏 HTTP 层处理能力。二者协同，才构成真正可用、可观测、可运维的高可用前端架构。
Nginx：做对请求的“精细治理”
Nginx 在集群中承担反向代理、动静分离、SSL 卸载、URL 路由、限流熔断等关键任务。它不直接暴露给用户，而是作为 Keepalived 管理的 VIP 后端服务节点存在：
- 通过 upstream 模块定义后端真实服务器池，支持轮询、加权、least_conn、hash（如 ip_hash 或 url_hash）等多种策略
- 启用 stub_status 模块，暴露 /nginx_status 接口，供 Keepalived 健康检查脚本实时抓取活跃连接数、请求速率等指标
- 配置 proxy_http_version 1.1 和 proxy_set_header Connection "Keep-Alive"，复用长连接，降低 TCP 开销
- 结合 real_ip 模块识别真实客户端 IP（尤其在多层代理场景下），确保日志与限流准确
Keepalived：守住入口的“最后防线”
Keepalived 的核心价值不是替代 Nginx，而是让 Nginx 的服务能力始终有一个稳定的对外出口——虚拟 IP（VIP）。它通过 VRRP 协议实现毫秒级故障接管：
- 主节点（MASTER）绑定 VIP 并持续广播心跳；备节点（BACKUP）静默监听，不响应 ARP 请求，避免冲突
- 心跳检测默认基于 UDP 多播，但生产环境建议配合自定义脚本（如检测 Nginx 进程存活 + 端口通 + HTTP 健康接口返回码）提升判断精度
- 权重（priority）决定主备选举逻辑，网络延迟或资源过载时可通过脚本动态降权，触发主动让位
- 支持 notify_master / notify_backup / notify_fault 钩子，可联动发送告警、更新 DNS、触发日志归档等运维动作
典型部署结构与分工边界
常见三层架构中，三者角色清晰、边界明确：
- 最外层：Keepalived 管理 VIP（如 192.168.50.130），对外提供唯一访问入口
- 中间层：两台 Nginx 服务器（如 192.168.50.133/134）监听该 VIP，各自反向代理到后端 Web 或 API 集群
- 最内层：真实业务服务（如 Tomcat、Spring Boot、PHP-FPM）运行在独立节点，由 Nginx 按需分发请求
注意：Keepalived 不参与请求内容解析，Nginx 不负责 IP 漂移决策——这种职责解耦，正是系统稳定与可维护性的基础。
适配多操作系统的关键落地点
企业环境中常需兼容银河麒麟 V10、openEuler、CentOS 8+、UOS 等国产及主流发行版。差异主要体现在：
- 服务管理：systemd 单元文件路径与启动命令统一，但部分国产系统需额外加载内核模块（如 ip_vs、nf_conntrack）
- 依赖安装：不同系统包管理器（dnf/yum/apt/zypper/pacman）对应依赖名称略有差异，如 keepalived-devel 在 openEuler 中为 keepalived-devel，麒麟中可能需手动编译
- 网卡命名：ens33、eth0、enp0s3 等需在 keepalived.conf 的 interface 字段中准确填写，否则 VIP 绑定失败
- SELinux/AppArmor：麒麟、UOS 默认启用安全模块，需调整策略或临时 setenforce 0 验证，再制定最小权限规则
