权重配置不能实现业务模块隔离，仅用于同一upstream内后端节点的流量比例分配；真正的模块隔离需通过独立upstream块、逻辑路由分离（子域名/路径/请求头）及专属配置边界来实现。
权重配置本身不直接实现业务模块隔离，它属于 upstream 负载均衡策略的一部分，仅影响同一 upstream 块内多个后端节点的流量分发比例。真正在 Nginx 中实现不同业务模块间的隔离，靠的是 逻辑路由分离 + 独立配置边界，而非调整 weight 数值。
用独立 upstream 块替代“共用块+调权重”
把多个业务模块（如订单服务、用户服务、报表服务）塞进同一个 upstream 块，再靠 weight 区分，本质是共享资源池——一个模块异常或扩容会影响其他模块的可用性与可观测性。
- 每个业务模块定义专属 upstream 块，名称语义化：upstream order_backend { server 10.0.1.10:8080 weight=5; server 10.0.1.11:8080 weight=5; }
- 对应 server 或 location 块中只 proxy_pass 到该 upstream，不跨模块复用
- 这样限流 zone、日志路径、超时设置、健康检查参数都能按模块独立配置，互不干扰
权重只在模块内部生效，不能代替模块划分
weight 的作用范围严格限定在单个 upstream 块内，它解决的是“这个模块的几个实例谁多分一点请求”，不是“订单模块和用户模块谁该接更多流量”。后者应由业务路由层决定：
- 子域名路由：order.example.com → order_backend，user.example.com → user_backend
- 路径前缀路由：location ^~ /api/order/ { proxy_pass http://order_backend; }
- 请求头识别：map $http_x_module $backend { "order" "order_backend"; "user" "user_backend"; }，再 proxy_pass http://$backend;
避免用 weight 掩盖架构问题
当团队试图通过大幅调高某个模块的 weight（比如设为 100）来“优先保障核心业务”，往往说明上游路由已模糊或后端扩缩容不均。更健壮的做法是：
- 用独立 server 块或 location 块明确划分入口边界
- 为关键模块配置更强的限流（limit_req zone=order_api burst=100）和更短超时（proxy_read_timeout 15）
- 监控各 upstream 的 active_connections 和 request_time，用数据驱动扩容，而非凭经验调 weight
需要权重协同隔离的典型场景
仅在灰度发布或渐进式迁移时，才需将新旧版本后端放在同一 upstream 内，并用 weight 控制流量比例。此时仍要确保：
- 该 upstream 专用于本次灰度，不混入其他业务模块节点
- 灰度流量通过独立 location 或 header 标识引入，不污染主链路
- 灰度日志单独记录（access_log /var/log/nginx/gray-order-access.log），便于快速回滚
