来自爱奇艺的Mesos+Marathon实践分享

Posted 2021-04-24 Mesosphere APAC

编者按

自2014年起，爱奇艺就开始在生产环境中部署使用Apache Mesos（Mesosphere DC/OS的底层核心技术）。并在2014年底，基于 Marathon 之上设计和开发自有 PaaS 平台 QAE（iQIYI App Engine）。目前，爱奇艺使用Mesos管理着近万台物理机和虚机，分布在多个数据中心以及公有云，单个集群最大节点数近2000。Mesos平台每周启动的容器超过千万，峰值在线容器数近十万。

“通过使用Mesos，适当的资源超卖以及混合部署帮助爱奇艺在最近一个季度中，实现超过虚机 2 倍的平均利用率，这对于一家本土的互联网公司来说非常不易”——杨成伟，爱奇艺高级技术经理。

如今，Mesos 在爱奇艺支撑着许多重要业务，包括但不限于：所有各类型转码生产业务，对服务质量和稳定性要求非常高的各种在线服务、AI 训练及推理服务以及 Storm，Spark等实时计算分析业务；对于实时计算，大数据类型业务， 爱奇艺将Mesos作为一个灵活补充的底层平台，大数据上层平台负责统筹Hadoop/Yarn和Mesos的任务调度。

以下内容来自爱奇艺高级技术经理的分享。

---

  

1. 小试牛刀

‍时光如斯，回望 Mesos 在爱奇艺的发展历程，也并非一番风顺。起初由于人员不足和开源代码不成熟等原因，一些项目不得不暂时搁置。不得不说，在一家迅速发展的科技娱乐公司，在注重内容创作的同时去推动基础设施服务变革是难上加难。

 

爱奇艺从 2013 年年底开始调研 Mesos，这个声称受到 Google Borg集群管理系统启发的开源数据中心操作系统核心技术。Mesos 是一个 ASF顶级开源项目，Mesos的作者也创建了 Mesosphere公司来更好的推动 Mesos 生态的发展。并且，基于 Mesos，Mesosphere 发布了开源与企业版本DC/OS（分布式云操作系统），这一次，暴露在你眼前的不仅是内核，而是一个完整的操作系统。‍

 

回顾当初选择 Mesos 的原因，印象最深的应该有以下几点：

• ‍Mesos 将类似 Google 的大规模集群管理调度方案带入了开源社区，多种业务混合部署，分时共享资源的设计也非常吸引人，希望能够极大的节省基础计算成本

• Mesos 支持 Docker 容器，对我们的业务来说，避免软件环境冲突和隔离是一个真正的吸引力‍

在 2014 年初，我们将 Mesos 0.16.0 部署到了生产环境，之上运行了一个自研的任务调度器，以短任务的形式运行视频转码业务。到了年中的时候，我们发现 Chronos作为基于 Mesos 的短任务调度器已经变得比较完善，顺理成章的，我们尝试从自研的转码框架切换到 Chronos，由此开始了一段新的征程。

2. 有得有失

和使用 Mesos 的感觉不一样，Chronos 并没有 Mesos 那样稳定，以至于在后面大半年的时间里，我们使用了一些临时手段来维持稳定，直到后来有更多时间彻底解决了 Chronos 的稳定性问题，在那之后，Chronos 几乎没有再出过问题。我们对 Chronos 进行了大量开发，其中有超过 30 个 commit回馈到 Chronos 社区并被接受，而大部分则是我们内部私有的改动，不够通用，所以没有提交到社区。我们内部则为修改后的 Chronos 取名为 Sisyphus——古希腊神话中一刻不停推着石头上山的神，这也是我们为数不多的自认为取得好的项目名字！

 

伴随着 Chronos 稳定性的提高，转码业务量逐步切换到 Mesos 集群，直到 2015 年中转码团队不再维护任何生产集群；至此，Chronos 完全支撑了公司的转码生产业务。

 

在开发 Chronos 的同时，我们也上线了 Hadoop on Mesos 业务，不过由于业务量不大，以及后来 YARN/MapReduce2 的推出，我们将运行在 Mesos 上的业务全部迁移到了 YARN 集群。另一方面，Storm 在解决了一些问题之后，能够稳定的提供服务，所以我们也将 Storm 业务接入了 Mesos 集群。2014 年底我们开始了对 Marathon的调研，并且在 Marathon 之上设计和开发我们自己的 PaaS 平台 QAE（iQIYI App Engine）。

爱奇艺自研 PaaS 平台 QAE，是一个完全自助式的（除了配额申请）容器云平台，用户（公司内部开发者）只需要申请资源配额，就能在 QAE 上实现对 App 的全自助式管理，生命周期管理自不必说，其它的高级功能例如：

•  基于角色的鉴权

•  App 和容器的监控，非侵入式的接入自定义监控

•  订阅式的报警

•  根据任何监控指标自动伸缩

•  支持灰度发布、AB 测试

•  App 的高级分布策略

•  健康检查

•  日志管理

•  历史容器管理（方便排障）

•  在线控制台

•  CI/CD，自动部署等。‍‍‍

3. 从容器到微服务

经过两年多的漫长发展，QAE 羽翼渐丰，也接入了数万的在线容器，形成了良好的用户口碑，已经变成了能够吸引爱奇艺内部开发者主动采用的平台。

 

团队的下一步是乘上微服务的东风，提供更多的微服务友好的基础设施以及产品给我们的用户（公司内部开发者）。因为微服务几乎总是和容器形影不离，可能会被人误以为实现了容器云平台，自然而然的也就实现了微服务平台。在我看来，其实不然，容器仅仅只是一种软件分发、运行方式，和服务并不位于同一个维度；微服务之所以和容器形影不离，无非是容器相较于虚机来说更加易用，灵活，更加适合微小的服务来利用物理计算资源。

 

微服务带来了什么问题？

一个单体 App，如果需要部署 100 个实例来提供服务，以前基于虚机的时候，开发者需要部署 100 台虚机，不管他用什么方式，总之需要部署；要知道，爱奇艺并没有专门的应用 SRE 帮助开发者维护运行环境；而现在，如果开发者使用 QAE 来管理他的 App，那么只需要在 QAE 上部署一次即可，100 个，1000 个实例，不过是点点按钮的事情；所以，在这个例子中，对于开发者来说，将业务管理成本降低了 100 倍，太棒了！

 

但是，如果开发者决定将单体 App 拆分呢？如果拆成 100 个微服务，会变成什么情况？在 QAE 上他得部署 100 次，即使 QAE 有 App 复制/导入的功能，也依然捉襟见肘，运维成本高企；更难的是，这 100 个微服务的治理：100 个微服务的拓扑、依赖关系是什么样的？各个微服务之间的流量是怎样的？流量是否健康？微服务接口是否有完善的鉴权管理？是否能从各种维度对微服务之间的请求限流？服务调用跟踪排障？怎样快速发现，接入服务，跨数据中心的流量管控等等？

 

而这些微服务基础设施，严格来说，并非需要总是和容器联系起来，而是应该作为另一个维度的基础设施，发挥着举足轻重的作用，微服务基础设施之于微服务就像虚机和容器之于单个 App 实例一样重要。

 

微服务基础设施包括例如：API gateway，APM，链路调用跟踪，服务中心，service-mesh 等；经过一年多的发展，也已经接入了千余个内外部服务，日均访问量超过八十亿。‍

4. 深度学习云平台 Jarvis

随着公司对 AI 赋能娱乐的投入越来越大，内部 AI 算法同学也急需要一个一站式的 AI 开发运维平台来解放生产力；由于 GPU 成本不菲，公司也需要一个统一的平台来管理所有资源，以便能优化配置。深度学习云平台 Jarvis 就在这种背景下产生了，经过一年多的快速迭代；Jarvis 有力的支撑了 AI 业务的飞速发展，AI 赋能娱乐在过去一年里取得了很好的成果，例如：蒙版弹幕让弹幕更有趣，语音交互给电视果带来更好的交互体验，ZoomAI 让经典影视剧高清、鲜亮起来等等。

Jarvis 定位一站式服务平台，从训练任务管理，模型管理，到部署上线，运维，依托于底层容器平台，能够实现灵活的资源配置，避免物理机式的分配，分配后管不了的局面；此外，统一的平台，我们能做很多优化的工作，让算法同学直接享受到优化带来的速度提升。

 

在成本方面，对于推理服务，我们通过优化，将部分业务运行在 CPU 集群上，有效降低成本；对于训练任务，分布式训练任务，一些稀疏模型也直接运行在 CPU 集群上。

5. 结语

基于开源软件，特别是 Mesos，Docker/moby 等开源技术方案，结合自研的一些平台，我们在爱奇艺内部搭建了灵活的私有云平台，极大的提高了资源灵活性，降低了成本，也很好的支撑了业务的快速发展。在将来，我们希望能在成本和灵活性上进一步深耕：

1. 成本上，继续加大对异构计算的接入，目前已经支持了 CPU，GPU，FPGA，VCA 架构；

2. 精细化对业务应用做性能分析，在保证服务质量的情况下，进一步提高混合部署的能力，从而进一步降低计算成本；

3. 灵活性，基于 Mesos 和容器的弹性方案，让我们能对公有云厂商保持最低依赖，避免锁定，所以也会进一步扩大公有云资源的弹性使用。

那么，什么是Mesos？

Mesos是一个开源的集群资源和任务管理系统，通过搭建Mesos平台，用户可以构建大规模的分布式数据中心操作系统，从而极大程度地提升资源利用率并同时减少运维复杂度，让数据中心像一台PC一样简单运行。

Mesos平台由Mesos Master与Mesos Agent组成，Mesos Agent在收集本

节点上的资源（CPU、内存、网络、GPU）后，将资源统一上报给Master，Master再将资源提供给Framework。Mesos Master与Mesos Agent可以安装在通用的Linux操作系统之上以及Power Linux以及Windows系统之上。

‍Mesos采用二次调度机制，即Mesos只负责资源的调度与提供，而应用层面的调度会由Framework来完成，Framework的范围定义很广，可以是MPI应用，可以是大数据与AI平台，如Spark、Flink、Tensorflow等，也可以是容器调度平台，如Marathon等。此外，用户也可以根据自身的业务管理和运维需求，编写其它类型的Framework，这也是头条选择通过Mesos支撑其推荐平台的一个重要的原因。

Mesos提供标准的接口和SDK，开发人员在了解自身业务的基础上，通过简单地调用接口即可完成Framework的开发。Mesos+自主开发Framework的模式，更加适合于具备一定技术开发能力的企业，在国际上，如Uber、Twitter、Netlix等高新技术企业都是Mesos的资深用户。‍

然而对于市面上大多数正在尝试数字化转型的企业，他们更加需要一个可以降低数据管道构建难度和成本、简化团队Framwork开发工作、帮助产品实现快速上线的解决方案，那么Mesosphere DC/OS则更加适合。‍

Mesosphere DC/OS

基于Mesos的高可用企业级平台

Mesosphere DC/OS是以Apache Mesos为内核的分布式云操作系统，是全球首家可用于构建、部署和弹性扩展现代应用程序的高可用企业级平台。

DC/OS可以帮助您在混合云或多云架构上，轻松构建一个可运行多个关键任务的工作负载，包括Docker容器，传统应用程序（例如Java等）和分布式数据服务（例如Spark，Kafka，Cassandra，Elastic）。在我们的应用超市中，您可以一键部署和自动化运维100余种市面上最受欢迎的容器/微服务（Kubernetes, Marathon）、DevOps和SAMCK Stack应用。欢迎扫描下方二维码，了解更多。

Mesosphere DC/OS是企业级分布式云操作系统，已被全球近百家世界500强企业在生产环境中广泛使用。DC/OS 核心基于Apache Mesos实现，其本质是用于构建分布式的操作系统，为不同的计算框架提供资源，帮助企业在多云及边缘计算基础设施上，运行传统、容器编排、数据驱动型应用。扫描二维码，咨询DC/OS产品及服务详情。