轮询算法是Nginx API网关最基础的负载均衡策略，按server声明顺序循环调度、权重默认为1、各节点请求比例均等，配置只需upstream内列server地址并proxy_pass引用，但不感知响应时间或连接数，适用于无状态均质服务。
轮询算法是 Nginx 作为 API 网关时最基础、最常用的负载均衡策略，其配置逻辑简单但需理解背后的转发机制与适用边界。
轮询的核心行为逻辑
轮询不是随机分配，而是按 声明顺序 循环调度：Nginx 维护一个内部指针，每次收到新请求就指向下一个 server，到末尾后回到开头。它不感知后端响应时间或当前连接数，仅依赖配置中 server 的排列顺序和默认权重（均为 1）。
- 每台后端服务器在无故障前提下，获得请求的比例严格相等（如 3 台即各约 33.3%）
- 不依赖额外指令，
upstream块内只写server IP:PORT;即启用轮询 - 若某 server 不可达（TCP 连接失败），Nginx 会临时剔除它，并在后续探活成功后自动恢复
API 网关场景下的典型配置结构
在 API 网关中，轮询通常嵌套在 upstream 定义中，再由 proxy_pass 关联到具体 location 路由规则：
- 先定义上游服务组，例如：
upstream api_backend { server 10.0.1.20:8080; server 10.0.1.21:8080; server 10.0.1.22:8080; } - 再在 server 块中绑定路由路径：
location /v1/ { proxy_pass http://api_backend; } - 必须包含关键代理头，如
proxy_set_header Host $host;和proxy_set_header X-Real-IP $remote_addr;，确保后端能正确识别原始请求上下文
轮询在网关集群中的实际约束
它适合无状态、性能均一的微服务实例，但在真实网关部署中容易暴露短板：
- 无法应对节点间处理能力差异（如 CPU/内存配置不同），此时应改用加权轮询
- 同一用户连续请求可能被分发到不同后端，不适合需会话保持的场景（此时选
ip_hash） - 健康检查仅基于 TCP 层，默认不校验 HTTP 返回码，若后端应用假死（进程存活但接口返回 500），轮询仍会持续转发
验证与调优建议
上线前建议通过简单方式验证轮询是否生效：
- 让每个后端返回唯一标识（如
Server-ID: node-A），连续发起 6 次请求，观察响应是否按 A→B→C→A→B→C 循环 - 用
nginx -t检查语法，再nginx -s reload生效配置，避免全量重启 - 监控各后端的请求计数与平均延迟，若某节点延迟显著偏高（如 >200ms），说明轮询未适配实际负载，需引入 least_conn 或外部健康检查插件
