nginx不支持运行时修改upstream weight，需借助外部机制实现动态调整：①nginx-upsync-module+consul/etcd毫秒级同步；②openresty+lua闭环调控；③nginx-upstream-dynamic-servers模块+http api轻量控制，均需配套可观测性建设。
Nginx 本身不支持运行时修改 upstream 中的 weight 参数——该值在启动时编译固化，静态生效。所谓“动态调整权重”，本质是借助外部机制持续感知后端性能，并将新权重实时同步进 Nginx 工作进程，整个过程无需 reload、不中断连接。目前生产环境验证有效的路径有三条，按适用场景由强到弱排列：
用 nginx-upsync-module + Consul/etcd 实现毫秒级自动同步
这是云原生和容器化架构下的首选方案。Consul 或 etcd 作为权威配置中心，存放带 weight 字段的 JSON 节点列表；Nginx 通过 upsync 模块定时拉取（默认每 300ms），自动增删节点、更新权重，全部在内存中完成。
- 编译时加入模块：
--add-module=/path/to/nginx-upsync-module - upstream 配置中启用 upsync，并指定 dump 路径用于故障回滚
- Consul KV 中写入格式如：
[{"server":"192.168.1.10:8080","weight":6,"max_fails":3}] - 权重变更只需更新 Consul，Nginx 自动生效，天然支持 fallback 权重（如新节点上线默认 weight=2）
用 OpenResty + Lua 实现毫秒级闭环调控
适合对延迟敏感、逻辑复杂、已有 OpenResty 基础的场景。利用 lua_shared_dict 缓存各节点实时指标（如 P95 响应时间），再在 balancer_by_lua_block 中调用 balancer.set_current_peer() 动态选节点。
- 用
ngx.timer.at每 2–5 秒探测后端健康与真实业务延迟 - 权重计算可采用公式：weight = base × (ref_rt / actual_rt)²，响应越快提升越明显
- 内置熔断：单节点连续 3–5 次超时，临时设权为 0 并标记状态
- 避免多 worker 重复采样，所有指标统一读写共享字典
用 nginx-upstream-dynamic-servers 模块 + HTTP API 控制
轻量、无依赖、适合中小规模集群。模块提供标准 REST 接口，由外部脚本（如 Python + Prometheus）驱动权重变更。
- upstream 块中声明
dynamic_server on;，不写任何 server 指令 - 通过 POST 请求实时管理：
curl -X POST http://nginx-host/upstream/servers -d '{"server":"192.168.1.11:8080","weight":8}' - 可对接 Grafana 告警：PromQL 查询 P95 延迟，脚本每分钟重算并推送新权重
- 无需 Consul 等中间件，部署和调试成本最低
无论哪种方式，都需配合可观测性建设：在 access_log 中固定记录 $upstream_addr $upstream_response_time $upstream_status，用日志聚合工具（如 Loki + Promtail）或脚本按窗口分析各节点表现，避免仅凭单一指标误调。权重只是流量调度杠杆，不能替代对应用层瓶颈（如慢 SQL、锁竞争）的根因治理。
