应将动态请求按业务语义（如/api/、/user/等）精准路由至独立高权重重upstream，静态资源由Nginx直接服务；dynamic_upstream需配置weight与least_conn协同实现流量倾斜与实时负载均衡。
直接在 upstream 块中为动态服务节点分配更高 weight，并配合 location 规则将动态请求精准路由过去，就能让高算力节点专注处理动态逻辑。
动态请求必须明确分离出来
不能靠文件后缀（如 .php）简单判断，要以业务语义为准。比如所有 /api/、/user/、/order/ 开头的路径，都属于动态请求；而 /static/、/img/、/css/ 等路径才归静态。Nginx 需用精确的 location 前缀匹配或正则，把这类请求单独拎出来：
location ^~ /api/ { proxy_pass http://dynamic_upstream; }location ^~ /user/ { proxy_pass http://dynamic_upstream; }- 避免写成
location ~ \.php$这类模糊匹配，否则可能漏掉 RESTful 接口或被前端路由干扰
动态 upstream 要独立定义并配高权重
不要和静态服务器混在一个 upstream 里。专门建一个只承载动态请求的 upstream 组，里面只放高配置的后端（如 16C32G 的应用服务器），并显式设高 weight：
upstream dynamic_upstream {server 192.168.1.10:8080 weight=10;server 192.168.1.11:8080 weight=10;server 192.168.1.12:8080 weight=5; # 降级备用节点}
这样，当轮询或加权轮询生效时，流量自然向 weight=10 的节点倾斜，静态资源不会抢占这些资源。
静态资源走完全隔离路径
静态请求不经过 proxy_pass，而是由 Nginx 直接 serve，彻底释放动态节点压力：
location ^~ /static/ { alias /data/www/static/; expires 1y; }location ~* \.(js|css|png|jpg|gif|ico)$ { root /data/www/assets; expires 30d; }- 确保这些路径不落入任何 proxy_pass 区块，也不与动态 location 产生前缀覆盖冲突
可叠加 least_conn 防止单点过载
仅靠 weight 不足以应对突发流量下的瞬时堆积。在 dynamic_upstream 中启用最少连接算法，能实时平衡真实负载：
upstream dynamic_upstream {least_conn;server 192.168.1.10:8080 weight=10;server 192.168.1.11:8080 weight=10;}
weight 决定长期分发倾向，least_conn 在每次请求时做连接数快照决策——两者结合，既保障高算力节点承接主力流量，又避免其因某次慢查询而雪崩。
