Mesos 已死，容器永生

“回顾过去，我认为 Mesos 的失败是种必然。”

4 月 7 日，Apache 宣布开始投票进程，准备将曾火极一时的 Mesos 项目移至Attic下，保存为“只读”状态。Attic 是 Apache 软件基金会为已终止项目提供的一种解决方案，此举意味着 Mesos 正式进入项目“退休”阶段。

Mesos 诞生于 2009 年，最初是伯克利大学的一个研究项目。它曾为分布式资源管理做出过一系列前沿贡献，据 Mesosphere/D2IQ 联合创始人回忆，“我们提出的 Mesos 是一套可跨越多个不同集群计算框架（类似于 Hadoop 与 MPI）实现商用集群共享的平台。”它的诞生甚至比 YARN 还早了几年，并于 2010 年很快被应用到 Twitter，成为 Twitter 自定义 PaaS 的实现基础，管理着 Twitter 超过 30,0000 台服务器上的应用部署。随后其他公司纷至沓来，比如 Airbnb、eBay 和 Netflix 等等，Mesos 也因此火极一时。

但很遗憾的是，现在已经到了它退役的时候。不过短短数年，我们再次见证了一个知名技术项目的兴起和衰落。

响应时代的召唤

Mesos 项目跟起源于 Google 的数据中心资源管理系统 Borg 一样，目的是弄清楚是否必须重建 Google 的超大规模计算专有架构。

同时，作为世界上最成功的社交媒体巨头之一，创立于 2006 年的 Twitter 也以其庞大的生产集群规模（万级别节点）而备受关注。Twitter 每天需要管理几亿条推文，急需开发一个类似的资源管理系统来帮助他们摆脱可怕的“失败之鲸”（如上图所示）。后来他们注意到加州大学伯克利分校 AMPLab 正在开发的名为 Mesos 的项目，这个项目的负责人是 Ben Hindman，Ben 是加州大学伯克利分校的博士研究生。后来 Ben Hindman 加入了 Twitter，负责开发和部署 Mesos。

Mesos 的两级调度架构很好的解决了 Twitter 面临的可伸缩性和性能上的挑战，“失败之鲸”逐渐成为往事。Twitter 的这个 PaaS 平台解决方案，后来以 Apache Aurora 的名号转为开源。

在海量数据的挑战下，Twitter 基础设施架构的演进过程，一直以来都是全世界技术公司眼中的标杆案例。在 2010 年之后，大量企业跟进了 Mesos，包括 Uber、Airbnb、eBay、Netflix，以及国内的携程、去哪儿等一众企业。

可能是计算机历史上最短的技术战争

Mesos 的创造者 Ben Hindman 等于 2013 年建立了名叫 Mesosphere 的初创公司，旨在打造一套生产级商业化 Mesos 平台。最终成果是一套名为 DC/OS（数据中心操作系统）的管理平台，号称将成为集群服务器的主控系统。他们还打造了 Marathon，这款工作负载编排平台明显是将 Kubernetes 设定成了竞争对手。Mesosphere 的目标是将数据中心改造成具有凝聚力的计算复合体，并在中心内部提供一套新型运营环境。

但谁也没想到，几年后 Docker 成为了改变游戏规则的人。在 2015 年的短短几个月里，Docker 公司凭借一款非凡的新型工具彻底颠覆了服务器工作负载自动化市场。从那时起，数据中心基础设施不再单纯侧重于服务器，而是以工作负载为中心——强调负载的可移植性、灵活性与安全完整性。

2015 年 6 月 22 日，作为回馈开源社区热情支持的一份谢礼，Docker 将基于 Linux 的软件容器包装格式捐赠给 Linux 基金会，并正式定名为开放容器倡议（OCI）。但就在同一周，谷歌闪电出手，将 Kubernetes 项目的管理权移交给了另一个 Linux 基金会项目：云原生计算基金会（CNCF）。

之后，Docker 公司当初想培养的这片市场就已经被很多人称为“Kubernetes 生态系统”。在当时的工作流编排领域，主要有三家竞争参与者：Kubernetes，也源自谷歌内部原名为“Borg”的项目；Docker Swarm，已经开始与商业 Docker Enterprise 产品共同交付的集群管理器；Apache Mesos，用于“非镜像工作负载”（包括 Hadoop 与 Spark 大数据系统等）的服务器集群调度与管理方案。

起初，Mesos 代理负责在各组件之间分配工作负载。但不久之后，Kubernetes 也在这一领域有所建树。Mesosphere 的一部分技术人员认为这两款编排工具完全可以并行存在，也有人觉得可以把 Kubernetes 环境作为 Mesos 模板的工作场景。

但想象总是美好的。

面对 Kubernetes 无可匹敌的市场优势地位，仅仅两年，Kuberneters 就胜局已定。经历了计算发展史上最“高效”的对抗之后，Docker 与 Mesosphere 也只能认怂、转而寻求新的发展方向。

Mesosphere 于 2019 年 8 月正式更名为 D2IQ（内部员工将其称为「Day 2-IQ」），推进品牌重塑。他们继续开发所谓“Mesosphere DC/OS”产品。但 Mesosphere 所提供的诸如 Marathon 等上层解决方案在其产品线路的位置已经被 Ksphere 取代。Ksphere 是一款用于管理及分配容器化工作负载的组件，其中也包括仍然沿用原名的 Mesphere Kubernetes Engine（MKE）。Mesosphere 于 2020 年 10 月停止支持 Mesos / Marathon。

“Mesos 的失败是种必然”

如果真的存在技术“生态系统”，那么这座代表生态的高山从来就容不下二虎。超市的商品陈列可以兼容不同品牌，但跟这种商品不同的是，计算机技术领域就没有哪两种产品能够长期保持双头垄断地位。

技术专家张磊在2016年容器技术年终盘点文章里总结道：

“社区”两个字，竟成了 Mesos 生态的命门。在 Docker 公司煞费苦心在社区争取每一个用户和粉丝、Google 公司放下身段把 Github 作为一线阵地，用 Kubernetes 全力输出技术理念的时候，一旦错失了先机，哪怕有一身本事如 Mesos 项目，也只能望用户而心叹。这正是目前 Mesos 生态系统在容器圈子表现的不够强势的重要原因。当然，既然实力强劲，Mesos 生态在工业界中的案例还是数不甚数，除了 Marathon 框架，Mesosphere 公司重点维护的 DC/OS 项目其实能够提供并不逊于 Kubernetes 的各项容器编排和管理能力，不可谓不强大。但是社区表现不力，使得 Mesos 生态错失了成为容器圈的“buzz word”（热词）的机会。

2019 年，曾作为 Mesos“代言人”的 Twitter 华丽丽的宣布其基础设施将从 Mesos 全面转向 Kubernetes：“我们认为，使用 Kubernetes 项目作为 Twitter 公司基础设施向前演进的核心依赖，将会是一个正确的选择”。

昨天，Apache 提交“将 Mesos 移至 Attic”的进程之后，众多开发者对 Mesos 的开发时光予以了怀念。

作为 Mesos 项目的 PMC 成员，Ben Hindman在 Hackernews 上总结说：

“回顾过去，我认为 Mesos 的失败是种必然，原因有以下几点：

• Kubernetes 拥有后发优势，承载着谷歌十多年来在构建此类系统方面积累起的丰富经验与知识。Mesos 则源自技术研究，随后虽然得到了 Twitter 的实际应用，但负责项目的工程师们（包括我本人）并不具备构建集群管理系统的经验。我们在探索当中学到了很多，回头来看，如果能有第二次机会、我们肯定会认真调整设计思路。

• Mesos 这个项目做得有点‘小气’，导致社区变得支离破碎。为了正常使用，新用户们不得不付出大量重复劳动。很明显，大多数用户只想运行服务、作业与 cron 作业，但 Mesos 的设计思路并不是这样。大家必须得从一系列生态系统调度程序（包括 Aurora、Marathon、Chronos 以及 Singularity 等）中进行选择，或者自主构建某些内容。

• Mesosphere 是一家靠风险投资支持的初创企业，后来则由 Twitter 接手赞助项目发展。正因为如此，我们必须找到一种能够产生收益的商业模式，这就导致我们与用户乃至其他供应商之间产生了紧张关系、甚至是严重的不信任感。相反，谷歌/k8s 不要求任何直接产出，反而可以不断投入大量资金与丰富的人才资源，由此带来的技术成果单靠增强谷歌自己的云计算业务就足以值回票价。”

他总结道：“即使没有出现 k8s，Mesos 也很可能被其他开箱即用类方案所压制。必须承认，Mesos 很难像其他开源项目那样建立起供应商与贡献者团结一致的友好氛围。随着时间推移，Mesos 也许会朝着这个方向发展，但目前还看不到希望。”

曾担任 Mesosphere 架构师和技术总监的 Yujie 博士也跟帖表示：

“Ben 说得很对。我也是 Mesos 项目的长期 PMC 与提交者之一。纵观整段历程，我吸取的教训之一，就是如果从初始设计论文来看，Mesos 的两级式资源分配机制完全就是为运行批量工作负载（例如 spark、mpi 等）所设计。使用它来运行长期服务实际上是后来才做出的改变。我们最终发现，由于第二级调度程序缺少集群的完整视图且第一级调度程序没有足够的信息做出正确决策，我们需要对第一级调度算法进行大量调整才能确保公平性。而其中乐观型解决方案在本质上，其实就是对 Kubernetes 模型的复制。

Kubernetes 成功的另一个原因，可能在于 golang 生态系统。在 Mesos 中，由于采用独特的线程模型，我们耗费了大量精力在 C++中构建基础 HTTP 层。如果能够重新选择，真希望能把这些时间花在开发点真实有用的功能上。”

容器技术的快速发展，得益于开源软件社区的成功。如今，Mesos 社区已经逐渐淡去，但容器还依然处于技术世界的中心，正所谓“Mesos 已死，容器永生”。

延伸阅读：

https://www.infoq.cn/article/interpretation-of-2016-container

https://www.infoq.cn/article/672*aX6aQ1FB0QT1RRAM

https://news.ycombinator.com/item?id=26713082