nginx轮询默认生效，关键在于动态更新upstream并平滑重载：静态配置需nginx -s reload配合max_fails/fail_timeout被动健康检查；动态场景推荐resolver+变量域名或openresty+lua对接注册中心，实现秒级自动发现与零中断上线。
在 Nginx 中通过轮询（round-robin）策略接入新上线的微服务实例，核心是动态更新 upstream 配置并平滑重载，而非等待长连接超时或手动重启。轮询本身是 Nginx upstream 的默认策略，无需额外声明，关键在于“快速”和“无感”——即新实例上线后能被立即分发流量，且不中断现有请求。
确保 upstream 使用默认轮询并启用健康检查
Nginx 默认就是轮询，但需显式定义 upstream 块，并建议搭配 health_check（需 nginx plus）或开源版常用 nginx_upstream_check_module（需编译安装）。若仅用基础版，可依赖 max_fails/fail_timeout 实现被动探活：
- 在 upstream 中为每个 server 设置 max_fails=1 fail_timeout=10s，让异常节点快速摘除
- 新实例启动后，只要能响应 HTTP 200（如 /health 端点），Nginx 下一次请求就会将其纳入轮询队列
- 避免写死 weight 或 backup，否则会干扰轮询均衡性
用变量或动态解析支持自动发现（推荐结合服务注册中心）
纯静态 upstream 需 reload 才生效，无法“快速”。真正实现秒级接入，应绕过手动改配置：
- 使用 resolver + 变量域名（如
server backend-service.default.svc.cluster.local:8080;），配合 Kubernetes Headless Service 或 Consul DNS，让 Nginx 定期解析 A 记录，自动感知新增 Pod/IP - 或集成 OpenResty + Lua，调用 etcd/Consul API 动态更新 balancer（如 lua-resty-upstream-healthcheck）
- 注意：resolver 必须配 valid=5s，否则 TTL 过长，新实例延迟加入
reload 时避免连接中断（零停机上线）
即使要 reload 配置，也不该影响业务：
- 用 nginx -s reload（非 restart），Nginx 启动新 worker 进程，旧进程处理完已有连接后退出
- 确保 worker_shutdown_timeout 足够长（如 30s），防止长连接被强制断开
- 客户端侧设置合理的 keepalive timeout（如 60s），与 Nginx 的 keepalive_timeout 匹配，减少连接重建开销
验证新实例是否真实参与轮询
别只看日志或配置，要实测流量分发：
- 对 upstream 中每个 server 单独打日志：
log_format upstream_log "$upstream_addr $upstream_response_time"; - 用 curl 循环请求，观察 access log 中各实例 IP 是否交替出现、响应时间是否合理
- 检查
nginx -T | grep -A 10 "upstream.*name"确认当前生效配置已包含新地址
不复杂但容易忽略：轮询生效的前提是新实例能通过健康检查（或未触发 max_fails），且 Nginx worker 进程已加载最新 upstream 结构。静态配置靠 reload，动态场景靠 DNS/Lua，选哪种取决于你的基础设施成熟度。
