nginx轮询负载均衡是微服务中轻量级流量分发方式，需配置upstream与proxy_pass，并增强故障摘除、超时重试及连接复用；适用于无状态均质服务，不适用会话保持或性能异构场景。
轮询的基本配置结构
只需在 http 块中定义 upstream 组，按顺序列出微服务实例地址，再在 location 中通过 proxy_pass 引用即可：
- 每个
server行默认权重为 1，请求按顺序循环分发（如 A→B→C→A…） - 地址支持 IP+端口、域名或 Unix socket，例如
server 10.0.2.5:8081; - 无需显式写
round_robin，它是 upstream 的默认行为
微服务场景下的关键增强项
纯轮询不感知节点健康状态，直接用于生产环境风险较高。建议至少补充以下三项：
-
故障自动摘除：为每个
server添加max_fails=3 fail_timeout=30s，连续失败 3 次后暂停转发 30 秒 -
超时与重试：在
location块中设置proxy_connect_timeout 5s、proxy_read_timeout 30s，并启用proxy_next_upstream error timeout http_500 http_502 -
连接复用优化：对高频 API 场景，添加
keepalive 32;并配合proxy_http_version 1.1;和proxy_set_header Connection '';
轮询的适用边界与替代方案
轮询不是万能解法，需结合微服务实际特性判断是否合适：
- 适合：RESTful API 网关、无状态计算服务、日志上报等短连接、均质化处理场景
- 不适合：需要会话保持的服务（如含本地 session 的旧系统），此时应改用
ip_hash或接入 Redis 共享 session - 当节点性能差异明显（如部分机器 CPU 更强），应改用加权轮询，例如
server 10.0.2.6:8081 weight=2;
验证与可观测性建议
配置生效后，可通过简单方式快速验证轮询行为：
- 用
curl -s http://nginx-ip/api/health | grep 'host'多次执行，观察返回的实例标识是否循环变化 - 临时在后端服务响应头中加入
X-Backend-Id，便于 Nginx 日志或浏览器开发者工具直接识别路由路径 - 配合 Nginx 自带的
stub_status或 Prometheus +nginx-vts-exporter监控各 upstream 节点的请求计数与失败率
