轮询是轻量可靠的负载均衡底座，但大规模扩展需配套健康检查、指标验证与服务发现等工程实践。必须禁用ip_hash、backup等干扰均衡的配置，启用HTTP健康探测与自动重试，并通过延迟、错误率、请求数分布验证均衡效果；超20节点须对接Consul或etcd实现动态服务发现。
轮询策略本身不“应对”大规模扩展，它只是按顺序分发请求。真正支撑大规模节点扩展的，是一整套轻量、可靠、可观测的工程实践——轮询是底座，不是全部。
保持 upstream 极简，避免绑定类配置
轮询天然适合无状态服务，但前提是配置不破坏它的公平性：
- 不设 weight，除非节点硬件性能差异显著（如 GPU 显存/SSD 缓存明显不同）
- 禁用 ip_hash，否则新节点无法承接已有用户流量，扩容形同虚设
- 不配 backup 或强路由规则，它们会干扰自动均衡节奏
- 只静态列出健康实例 IP:PORT，新增即生效，无需改逻辑、调权重、重发布
必须启用 HTTP 健康检查，防止盲转故障节点
没有探测机制的轮询，在节点规模变大后风险急剧上升：
- 为每个 server 行加上 max_fails=2 fail_timeout=30s，Nginx 会主动发起 HTTP 探测
- 探测端点优先用业务健康接口（如 /actuator/health），而非 TCP 连通性，确保数据库、下游依赖真实就绪
- 配合 proxy_next_upstream error timeout http_502 http_503，单次失败自动切到其他节点，提升请求成功率
扩容后靠指标验证是否真均摊
加完节点不能只看 reload 成功，得用数据确认效果：
- 监控 upstream_response_time 分布，重点看新增节点的 P95 延迟是否正常，避免因配置或网络问题导致慢节点拖累整体
- 观察 upstream_status 中各节点的 5xx 比率，若某节点突增，说明其下游尚未同步就绪或资源不足
- 比对 Prometheus 指标 nginx_http_request_total{upstream="xxx"}，确认各节点请求数偏差控制在 ±12% 内
- access_log 中加入 $upstream_addr 和 $upstream_response_time，便于快速定位异常节点
超 20 节点时，必须对接服务发现
硬编码 IP 列表在大规模场景下不可持续，会成为运维瓶颈和故障源头：
- 轻量方案：用 consul-template 监听 Consul 注册变化，自动生成 upstream 配置并触发 reload
- 灵活方案：OpenResty + Lua，在 init_by_lua_block 中拉取 etcd/Consul 数据，用 balancer_by_lua_block 动态选节点，彻底绕过 reload
- 临时过渡：将 upstream 单独抽成独立文件（如 upstream_backend.conf），扩容只改该文件，降低主配置误操作风险
