这两种类型的服务负载在分时复用、资源互补上存在极大的优化空间，使得它成为混部的首选场景。在离线混部：将在线服务和离线作业部署到同一个节点，以此来提高资源利用率，减少企业对与日俱增的离线计算资源的成本开支。在离线混部最重要的目标：在提高单机资源利用率的同时，保障在线服务和离线作业的服务 SLA。

方案概述：调度保障：采用快感知慢回退预测算法、离线大框、共享状态调度等手段，进行资源弹性复用，解决调度冲突。资源保障：通过应用优先级划分、内核增强、干扰检查、超线程避让等关键手段，保证应用间资源隔离。

采取混部节点自动上报扩展的离线资源，离线服务通过离线 Cgroup 大框隔离的方式来保证资源的弹性复用和回收。首先，在资源复用的方式上，将空闲的在线资源进行精准预测，并通过扩展资源的方式，暴露给离线调度器，从而让离线调度器可以看到有多少离线资源是可以复用的，然后进行调度。其次，资源复用以后，需要能够有一层限制，限制离线负载不能过度使用宿主机的资源；在底层资源限制上，针对在线和离线业务，分别限制其在不同的 Cgroup 层级上：

多调度器共享状态调度的模式，第一是解决在线资源的复用调度问题，第二是解决调度冲突、调度性能、可扩展性和可靠性。共享状态调度，无论从资源视图共享性，并发性，资源分配的灵活性以及对多调度器的灵活支持，都表现比较出色。因此，采用共享状态乐观并发的调度方式，该方案对协调器的性能和可靠性有较高要求，但是可以做到真实的资源共享，资源视图和全局一致性，同时还能支持部署多个不同的调度器来针对不同场景进行调度。设计和实现了 调度协调器，Kubernetes 调度器只需要在reserve 阶段，开发扩展插件，进行 reserve 的提交，即可完成共享状态并发。

在资源的预测和负载处理上，采用指数衰减滑动窗口算法，达到快速感应资源上升，慢速感应资源下降的目的，做到自动化，细粒度的分时复用目标。之所以需要快速感应到资源上升，是因为在线服务负载如果有上升，一般都是比较短暂的，此时需要快速感知，从而快速做出资源回收和离线退位。而在负载下降的过程中，一般不能立即就去减小在线服务的资源，而是要保证其运行一段时间，确认是负载真实的进入平稳状态，离线才能开始复用在线资源。

在单机资源保障上，结合 TencentOS 内核，提供了全维度的资源保证；在 Kubernetes 和内核侧提供了强有力的资源隔离和保障机制。在优先级上，采用精细化的 cpuset 编排技术，根据不同类型的服务优先级，高优在线业务，将其进行 cpuset 绑核。中优在线业务，采用 Cgroup quota 和 cpushare 进行 CPU 资源共享。离线业务，则采用离线大框将所有离线业务划分在一个离线 Cgroup 资源池下，但是可以去使用所有的 CPU 核，也可以支持离线业务单独绑定在和高优在线业务完全互斥的 CPU 子集下。

除了基于传统 Cgroup 限制与隔离，比如采用 CPU quota、CPU share 进行资源的限制和隔离，采用 cpuset 进行绑核等，也在内核层次上进行了充分的定制和优化，以适应云原生场景。在 CPU 方面，为了在微观层次应对突发流量以及超线程干扰，TencentOS 云原生内核支持选取 BT 调度类进行离线任务调度，从而能够实现在内核级快速减少离线任务干扰，同时能防止离线任务出现饥饿状态。在内存方面，TencentOS 内核拥有 Cgroup 级别的 cache 清理功能，及时释放某个容器的 cache, 比如离线业务完成以后，就可以将其 pod 触发的 page cache 进行及时清理。在网络和磁盘 IO 方面，云原生内核都进行了自研控制，接口都是标准 Cgroup 接口，充分利用相关 qos 进行容器的qos 保证。

业务的 SLO 干扰检查，一方面是系统层次的指标的干扰检查，另一方面是应用层次的指标的干扰检查。在系统层次，采集各种系统资源指标，比如感知指令集频率 CPI，感知系统调用等手段，获取系统指标干扰。在应用层次，允许在线业务设置自己的 SLO 干扰阈值，混部系统能够回调和检查业务的 SLO，一旦检查到业务真实的SLO 不符合预期，就会采取一系列措施进行干扰源消除；对于离线业务的 SLO，允许动态优先级调整以及弹性公有云的方式，避免离线业务长时间等待或者频繁驱逐，保证离线业务能够在规定时间内跑完。