Nginx 中实现双机热备环境下的系统自动扩容

双机热备自动扩容需构建“感知—决策—接入”闭环，确保Keepalived稳住VIP、Nginx动态发现后端、监控精准触发，并满足就绪检查与贴合静态资源特征的扩容逻辑。

双机热备环境下的自动扩容，不是简单加机器再改配置，而是让主备架构具备“感知—决策—接入”闭环能力。Nginx 本身不扩缩容，Keepalived 也不扩缩容；真正的自动扩容，是让新增的后端服务节点能被 Nginx 动态发现、被 Keepalived 稳定承载、被监控系统准确触发。

主备架构必须先稳住 VIP，再谈扩容

在双机热备中，Keepalived 管的是虚拟 IP（VIP）漂移，不是服务伸缩。如果扩容时 VIP 频繁切换或延迟响应，用户就会感知中断。所以扩容前要确保：

• 主备 Keepalived 的 virtual_router_id、authentication 密码、interface 名称三者完全一致
• 启用 preempt_delay（建议 ≥20s），避免新节点上线瞬间抢主导致 VIP 震荡
• 健康检查脚本（如 /etc/keepalived/nginx_check.sh）检测的是 Nginx 进程 + upstream 可达性，不能只 ping 端口
• VIP 绑定到独立子接口（如 eth0:1），和业务流量物理隔离，减少 ARP 冲突风险

Nginx 必须支持动态 upstream，否则扩容等于手动运维

传统写死 upstream 的方式（server 192.168.1.10:8080;）无法适配自动扩容。你需要让 Nginx 实时感知后端变化：

• 在 Kubernetes 环境：直接用 ingress-nginx，它监听 Endpoints 变更，Pod 启动几秒内自动加入 upstream
• 在物理机/VM 环境：推荐 Consul + nginx-upsync-module，Nginx 主动拉取 /v1/health/service/static-srv?passing 列表，零 reload 更新
• 轻量方案：用 consul-template 渲染 upstream 配置文件，配合 flock -n /tmp/nginx-reload.lock nginx -s reload 防并发重载

后端服务要“就绪才入流”，避免 502 和 404

扩容出来的实例如果一启动就接流量，容易因静态资源未加载、目录权限未就绪、端口监听延迟等问题返回错误。必须做到：

• 提供 /readyz 接口，仅当文件目录扫描完成、磁盘可读、HTTP 端口已监听时返回 200
• 注册服务前，先向 Consul 注册 service 并设置 HTTP check；或使用 registrator 自动注入
• K8s 场景下，readinessProbe 必须配置，且 initialDelaySeconds 要大于服务冷启动耗时（如 Python static server 建议设为 5–8 秒）

扩容触发逻辑需贴合静态资源特征

静态资源的负载高峰往往来自突发下载（如新版本 JS 包发布、热点图片传播），不像 API 请求那样均匀。监控指标应侧重：

• 带宽利用率（如 eth0 出向持续超 85%）比 CPU 更敏感
• 连接数峰值（nginx_stub_status 中 Active connections）比 QPS 更直观
• 上游平均响应时间（$upstream_response_time）突增 3 倍以上，可能预示节点过载
• 触发动作建议：先扩容 1–2 个实例 → 观察 2 分钟 → 若指标未回落再扩，避免雪崩式扩容