Nginx 集群中如何通过 upstream 实现流量调度

Nginx集群中upstream流量调度本质是构建可控、可观察、带状态感知的分发层，需通过业务语义分组、匹配调度算法（如轮询/least_conn/weight）、location精准导流及健康检查、头透传、长连接复用等协同实现稳定可靠转发。

Nginx 集群中通过 upstream 进行流量调度，本质是构建一个可控、可观察、带状态感知的分发层，而不是简单地把请求“平均扔出去”。关键在于分组定义、策略匹配和连接控制三者协同。

按业务语义拆分 upstream 分组

每个微服务或功能模块应有独立的 upstream 块，放在 http{} 上下文中：

• 名称要清晰，例如 user_svc、order_api、file_upload
• 节点地址支持 IP:Port、DNS 名（如 auth-service.default.svc.cluster.local）、Unix socket
• 避免混用：不同服务不共用同一 upstream，否则健康状态、限流、连接池会互相干扰

选对调度算法并配合理策略

算法需匹配实际链路特征，不是越复杂越好：

• 轮询（默认）：适合无状态、短连接、响应时间均衡的服务，开箱即用
• least_conn：写在 upstream 首行，优先发给当前活跃连接数最少的节点，适合长连接多或处理时长差异大的场景（如 WebSocket、文件上传）
• weight：用于性能不均的后端，比如新机器设 weight=5，旧机器设 weight=1，但注意 least_conn 下 weight 仅影响初始建连阶段
• 避免 ip_hash：集群内调用方多为 Pod IP，易漂移，导致负载不均甚至单点过载

用 location + proxy_pass 精准导流

分流逻辑由 location 规则驱动，必须与 upstream 分组一一对应：

• 用 ^~ /api/user/ 前缀匹配，性能高且不易被正则覆盖
• proxy_pass http://user_svc/; 末尾斜杠决定是否截断路径 —— 推荐加斜杠，让后端收到干净路径
• 支持动态变量路由：用 map 指令解析 $http_x-env 或 $arg_v，再 proxy_pass http://$backend;

增强稳定性与可观测性

光转发不够，还要确保转发过程可靠、可查、可调：

• 启用被动健康检查：max_fails=3 fail_timeout=30s，异常节点自动摘除
• 透传关键头：proxy_set_header X-Real-IP $remote_addr;、X-Request-ID $request_id;
• 复用长连接：upstream 中加 keepalive 32;，location 中加 proxy_http_version 1.1; 和 proxy_set_header Connection '';
• 记录真实转发目标：log_format 中包含 $upstream_addr 和 $upstream_response_time