企业中一般存在「在线服务」和「离线任务」两种类型工作负载。在降本增效的大背景下，如何通过技术为不同业务完成较为精准的资源配置成为企业制胜的法宝。然而，这并非一蹴而就，需要不断的探索和实践。
知乎在采用金山云在离线混部解决方案Colocation(以下简称“Colo”)前，就已尝试多种优化IT资源成本的方法，例如根据数据指标手动或自动降低服务资源配置、潮汐调度等，直到选择混部方案后，知乎才实现了更精确化的管理调度、更合理的资源隔离，以及更高效的运维效率。
本文将对知乎早期优化路径进行简要分析，并将重点置于Colo在知乎大数据场景混部中的具体使用方式，以及该方案为知乎带来的价值。
知乎采用混部前的成本优化路径
知乎的成本优化路径经历了早期和中期两个阶段，两个阶段的优化在当时背景下利用率有所提升，但最终都未能达到理想的效果。
早期阶段：系统化资源利用提升
在进行系统化资源利用提升前，需要通过建立的完善的数据指标和应用指标系统，通知业务方自动或主动降低资源配置。在早期资源利用率不合理的场景下，该方案是一种直接高效的资源优化手段，但其属于被动式的处理手段，并不能做到资源的最优配置。(如下图)
中期阶段：潮汐调度
与离线任务相比，在线业务具有明显的波峰波谷，可利用潮汐调度来实现资源的优化配置。利用K8s的VPA(Vertical Pod Autoscaler)、HPA(Horizontal Pod Autoscaler)组件，可在低峰和高峰时分别为工作负载进行缩容和扩容。同时利用K8s的CA调度器(Cluster Autoscaler)实现基于pod的扩缩，而在集群容量不足时扩容新的node节点。(如下图)
存在的问题：
尽管以上两个阶段均在一定程度上提升了资源利用率，但在这两个阶段中知乎离线集群与在线集群完全独立不互通，离线集群和在线集群的资源利用率均存在明显的周期性波动，具有明显的潮汐效应。
离线集群在凌晨0点至8点之间的资源利用率达到95%以上，处于满负荷运行状态，而在线集群同期内的资源利用率会下降至30%以下。这种周期性变化使得离线集群凌晨资源存在短缺，在线集群资源利用率严重不足，集群整体平均利用率在27%-30%左右。
现阶段知乎大数据场景采用Colo实现在离线业务混部后
现阶段，知乎大数据场景多集群打通了在线集群与离线集群的互联互通。离线任务调度平台提交任务到YARN Federation中的YARN Router节点，Router节点连接决策服务，决策服务依据任务画像和其他边界条件确定的规则，最终将符合规则的低优离线任务运行至在线集群中，实现在离线混部调度。(如下图)
知乎大数据场景低优离线任务调度至在线集群后，在线集群中在离线业务的混部通过Colo管理与调度，Colo通过调度与重调度能力、CPU/Memory/BLKIO/网络带宽等资源隔离及资源动态调整压制、资源冲突检测与处理、实际负载感知调度能力、eBPF关键内核指标的采集和利用等关键技术，保证了在离线混部节点间均衡调度、节点不过载、在线服务稳定性、敏感型业务不受干扰、离线资源及时回收等问题。Colo通过Colo-manager、Colo-scheduler、Colo-Descheduler、cololet等组件，采取削峰填谷的方式，提高在线集群资源利用率，降低离线集群在夜间的超负荷运转状况，实现服务器资源利用率大幅提升，从而减少了企业IT开支。(Colo架构如下图)
Colo在知乎大数据场景混部中的具体使用方式：
使用Colo调度系统进行在离线业务混部时，根据不同业务场景可通过配置Colo的Priority(优先级)与QoS(服务质量)的关键字段字段进行部署。在知乎大数据场景混部的应用中，Colo将业务做多个分级，优先保障高级别业务。具体如下：
数据库/消息队列等中间件服务：单独处理，不参与混部
LSR类(Priority:colo-prod + QoS:LSR)：知乎较高敏感型在线服务，可以接受牺牲资源弹性而换取更好的确定性(如CPU绑核)，对应用时延要求极高。QOS对应Guarantee
LS类(Priority:colo-prod + QoS:LS)：知乎典型的在线服务，通常对应用的延迟、资源质量要求较高，运行时间较长，也需要保证一定的资源弹性能力。QOS对应Burstable
BE类(Priority:colo-batch + QoS:BE)：知乎混部场景中的低优离线任务，通常表现为对资源质量有相当的忍耐度，对延迟不敏感，运行时间相对较短。QOS对应BestEffort
知乎大数据场景混部方案Colo的落地价值：
在离线混部方案Colo已在知乎大数据场景下完成大规模核心业务落地，部署节点数量超过3000多个。不仅实现了知乎多个集群全天资源利用率均值的大幅提升，白天实时利用率也保持在一个较高的水平，且服务器节点之间的负载均衡也得到了明显改善。
