Nginx 不负责伸缩决策，仅承担流量分发与健康转发；伸缩由外部系统基于延迟、错误率等指标驱动，通过服务发现动态更新后端，并需渐进加权、状态解耦以实现无损伸缩。
Nginx 本身不负责伸缩决策，也不直接增删后端实例。它只做流量分发和健康转发。真正的“按需水平伸缩”必须靠外部系统驱动，Nginx 的角色是快速感知、平滑承接、零中断切换。
伸缩决策交给监控与编排系统
伸缩动作不能由 Nginx 触发，而应基于可量化的业务或基础设施指标： - 后端服务平均响应延迟 P95 超过 600ms 持续 2 分钟 - 上游 5xx 错误率连续 1 分钟 > 2% - Nginx 自身 writing 连接数达 worker_connections 的 85%，且 upstream timeout 次数突增 - 业务队列积压（如 Kafka 消费延迟 > 30s）或订单处理 SLA 违规这些信号由 Prometheus + Alertmanager 捕获，再交由自动化执行层（如 Ansible Playbook、云平台 SDK 或 K8s HPA 控制器）调用扩缩接口。
后端节点动态注册与发现
Nginx 必须摆脱静态 upstream 配置，才能响应新实例上线或下线： - 在 Kubernetes 中，直接使用 Nginx Ingress Controller：它监听 Endpoint 变化，自动更新内部 upstream，无需 reload - 在虚拟机或物理机环境，推荐 Consul + consul-template：后端应用启动时向 Consul 注册，consul-template 监听变更并生成 nginx.conf，触发 nginx -s reload - 更轻量的方案是 OpenResty + Lua：在 balancer_by_lua_block 中实时查询 etcd 或 Consul API，绕过配置文件，实现毫秒级路由调整关键点：所有新节点必须提供 /health 端点，并通过主动健康检查（如 keepalive 或自定义 probe）确认就绪后再纳入流量。
流量承接要渐进、可退、无损
新增后端不能一上来就全量承接，否则容易因冷启动失败： - 初始 weight 设为 1（老节点设为 10），配合脚本每 3–5 分钟递增权重，直至与老节点一致 - 或采用 draining 模式：新节点注册后先标记 maintenance，等 CPU、内存、JVM 初始化完成，再解除隔离 - 对 WebSocket 或长连接场景，需同步调优 proxy_read_timeout（建议设为心跳间隔的 1.5 倍）、启用 HTTP/1.1 复用及 Connection: "" 清除头 - 缩容前，先从服务发现中注销节点，Nginx 主动返回 503 并设置 max_fails=0 fail_timeout=0，等待活跃连接自然关闭状态解耦是平滑伸缩的前提
如果后端有本地 session、缓存或事务上下文，扩容就会引发状态错乱： - 登录态、用户偏好、购物车等必须存入 Redis 或统一认证中心，禁止写进程内存 - 使用 cookie hash 或 JWT 透传身份信息，Nginx 仅负责 header 透传（如 proxy_set_header X-User-ID $cookie_uid） - 避免 ip_hash：IP 变化或节点数量变动会导致哈希重分布，会话中断 - 数据库连接池、HTTP 客户端连接等资源需支持运行时重建，不依赖进程生命周期不复杂但容易忽略。
