Nginx无法按API路径动态分配算力，需通过路径分流（location匹配）+后端能力适配（独立upstream及权重）实现差异化调度，并配合least_conn、健康检查等策略防积压。
Nginx 本身不支持按 API 路径动态分配“算力”，加权轮询（Weighted Round Robin）只作用于 upstream 中的 server，且权重是全局静态的——它无法感知路径、响应时间或后端真实负载。所谓“针对不同 API 路径应用差异化算力”，不能靠 weight 参数直接实现，必须拆解为两个层次：路径分流 + 后端能力适配。
先按路径把流量分到不同 upstream
用 location 块匹配不同 API 路径，各自 proxy_pass 到独立定义的 upstream，每个 upstream 内部再配置适合该类业务的权重策略。
- 例如：/api/report/ 类路径计算密集、耗时长 → 分流到 high-cpu-pool
- /api/health/ 或 /api/status/ 是轻量探测接口 → 分流到 low-load-pool，甚至只用 1 台低配机器
- /api/user/ 读多写少、缓存友好 → 可配中等权重，侧重吞吐而非单请求延迟
配置示意：
upstream high_cpu_pool {
server 192.168.1.10:8000 weight=4;
server 192.168.1.11:8000 weight=2;
}
upstream low_load_pool {
server 192.168.1.12:8000 weight=1;
}
upstream user_read_pool {
server 192.168.1.13:8000 weight=3;
server 192.168.1.14:8000 weight=3;
}
server {
location ^~ /api/report/ {
proxy_pass http://high_cpu_pool;
}
location ^~ /api/health/ {
proxy_pass http://low_load_pool;
}
location ^~ /api/user/ {
proxy_pass http://user_read_pool;
}
}
权重设置要基于实际服务特征，不是服务器硬件参数
同一台物理机可能同时跑多个服务，不同 API 对它的压力模型完全不同。比如：
- 一个 /api/report/export 接口平均耗 CPU 800ms，而 /api/user/profile 只需 15ms
- 那么即使两台机器配置相同，对 report 流量来说，它们的实际承载能力可能差 3–5 倍
- 这时应单独压测各路径在每台机器上的稳定 QPS，再反推权重比
举例：压测发现
- 机器 A 处理 /api/report/ 稳定在 60 req/s
- 机器 B 同样路径仅能撑住 20 req/s
- 则 high_cpu_pool 中 weight 应设为 3 和 1（60:20 = 3:1），而非按 CPU 核数设 4:2
必须配合健康检查与 least_conn 防止“假均衡”
纯 weight 只控请求数比例，不防慢节点积压。尤其在长耗时 API 场景下，容易出现：
- 高权重机器已堆积大量未完成请求，但 Nginx 仍持续派新请求过去
- 低权重机器空闲，却因权重低几乎收不到新请求
推荐组合策略：
- 每个 upstream 加 least_conn：优先发给当前活跃连接最少的节点
- 加 max_fails=2 fail_timeout=15s：快速剔除响应超时或 5xx 过多的实例
- 慎用 slow_start=30s：新上线节点逐步加量，避免冷启动冲击
进阶：用 split_clients 或 map 实现灰度/AB 路径分流
如果某些 API 路径需要按请求特征（如 header、query 参数）做更细粒度调度，可结合 map 模块生成变量，再用 if 或 proxy_pass 变量跳转：
- 例如：带 x-version=v2 的 /api/order/ 请求走 v2-pool；其余走 v1-pool
- 或按用户 ID 哈希，将 /api/payment/ 固定路由到某组专用支付节点
这虽不是“算力感知”，但能隔离关键路径、避免相互干扰，间接提升资源利用效率。
