Nginx轮询适用于无状态、接口一致、性能相近的微服务，需按业务分upstream组、差异化配置超时与keepalive，并避开含状态、异构节点及强依赖顺序场景。
Nginx 轮询模式在多业务逻辑集群中，适合部署无状态、接口行为一致、性能相近的微服务节点，配置本身简单，但要真正稳定运行，关键在于匹配业务特性做针对性调整，而非直接套用默认参数。
轮询配置的核心结构
只需在 http 块中定义 upstream，并按顺序列出各业务服务实例地址：
- 每个 server 行不写任何参数时，默认权重为 1，请求严格按 A→B→C→A 循环分发
- 地址支持 IP+端口（如 10.20.30.40:8081）、域名（如 order-svc.prod）或 Unix socket（适用于同机多进程场景）
- 无需声明 round_robin，它是 upstream 的默认调度行为，显式写出反而冗余
适配多业务逻辑的关键增强项
多个业务模块共用同一 Nginx 实例时，不同服务的响应特征可能差异较大（如订单服务耗时长、用户查询快），需差异化配置：
- 按业务分 upstream 组：不要把订单、支付、通知等混在一个 backend 里；应分别定义 upstream order_backend、upstream notify_backend，再在对应 location 中引用
- 差异化超时与重试：在不同 location 块中设置独立的 proxy_read_timeout 和 proxy_next_upstream。例如订单接口设为 60s + error timeout http_500，而健康检查接口可设为 5s + error
- 连接复用隔离：为高频低延迟业务（如用户鉴权）启用 keepalive 64；对低频高耗时业务（如报表导出）可关闭 keepalive 或设更低值，避免连接池被长期占用
避开常见业务适配陷阱
轮询不是“一配了之”，以下情况需主动规避或切换策略：
- 含本地缓存或会话状态的旧业务模块（如基于 HttpSession 的管理后台），轮询会导致登录态丢失，应改用 ip_hash 或统一接入 Redis session
- 集群中存在异构节点（如部分机器专用于 GPU 推理、其余仅 CPU 计算），不能靠纯轮询均摊流量，须改用 加权轮询，例如 server ai-svc-1:9000 weight=5
- 某业务模块后端有强依赖顺序（如先调 A 再调 B），Nginx 层无法保障链路一致性，此时不应由 Nginx 做该模块的负载均衡，而应交由服务网格或客户端 SDK 控制
验证与可观测性落地建议
上线后快速确认是否按预期工作：
- 在各业务服务响应头中注入标识字段，例如 X-Service: order-v2、X-Service: notify-worker，通过 curl 或浏览器 Network 面板直观识别路由路径
- 配合 Nginx 日志格式，在 log_format 中加入 $upstream_addr 和 $upstream_http_x_service，便于按业务维度聚合分析转发目标与耗时
- 对核心业务（如下单、支付），在 Prometheus 中采集各 upstream 的 nginx_upstream_requests_total 与 nginx_upstream_fails_total，设置失败率 >1% 的告警
