轮询是Nginx默认负载均衡策略，但微服务中需满足实例性能一致、状态健康可感知等前提；须配置健康检查、连接复用、max_conns限制，并协同服务发现与监控验证。

轮询是 Nginx 默认且最基础的负载均衡策略，在微服务架构中用得广泛，但“默认”不等于“万能”。要真正用好它，得结合微服务的动态性、无状态要求、可观测性和故障恢复能力来设计，不能只写几行 upstream 就完事。

轮询在微服务中的适用前提必须明确

轮询天然假设后端服务实例性能一致、响应时间稳定、无状态、健康状态可被准确感知。微服务环境里，这些条件常被打断：

• 不同服务实例可能部署在异构资源（CPU/内存配比不同）上，导致实际处理能力差异超20%时，轮询会放大延迟——测试表明响应时间可能增加15%
• 服务实例频繁上下线（如K8s滚动更新），Nginx 若未配合服务发现机制，会持续向已下线节点转发请求
• 轮询不感知连接数、响应耗时或错误率，一个慢实例可能堆积大量长连接，拖垮整体吞吐

配置层面的关键加固点

纯 server ip:port; 的写法只是起点，生产级轮询需叠加以下配置：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 启用健康检查：必须加 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 阈值时，应触发告警并人工介入——轮询不会自动降权，需靠运维闭环补位