*作者：赵慰*

在 [2022 云栖大会龙蜥峰会云原生专场](http://mp.weixin.qq.com/s?__biz=Mzg4MTMyMTUwMQ==&mid=2247508686&idx=2&sn=1ff88844132a40dc727b364524f66ddc&chksm=cf6551bcf812d8aa8055f314ae8cf724e5d2bea33b6bfb428512899b6a56c0968290666204e8&scene=21#wechat_redirect)上，来自爱奇艺的基础架构研究员赵慰分享了《基于龙蜥与 Koordinator 的在离线混部实践》技术演讲，以下为本次演讲内容：

## 爱奇艺离线业务混部背景

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/28d6cb1cebcb46328d96afce6c6782e7~tplv-k3u1fbpfcp-zoom-1.image "1.png")

与众多互联网公司一样，爱奇艺常见的负载类型包括业务应用、数据库&中间件以及离线任务。其中业务应用包括有状态应用和无状态应用，无状态应用可以借助运维平台在业务团队和运维团队之间做比较清晰的职责划分，适合混部；而有状态应用较为复杂，混部时的运行质量难以保证。数据库和缓存目前并没有运行在混部集群中。离线任务中的非实时性任务，比如夜间转码、数据处理等只关注吞吐量而不关注时效的任务也是混部的对象。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d27aa02da509483b9859b9ef9eed01d5~tplv-k3u1fbpfcp-zoom-1.image "2.png")

爱奇艺在混部上经历了长时间的探索。

2013 年，爱奇艺初次进行了计算存储混部。进入容器时代后，爱奇艺在 Mesos 上花费了大量精力，最早把在线任务内容生产、 Spark、Storm 等所有工作负载混部在一个集群里，没有进行任何特殊的隔离性处理。在 Docker 上经历了困境后，爱奇艺将业务按节点、集群进行了拆分；这又导致离线任务集群资源常年不够用，在线业务集群利用率非常低，尤其是夜间利用率甚至只有个位数。因此，爱奇艺考虑将夜间线任务的资源提供给离线任务。

2016 年，通过 Mesos Oversubscription 功能引入根据真实资源做额外计数器的机制，将任务分为了延迟敏感和尽力而为两类进行混部。但由于细粒度的隔离性问题，这条道路也无疾而终。

到了 K8s 阶段，由于在线业务的伸缩能力的增强和普及，第二套计数器不再是强需求，爱奇艺直接在 K8s 上进行了混部，通过引入 Kata 保证服务质量。

2022 年，龙蜥 + Koordinator 一并被引入，用于构建下一步的混部架构。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2e1e28e194ee4867b276e7176ff96a76~tplv-k3u1fbpfcp-zoom-1.image "3.png")

从多年的混部经验里，爱奇艺总结出了影响混部的关键因素：

-   服务质量，尤其是在线业务的质量，脱离了服务质量则混部无意义。
-   获取额外资源。
-   任务适配。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cd1ed7779877473e97f326dfd00c04df~tplv-k3u1fbpfcp-zoom-1.image "4.png")

获取额外资源存在有两个思路：

其一为使用一套计数器，按固定比例超卖资源，直接混用，或者按经验比例分配给各个类型的负载。

其二为多套资源计数器，一种方式是利用经验数据判断集群的空闲时间和空闲资源，另一种方式是通过类似 Mesos Oversubscription 的方式做空闲资源的实时探测。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d43081fdb5054092b6ccfae89ff35927~tplv-k3u1fbpfcp-zoom-1.image "5.png")

**服务质量的策略分为静态和动态。** 动态指在离线业务或具体的进程之间动态进行调整，静态则是一旦下发即固定，即便有影响也不变动。

## 龙蜥和 Koordinator 在离线业务混部探索

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/96bc35c234a642e99aaf5dfc5f58f602~tplv-k3u1fbpfcp-zoom-1.image "6.png")

Koordinator 没有对分布架构做本质上的变动，而是在云原生的规范性方面，比如业务类型的抽象上做了更多工作，使 K8s 和 Koordinator 有了做通用分布式架构的可能性，而不像之前只能针对特定的业务做定制。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9689c53ea06c4e3daaa11b5bfef34aa1~tplv-k3u1fbpfcp-zoom-1.image "7.png")

Koordinator 可以简单理解为给 K8s 增加插件或做了增强，首先会增加一个调度器，引入一套资源技术，在节点上有一个 Koordlet，分别负责收集资源和保证任务的隔离性。

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9c1e65a9ba4343b8b8eb8722d34b114b~tplv-k3u1fbpfcp-zoom-1.image "8.png")

其工作机制为利用计数器在真实利用率基础上进行二次分配。整机的真实使用使用率取决于离线任务的使用率，保证在线业务的质量的前提下，水位线可以根据实践随时调整。

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/da4af98ae868432582b6e70f09a2eea5~tplv-k3u1fbpfcp-zoom-1.image "9.png")

Koordinator 在任务分配 方面分为五种类型（图中只列举了常用的四种），通过不同层级的分类，对在线业务和离线业务进行了不同层级的保障。

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ee1dfeda0e1a4422a30c1f2d76c90e42~tplv-k3u1fbpfcp-zoom-1.image "10.png")

为进一步保证服务质量，爱奇艺引入了龙蜥操作系统（Anolis OS）。Group Identity 功能和 CPU Burst 功能对当前的混部效果起到了很大的提升作用。

Anolis OS 通过配置不同的 Group Identity 启用两套进程调度，一套作为在线业务的调度器，另一套作为离线任务的调度器，在线业务优先级整体高于离线任务。此前，在公平调度的机制下，在线业务、离线业务之间在细粒度上存在互抢资源；而引入两套调度器后，这个问题可以被合理规避。CPU Burst 的作用是使公平调度进程之间的切换更平滑，避免出现毛刺。

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cc9bba5d716247c69b7e204b461daf63~tplv-k3u1fbpfcp-zoom-1.image "11.png")

第一个试点业务为某类型内容实时生产，已经全量运行在混部资源上。从某种意义上它是零成本的，因为全部复用了其他服务器节省出来的资源。目前运行非常稳定，也没有对在线业务造成无法接受的干扰。

每天对热点视频进行二次或更多次编码也是爱奇艺一项较重的非实时离线计算任务，目的在于通过再生产降低码率或提高质量。该任务目前正在灰度验证阶段，期待接入Anolis OS 和 Koordinator 之后能带来足够大的惊喜。

大数据离线计算方面，出于综合考虑，爱奇艺目前依然选择 Kata 作为运行时，因此也正在积极和龙蜥社区进行探索，尝试 Kata 和 Koordinator 的合作。

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/313649f274264bbdab2e97ac92efe366~tplv-k3u1fbpfcp-zoom-1.image "12.png")

上图为试点前后的效果对比，在验证环境设计比较保守的情况下，利用率整体提升 50% 以上。图中任务高峰期 CPU 使用率低于水位线的主要原因是BE任务申请的资源量没有被充分利用导致，涉及到离线任务的运营。当然，如何通过技术手段将真实的资源进行三次、四次甚至无限次的分配，也是爱奇艺期望尽快解决的。

## 未来工作展望

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5194c6aad2764348a07aff22cd7a0f42~tplv-k3u1fbpfcp-zoom-1.image "13.png")

未来，爱奇艺将与龙蜥社区携手同行。首先，争取将 CPU 利用率提升到 50% 甚至更高。其次，因为涉及多租户，需要进行资源分配，尤其是离线任务资源总量不稳定，离线池内资源分配不合理和资源抢占问题时有发生，期望能够在未来规避此类问题。最后，爱奇艺将会在离线任务质量保障方面继续探索。

关于龙蜥峰会云原生专场课件获取方式：

【PPT 课件获取】：关注微信公众号【阿里云云原生】，后台回复“Koordinator课件领取” 即可获取。

【视频回放】：视频回放可前往下方链接进行查看：*<https://openanolis.cn/video>*

点击[**此处**](https://github.com/koordinator-sh/koordinator)，立即了解 Koordinator 项目！

—— 完 ——

非常欢迎你通过 Github/Slack/钉钉/微信 等方式加入我们来参与 Koordinator 开源社区。你是否已经有一些希望与我们社区交流的内容呢？可以通过以下渠道参与讨论：

-   加入社区 Slack channel (English)
-   加入社区钉钉群：搜索群号 33383887 (Chinese) 或者扫描下方二维码

*![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6c1d80e0da4c4b0183aabb7b276718f2~tplv-k3u1fbpfcp-zoom-1.image "14.png")*

*——本文转载自「龙蜥社区」*

ITPub博客

爱奇艺：基于龙蜥与 Koordinator 在离线混部的实践解析 | 龙蜥技术

最新文章