构建Nginx高可用架构核心是分层协同：Keepalived实现双节点VIP毫秒级漂移防止单点失效，upstream主动健康检查动态剔除故障后端，nginx -s reload配合配置校验与systemd保障零停机发布，跨机房则通过DNS轮询+本地高可用对实现多活。
构建企业级高可用、零停机的 Nginx 运维架构，核心不是堆砌工具，而是分层协同：前端防止单点失效，中层智能调度与自动摘除，后端支撑平滑发布。关键在于“故障不感知”和“更新无感”，而不是单纯追求组件数量。
双节点+VIP 自动漂移（防止单点失效）
这是高可用最基础也是最关键的防线。用 Keepalived 管理一个虚拟 IP（VIP），主节点健康时 VIP 绑定在其网卡上；一旦检测到 Nginx 进程异常或端口不可达，Keepalived 触发 VRRP 协议，0.3–1 秒内将 VIP 漂移到备节点，客户端通过 DNS 或直连 VIP 访问，全程无重连中断。
- 主节点 priority 设为 100，备节点设为 90，避免脑裂
- 必须配置 vrrp_script 检测 Nginx 进程存活（如 killall -0 nginx），不能只依赖端口通断
- VIP 必须和真实网段同子网，且交换机/云平台需放行 VRRP 协议（协议号 112）
Upstream 健康检查 + 动态剔除（保障后端稳定）
Nginx 自身的 upstream 模块要承担起“流量守门员”职责：不只是转发，更要实时判断后端是否真正就绪。默认的 passive 检查（靠失败次数）响应慢，建议启用主动健康检查（需 nginx-plus 或开源版配合 lua-resty-upstream-healthcheck）。
- 设置 max_fails=2 fail_timeout=5s，避免瞬时抖动误判
- 对关键服务加 HTTP 主动探活：HEAD /health，返回 2xx 才认为可用
- 使用 least_conn 或 ip_hash 算法时，务必确认是否符合业务状态一致性要求（如购物车不能轮询）
配置热加载 + 零停机发布（运维操作不中断）
修改 Nginx 配置后执行 nginx -t && nginx -s reload 是标准流程，但 reload 本身有极短窗口（毫秒级）可能丢连接。生产环境应进一步加固：
- reload 前用 nginx -T 输出完整生效配置，人工核对 SSL 证书路径、proxy_pass 地址等易错项
- 配合 systemd 的 ExecReload=/usr/bin/nginx -s reload 并设置 Restart=on-failure，防止 reload 失败导致进程退出
- 若用 Docker Compose，可结合 nginx:alpine 镜像 + 挂载配置卷，用 docker exec nginx nginx -s reload 实现容器内热重载
多活接入层 + DNS 轮询兜底（突破单机房瓶颈）
当单机房双节点仍不够时，需跨地域部署。此时不再依赖 VIP，而是由 DNS 层做粗粒度负载（如阿里云云解析支持按地域、权重、健康检查返回不同 IP）。
- 每个机房内部署独立的 Nginx+Keepalived 高可用对，对外暴露唯一 VIP
- DNS 设置 TTL ≤ 60 秒，确保故障时能快速切走流量
- 各机房 Nginx upstream 后端可指向本地服务集群，也可通过专线接入异地 DB，实现数据就近读写
