轮询负载均衡本身不提供滚动升级能力，其平滑滚动升级依赖nginx进程管理与后端协同：需多版本共存、健康检查自动剔除节点、优雅下线及无强会话绑定。
轮询负载均衡本身不直接提供滚动升级能力，它只是请求分发策略；真正的平滑滚动升级依赖于 Nginx 进程管理机制（如二进制平滑升级）与后端服务的协同配合。关键在于：让新旧版本后端服务共存、Nginx 代理层无感知切换，同时避免请求中断或会话丢失。
轮询模式下滚动升级的核心前提
轮询是客户端请求按顺序打到多个后端节点的算法，要实现“滚动升级”，必须满足：
- 后端服务支持多版本并行运行（例如新旧两批应用实例同时在线）
- Nginx 的 upstream 配置能动态识别健康节点（自动剔除升级中不可用的旧实例）
- 单个后端实例下线前已完成当前请求处理（ graceful shutdown ）
- 业务无强会话绑定（或已通过 ip_hash 等方式规避，但轮询本身不保证会话粘性）
具体操作步骤（以三台后端为例）
假设你有三台后端服务器：192.168.1.101、192.168.1.102、192.168.1.103，当前全部运行 v1 版本，需滚动升级为 v2。
-
第一步：确保健康检查启用
在 upstream 中配置 max_fails 和 fail_timeout，让 Nginx 自动摘除临时不可用节点：server 192.168.1.101:8080 max_fails=3 fail_timeout=30s; -
第二步：逐台升级后端
先停掉 101 上的 v1 应用，部署并启动 v2；观察 Nginx access 日志或用 curl 测试，确认该节点响应正常后再继续下一台。期间轮询会自动跳过短暂不可达的节点，其余两台持续承接流量。 -
第三步：验证流量分配一致性
升级完成后，用循环请求验证是否仍保持轮询顺序（如 101→102→103→101…），说明 upstream 未因重启而重置状态，连接池和调度逻辑连续。
配合 Nginx 本身的平滑升级（可选增强）
如果你还需升级 Nginx 代理层本身（比如从 1.24 升到 1.26），可在后端滚动完成后再执行二进制平滑升级：
- 备份原 nginx 二进制文件：
cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak - 替换新二进制，发送 USR2 信号：
kill -USR2 $(cat /usr/local/nginx/logs/nginx.pid) - 确认新 master 启动后，再向旧 master 发送 WINCH + QUIT 完成切换
注意事项与常见陷阱
轮询滚动升级看似简单，但容易忽略几个细节：
- 后端应用关闭时若未设置优雅停机（如 Spring Boot 的 server.shutdown=graceful），可能中断正在处理的请求
- 没有配置 backup 或 down 参数时，手动维护节点上下线易出错，建议结合 Consul 或 OpenResty 动态 upstream
- 轮询不保证会话一致，若业务依赖 session，应改用 ip_hash 或将 session 外置到 Redis
- 升级期间监控 upstream 的 active connections 和 failed requests 指标，比单纯看日志更及时
