在线接口通常对尾延迟敏感，离线或准实时任务更关注吞吐量与完成时间。两类工作负载放在同一批机器上，可以提高资源利用率，却也可能让后台计算在流量高峰时拖慢在线请求。
混部不是“把两个容器启动在同一台机器”这么简单。它要解决的是：当资源发生竞争时，系统能否始终把在线服务放在更高优先级，并快速回收后台任务使用的资源。
先定义不可破坏的目标
设计混部方案前，先把目标写成约束：
- 在线服务的延迟和错误率不能因混部明显恶化；
- 准实时任务必须可以被限速、暂停或迁移；
- 资源竞争能够被观测，而不是只看到最终超时；
- 灰度和回滚不依赖临时人工操作；
- 任何优化收益都要在稳定性约束内衡量。
这意味着混部的首要指标不是“平均 CPU 利用率”，而是流量波动时在线服务仍然拥有多少安全余量。
CPU：优先级比配额更关键
静态 CPU 配额能够限制后台任务使用多少资源，却不能完整表达“在线任务来了以后立即让路”。因此需要同时考虑调度优先级和时间片。
Linux 中不同调度策略具有不同语义。可选方向通常包括：
- 在线进程使用更高优先级，后台进程维持普通调度；
- 在线进程使用普通调度，后台进程使用低优先级或 idle 调度；
- 通过 cgroup、容器运行时或平台调度器统一配置权重与上限。
第一种方案见效快，但风险也更大。如果高优先级进程可以消耗全部 CPU，日志、运维工具甚至内核任务都可能得不到及时调度。必须为普通任务保留时间片，并通过小规模压力测试验证最坏情况。
第二种方案更符合“后台任务只吃空闲资源”的直觉，但依赖内核和容器隔离能力，需要评估升级成本与工具兼容性。
内存、IO 与网络不能缺席
只隔离 CPU 并不足够。媒体处理、模型推理等后台任务往往同时消耗大量内存和磁盘带宽。
| 资源 | 主要风险 | 常见控制方式 |
|---|---|---|
| 内存 | OOM、页缓存挤压、频繁回收 | 容器上限、进程回收、并发控制 |
| 磁盘 IO | 在线请求读写延迟升高 | 独立卷、IOPS/带宽限制 |
| 网络 | 下载上传占满出口 | 任务限速、连接并发限制、流量整形 |
| 进程数 | 后台任务放大调度开销 | worker 上限、队列背压 |
资源限制要尽量靠近任务运行边界。只在业务调度层限制“同时运行多少任务”，无法处理单个异常任务突然放大资源消耗的情况。
任务选择比技术隔离更重要
不是所有准实时任务都适合混部。选择任务时可以从三个维度判断：
- 时效性：延迟几分钟是否会影响用户体验；
- 可中断性：暂停后能否安全重试，是否存在昂贵的中间状态；
- 资源曲线：任务是否长期占满资源，单任务峰值是否可控。
低优先级、可重试、可分片的计算任务通常更合适。与用户发布链路直接相关的步骤，即使也是异步任务，也应保留在稳定资源池中。
灰度路径
混部需要从一开始就支持双资源池：
任务进入
↓
判断任务类型、优先级与灰度条件
├─→ 稳定资源池
└─→ 混部资源池
测试阶段可以维护独立的任务流程或资源别名，避免一次修改影响全部任务。运行稳定后，再把选择逻辑收敛为统一的资源路由规则。
灰度期间至少要观察：
- 在线服务的平均与尾延迟；
- 不同任务池的排队时间和完成时间；
- CPU 抢占是否按预期发生；
- 内存、IO 和网络是否触发限制；
- 暂停混部任务后，在线指标能否快速恢复。
回滚不是最后补上的脚本
最直接的回滚动作应该是停止向混部资源池派发新任务，并让运行中的任务安全结束或重新入队。底层调度策略和宿主机参数也要能分批恢复。
如果回滚依赖登录机器逐个修改参数，说明混部仍停留在实验阶段，还不具备规模化运行条件。
小结
混部的本质是把“闲置资源”变成一种可以被回收的能力。CPU 调度只是其中一环，真正可用的方案还需要资源全维度隔离、任务分级、灰度路由、观测和回滚形成闭环。
利用率提升是结果，在线服务在高峰中仍然稳定，才是混部系统成立的前提。