负载均衡是平滑扩容的关键枢纽而非扩容工具，需协同后端服务与运维机制实现新节点即时承接流量、旧节点安全退出、全程不丢请求不中断连接。
负载均衡本身不是扩容工具，而是让扩容“不被感知”的关键枢纽。真正实现平滑扩容，靠的是负载均衡器与后端服务、运维机制的协同设计——重点在于新节点能立刻承接流量、旧节点能安全退出、整个过程不丢请求、不中断连接。
热重载配置：扩容零中断的基础能力
无论是 Nginx 还是 Apache，都支持配置热加载，这是平滑扩容的前提。新增后端节点只需写入 upstream 或 balancer 配置，再触发 reload，旧 worker 继续处理已有连接，新 worker 立即启用新配置并分发新建连接。
- Nginx：用 nginx -t 校验语法后执行 nginx -s reload；生产环境建议封装为带日志确认的脚本
- Apache：启用 mod_proxy_balancer 后，修改
块，再执行 apachectl graceful - 务必避免直接 kill -HUP 或手动改进程，应依赖官方信号机制保障原子性
健康检查 + 自动摘除：让扩容更可靠
仅加机器不等于扩容成功。如果新节点启动失败或响应异常，流量仍可能打过去。必须配合主动/被动健康检查机制，让负载均衡器自动识别并隔离问题节点。
- 被动检查：设置 max_fails=2 fail_timeout=10s，连续失败后暂停转发
- 主动检查（推荐）：Nginx Plus 或 OpenResty + Lua 可调用 /health 端点轮询；Apache 可用 mod_proxy_hcheck
- 搭配 proxy_next_upstream（Nginx）或 retry=5（Apache），异常时自动转给其他可用节点
动态服务发现：摆脱手动维护 IP 列表
当后端实例超过 10 台，或运行在容器/K8s 环境中，硬编码 IP 会成为运维瓶颈。应引入轻量级服务发现机制，让负载均衡器自动感知节点增减。
- Consul + consul-template：监听服务注册变化，自动生成 upstream.conf 并触发 reload
- OpenResty + etcd：Lua 脚本定时拉取健康节点列表，在 balancer_by_lua_block 中动态选节点
- K8s 场景下，可直接使用 Service DNS + Nginx Ingress Controller 的 Endpoints 自同步能力
权重预留与 draining 协同：控制流量节奏
新节点上线初期可能未完全就绪，老节点下线前需释放连接。仅靠负载均衡器不够，还需后端配合。
- 新节点设较低 weight（如 weight=1），待观察稳定后再逐步调高
- 下线前向后端发送信号（如 SIGUSR2），使其进入 draining 模式：拒绝新连接，但保持旧连接直到超时或自然关闭
- Nginx 可配 max_fails=0 fail_timeout=0 主动标记节点为 down，配合后端 draining 完成优雅退出
