Nginx无原生动态权重分发机制，其“动态权重+平滑限流”实为加权轮询与漏桶限流（limit_req）协同：weight静态决定长期流量比例，limit_req独立实现单点平滑压控，二者组合达成业务感知的分层流量调控。
权重决定长期流量比例，不参与实时限流
上游服务器的 weight 只影响请求分发的长期倾向：比如 server a weight=6、server b weight=4，Nginx 会按 6:4 的比例把请求导向两台机器。但它不会根据某台服务器当前 CPU 或响应延迟自动调高/调低 weight——这是静态配置，需人工或外部系统（如 Consul + Lua 脚本）触发 reload 才能变更。
所以“动态”在这里不是 Nginx 原生能力，而是靠运维编排或集成外部信号（如 Prometheus 指标 + 自动化脚本）来实现权重重配+热重载。
限流模块负责单点平滑压控，与权重解耦
真正做平滑限流的是 limit_req 模块，基于漏桶算法：
-
rate 设定恒定处理速率（如
rate=100r/s），Nginx 内部以 100ms 粒度调度，确保出口流量稳定； -
burst 提供缓冲区（如
burst=20），允许短时突发请求排队； - nodelay 控制是否跳过排队——加了就立刻拒绝超限请求（返回 503），不加则排队等待，带来延迟但更平滑。
这个限流作用在 入口层（如 location 或 server 块），对所有流向该路径的请求统一管控，与 upstream 中的 weight 无关。
组合使用才能逼近“动态平滑”效果
想让强弱不一的后端服务器既按能力分摊压力，又不被突发打垮，推荐这样配合：
- 在 upstream 中按服务器实际吞吐能力设 weight（如高性能节点设 weight=10，老旧节点设 weight=3）；
- 在对应 location 中，为每类后端路径单独配置
limit_req_zone，键值可选$host、$request_uri或$http_x_user_tier（配合 map 指令提取用户等级）； - 对核心接口（如 /order/pay）用严格限流（
rate=5r/s burst=3），对静态资源（如 /static/）放宽（rate=100r/s）； - 若需按用户身份差异化限流，用
map提取 header 或 cookie 中的标识，再映射到不同 zone，实现 VIP 用户更高配额。
这样，weight 控制“谁该多干活”，limit_req 控制“每条路最多跑多快”，二者叠加，就形成了业务感知的、有层次的平滑流量控制。
