应按硬件能力设基础weight值，以标准云服务器（8C16G+1TB NVMe）为基准设weight=10，旧物理机据CPU性能、IOPS等综合折算为3～4；避免默认weight=1，须分层绑定策略并支持动态reweight。
旧物理机与新云服务器混部时，直接“一刀切”分配流量会放大性能鸿沟——新机器空转、老机器过载。关键不是回避差异，而是用权重把差异转化为可控的调度杠杆。
按硬件能力设基础weight值
权重必须反映真实容量和处理能力，不能拍脑袋定。新云服务器通常具备更高CPU核数、更大内存、NVMe本地盘和万兆网卡，而旧物理机多为SATA盘、千兆网、老旧CPU。建议：
- 以一台标准配置云服务器（如8C16G+1TB NVMe）为基准，设weight=10
- 旧物理机按实际资源折算：若其CPU性能约为新机的40%、磁盘IOPS仅为15%，综合评估后设weight=3～4（不建议低于2，否则易被完全绕过）
- 避免使用默认weight=1——它隐含“所有节点等价”的错误假设，混部场景下会严重失真
分层绑定权重策略，兼顾稳定性与弹性
单一权重无法应对业务多样性。应结合调度策略分层控制：
IT技术解决互联网公司网站模板
下载
IT技术解决互联网公司网站模板是一款适合提供APP设计、网页开发、SEO优化、云服务、数据分析等服务的互联网公司宣传网站模板下载。提示：本模板调用到谷歌字体库，可能会出现页面打开比较缓慢。
- 核心有状态服务（如数据库主节点、认证中心）：绑定“亲和物理机”策略 + 高权重云服务器组，确保跑在高性能、低延迟节点上
- 无状态边缘服务（如静态资源网关、日志采集器）：可分配至旧物理机集群，但为其所在后端池设置较低weight（如3），并启用“优先”执行机制——有资源就跑，没资源也不阻塞启动
- 灰度发布通道：将新云服务器权重临时调高（如从10→12），旧物理机对应权重同步微降（如4→3.5），让新版本自然承接更多流量，便于观察响应延迟与错误率变化
动态reweight应对实时负载漂移
静态weight解决的是“能跑多少”，动态reweight解决的是“此刻该跑多少”。尤其当旧物理机因老化出现CPU软锁、磁盘慢IO或内存回收抖动时：
- 接入统一监控（如Prometheus+Node Exporter），对旧物理机设置单独告警项：CPU load1 > 8、iowait > 25%、pgpgin/pgpgout异常突增
- 触发自动脚本：当连续3分钟满足任一阈值，执行
ceph osd crush reweight或LB后端健康检查API，临时将其reweight下调15%～20% - 恢复条件设为“连续5分钟指标回归基线”，避免震荡调整；每次reweight变动幅度不超过20%，防止数据重分布风暴
验证是否生效的三个硬指标
调完不是结束，要盯住结果：
- 各节点请求QPS占比，是否与预设weight比例基本吻合（允许±8%偏差）
- 旧物理机平均CPU使用率是否稳定在65%以下，且P95响应时间未劣于设定SLA
- 跨集群流量切换过程是否平滑——例如CLB后端健康检查失败率
