nginx轮询负载均衡在微服务中定位为边缘层反向代理，不替代注册中心，需静态/半动态upstream配置、强化健康检查与超时、按业务路径路由隔离、透传治理头信息，避免承担鉴权熔断等网关职责。
Nginx 轮询负载均衡在微服务架构中不是直接“接入服务发现”，而是作为边缘层稳定入口，配合微服务治理体系协同工作。它不主动拉取注册中心（如 Nacos、Eureka）的服务列表，也不感知服务上下线事件，因此关键在于：用静态或半动态方式定义 upstream，再通过健康检查、合理超时和语义路由保障可用性与隔离性。
明确 Nginx 的角色边界
Nginx 在微服务中定位为南北向流量的反向代理，不是服务治理组件：
- 不替代注册中心——后端节点列表需由外部维护（如 CI/CD 生成配置、consul-template 渲染、或 K8s Service 固定 Endpoint）
- 不承担鉴权、熔断、限流等网关职责——这些应由 Spring Cloud Gateway、Kong 或 Sidecar 完成
- 不依赖 DNS SRV 或服务名解析——upstream 中写 IP+端口 或 ClusterIP，避免引入额外故障点
配置基础轮询 + 健康感知
即使使用最简轮询，也必须叠加容错机制，否则无法应对微服务常见抖动：
- 每个 server 行加上 max_fails=3 fail_timeout=30s，实现被动健康检查
- 在 location 块中启用重试：proxy_next_upstream error timeout http_500 http_502 http_503 http_504
- 设置三类超时：proxy_connect_timeout 3s、proxy_read_timeout 15s、proxy_send_timeout 15s
- 对 HTTP/1.1 长连接服务，添加 proxy_http_version 1.1 和 proxy_set_header Connection ''，并在 upstream 中配 keepalive 64
按业务维度做路径级路由隔离
微服务天然按领域拆分，Nginx 可承担第一层语义路由，提升可维护性：
- 为不同服务定义独立 upstream，例如：upstream user_backend { ... }、upstream order_backend { ... }
- 用 location 匹配前缀路由：location /api/user/ { proxy_pass http://user_backend; }
- 如需灰度发布，可用 map 模块提取请求头或 cookie，再结合 if 判断转发目标（避免在 server 块中滥用 if）
对接容器化部署的实用做法
当微服务运行在 Docker 或 K8s 中，推荐以下轻量接入方式：
- 在 Docker Compose 中将 Nginx 与微服务共网络，upstream 直接写 service 名（仅限同一 compose 网络内）
- 在 K8s 中，upstream 指向 Service 的 ClusterIP + Port，配合 readinessProbe 保证节点只在就绪后被 Nginx 转发
- 避免用 host.docker.internal 或 localhost:port 映射——跨容器通信应走 DNS 或 Service 名
- 配置文件通过 ConfigMap 挂载，更新后执行 nginx -s reload 实现热生效
