轮询算法是Nginx最基础的负载均衡策略，按顺序将请求依次分发至upstream服务器，要求后端无状态、性能相近，并需配置健康检查与backup节点；适用于中小规模微服务初始调度，但不支持会话保持或能力差异大的场景。
轮询算法是 Nginx 负载均衡最基础也最常用的策略，在分布式服务网关中承担着请求分发的核心角色。它不依赖额外模块或复杂逻辑，天然适配无状态服务，部署简单、行为可预期，特别适合中小规模微服务集群的初始流量调度。
轮询的基本行为与适用前提
轮询按顺序将每个新请求依次分配给 upstream 列表中的后端服务器：第1个请求到 server A，第2个到 B，第3个到 C，第4个再回到 A，循环往复。这种机制默认启用，无需显式声明 round_robin 参数。
- 后端服务必须是无状态的——例如 RESTful API、静态资源服务、消息转发代理等，避免因请求散落导致业务逻辑错乱
- 各节点性能应尽量接近，否则容易出现“请求均匀但负载不均”的现象（如某台机器处理慢请求积压）
- 需配合健康检查机制（如
max_fails和fail_timeout）自动剔除故障节点，保障可用性
在网关层的实际配置要点
服务网关通常作为统一入口，轮询配置需兼顾稳定性与可维护性：
- upstream 块建议使用语义化名称（如
upstream auth_service），便于后续按业务域拆分管理 - 每个 server 行可附加端口、域名或路径，支持混合部署（如
server api-v1.example.com:8080） - 推荐显式设置
max_fails=3 fail_timeout=30s，防止瞬时抖动误判宕机 - 若后端含备用节点，可用
backup标记（如server 192.168.1.100:8080 backup），仅在其他节点全部不可用时启用
轮询与其他策略的协同边界
纯轮询不是万能解法，需明确其能力边界，并在必要时切换或组合策略：
- 当网关需保持用户会话（如登录态未交由 Redis 统一管理），应改用
ip_hash，避免同一用户反复跳转不同实例 - 若后端节点计算能力差异明显（如部分机器 CPU/内存翻倍），应升级为加权轮询，用
weight=2等参数体现实际承载力 - 对缓存命中率敏感的场景（如 CDN 回源），可考虑第三方
url_hash模块，使相同路径请求始终打到同一节点 - 高一致性要求下（如强依赖本地内存缓存），轮询本身不提供连接粘性，需配合应用层重试或限流兜底
验证与可观测性建议
上线后不能只看配置是否生效，而要确认真实流量分布效果：
- 通过
log_format在 access_log 中记录$upstream_addr，直接查看每个请求落到哪台后端 - 用
ab或wrk工具发起千级并发，观察三台机器日志请求数是否基本持平（允许±5%波动） - 配合 Prometheus + nginx-vts-exporter 监控各 upstream 的 request count、response time 和失败率，及时发现倾斜苗头
