nginx原生不支持基于cpu、内存等指标动态调权，需通过外部机制实现：①prometheus+脚本+reload方式，定时采集指标、计算权重并热重载；②openresty+lua方式，在运行时异步获取健康评分并加权选节点；③结合日志分析做离线策略优化。
Nginx 原生不支持基于后端实时 CPU、内存或响应时间等指标动态调整流量分发。它的 upstream 模块是静态声明式的，所有权重和调度逻辑在配置加载时固化，运行中不会自动感知后端负载变化。但通过外部协同机制，可以构建“近实时”的反馈闭环，让分发更贴近真实负载状态。
用 Prometheus + 脚本 + reload 实现权重动态更新
这是最常用、可控性最强的落地方式。核心不是让 Nginx “自己看”，而是让它“被通知”：
- 在每台后端节点部署 node_exporter，暴露
/metrics，Prometheus 定期采集node_cpu_seconds_total{mode="idle"}等指标，算出 CPU 使用率 - 编写调度脚本（Python/Shell），每 20–30 秒查询 Prometheus API，按公式反向计算权重（例如
weight = max(1, round(100 / (cpu_usage + 1)))） - 生成新的
upstream配置片段，覆盖/etc/nginx/conf.d/upstream_dynamic.conf - 执行
nginx -t && nginx -s reload热重载——注意worker_processes不设为auto，避免 reload 期间连接中断
该方案依赖 reload 的原子性和低开销，实测单次 reload 耗时
用 OpenResty + Lua 实现轻量级运行时决策
若不想频繁 reload，OpenResty 提供更灵活的运行时控制能力：
- 在
init_by_lua_block中初始化 Redis 连接，用于缓存各节点最新健康评分 - 用
timer.every定时（如每 10 秒）异步调用后端/health或/metrics接口，将 CPU、延迟、错误率聚合为一个 0–100 的“可用分”，存入 Redis - 在
balancer_by_lua_block中读取 Redis 数据，按分数加权选择目标节点（例如使用轮询但跳过分数低于 60 的节点） - 所有 Lua 逻辑需做 try-catch，避免单点异常导致整个请求失败
这种方式无需 reload，响应路径内完成决策，适合对延迟敏感的场景。
结合日志与离线分析做策略调优
实时调控之外，结构化日志本身是优化依据：
- 日志中记录
$upstream_addr、$upstream_response_time、$upstream_status，按节点分文件输出 - 用
awk或logstash每分钟统计各节点平均响应时间、5xx 错误率、连接超时次数 - 当某节点连续 3 分钟
upstream_response_time > 1.5s且错误率 > 5%，触发告警并人工介入，或由脚本临时将其weight降为 1
这类分析不参与实时分发，但能发现慢节点、配置偏差或资源瓶颈，支撑长期容量规划。
不复杂但容易忽略
