轮询是Nginx默认负载均衡策略，但微服务中需满足实例性能一致、状态健康可感知等前提；须配置健康检查、连接复用、max_conns限制，并协同服务发现与监控验证。
轮询是 Nginx 默认且最基础的负载均衡策略，在微服务架构中用得广泛，但“默认”不等于“万能”。要真正用好它，得结合微服务的动态性、无状态要求、可观测性和故障恢复能力来设计，不能只写几行 upstream 就完事。
轮询在微服务中的适用前提必须明确
轮询天然假设后端服务实例性能一致、响应时间稳定、无状态、健康状态可被准确感知。微服务环境里，这些条件常被打断：
- 不同服务实例可能部署在异构资源（CPU/内存配比不同）上，导致实际处理能力差异超20%时，轮询会放大延迟——测试表明响应时间可能增加15%
- 服务实例频繁上下线（如K8s滚动更新），Nginx 若未配合服务发现机制，会持续向已下线节点转发请求
- 轮询不感知连接数、响应耗时或错误率，一个慢实例可能堆积大量长连接，拖垮整体吞吐
配置层面的关键加固点
纯 server ip:port; 的写法只是起点，生产级轮询需叠加以下配置：
-
启用健康检查：必须加
max_fails=2 fail_timeout=30s，避免单次超时就摘除节点；建议搭配proxy_next_upstream error timeout http_500 http_502实现请求重试 -
设置连接复用与超时：在
upstream块中加keepalive 32;，并在location中配置proxy_http_version 1.1;和proxy_set_header Connection '';，减少建连开销 -
限制单实例并发压力：通过
max_conns=1024防止单个后端被突发流量打满（需开启least_conn或自定义逻辑配合，但轮询下该参数仍有效）
与微服务治理体系的协同不可少
Nginx 本身不支持服务注册发现，必须外挂适配层才能跟上微服务的弹性节奏：
- 若用 Consul/Eureka，可通过
consul-template或nginx-upsync-module动态更新 upstream 配置，避免手动 reload - 在 API 网关层（如 Nginx + OpenResty）注入轻量服务发现逻辑，定期拉取实例列表并生成
upstream块，比静态配置更可靠 - 所有微服务必须提供标准健康探测接口（如
/actuator/health），Nginx 的health_check指令才能真正起效
监控与验证必须闭环
轮询是否真的“均匀”，不能靠感觉，要靠数据验证：
- 开启
log_format记录$upstream_addr和$upstream_response_time，用日志分析各实例请求占比与延迟分布 - 用
ab或wrk压测时，观察Requests per server是否接近理论均值（如3节点应≈33.3%） - 当某实例响应时间持续高于 P95 阈值时，应触发告警并人工介入——轮询不会自动降权，需靠运维闭环补位
