原生 Nginx 不支持基于后端 CPU 使用率的动态路由分发，因其 upstream 模块无实时采集、反馈及动态更新权重能力；需通过 Prometheus 采集指标、脚本计算权重、nginx -s reload 热重载实现闭环，或升级至 OpenResty/Nginx Plus。
Nginx 本身不直接支持基于后端 CPU 使用率的动态路由分发，因为其 upstream 模块缺乏实时采集和反馈后端服务器资源指标（如 CPU）的能力。原生 Nginx 是无状态、声明式配置的，不内置服务发现或健康度感知的主动探针机制，更不会自动拉取 Prometheus、Zabbix 或 cAdvisor 等监控系统的 CPU 数据来调整权重。
为什么原生 Nginx 无法直接按 CPU 分发
原因很明确：
- upstream 中的 weight、max_fails、fail_timeout 都是静态或被动故障剔除参数，不随运行时指标变化
- ip_hash、url_hash、least_conn 等算法只依赖请求特征或连接数，不感知系统负载
- Nginx 不提供 HTTP/HTTPS 接口供外部写入实时权重，也没有内置 agent 上报或订阅机制
可行的替代方案：三步联动实现“类 CPU 感知”分发
要达成目标效果，需借助外部组件协同工作，形成“监控 → 决策 → 配置更新”闭环：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
采集层：在每台后端服务器部署轻量 agent（如 node_exporter），暴露
/metrics，由 Prometheus 定期抓取node_cpu_seconds_total{mode="idle"}等指标并计算 CPU 使用率 - 决策层：用 Python/Go 编写调度器脚本，定时查询 Prometheus API，按 CPU 使用率反向计算权重（例如：CPU 越低，weight 越高），生成新的 upstream 配置片段
-
下发层：将新配置写入
/etc/nginx/conf.d/upstream_dynamic.conf，执行nginx -t && nginx -s reload热重载（确保 worker_processes 不为 auto，reload 时连接不中断）
一个最小可运行示例（Nginx + Prometheus + 自动权重脚本）
假设你有两台后端：backend-a:8080 和 backend-b:8080，Prometheus 地址为 http://prom:9090：
- 脚本每 30 秒查一次最近 1m 的平均 CPU 使用率（单位：%），按公式
weight = max(1, round(100 / (cpu_usage + 1)))计算权重 - 生成如下 upstream 块：
server backend-a:8080 weight=8;
server backend-b:8080 weight=3;
least_conn;
}
注意：必须搭配 least_conn 或 ip_hash 等算法使用，否则仅改 weight 不生效；且 reload 频率不宜过高（建议 ≥20s 间隔），避免 Nginx 频繁重载影响稳定性。
更现代的工程化选择：用 OpenResty 或 Nginx Plus 替代
若业务规模较大、对实时性要求高，推荐升级技术栈：
-
OpenResty：利用 Lua 调用 resty.http 请求 Prometheus API，在
init_by_lua_block或定时 timer 中动态更新 shared_dict 中的权重表，再在balancer_by_lua_block中实现自定义调度逻辑 -
Nginx Plus：官方商业版支持 active health checks + API 动态 upstream 管理（
POST /api/7/upstreams/backend/servers/1可实时修改 weight），配合外部脚本即可闭环
