本文讲的是Mesos框架对比：Marathon 和 Aurora， 【编者的话】 Marathon 和 Aurora 都能在 Mesos 集群上调度和运行常驻服务。本文比较了两个框架的不同和优劣。

问题

Marathon  框架和  Aurora  框架都能在  Mesos  集群上调度和运行常驻服务。我的问题是：

1. 两个框架有哪些不同？我费了半天劲，也没有找到能够很好地解释二者的关键区别的资料。
2. 任何程序或代码，只要能在 Linux 系统上正常地运行，就能被这些框架调度和运行，这么说对吗？ Marathon 的开发者说 Marathon 能够运行“可在 shell 中执行”的任何程序或代码。不过，这话有点空洞，让人琢磨不透，:)

第 1 个解答

声明：我是 Apache Aurora 的副总裁，担任 Twitter 公司 Aurora 团队的技术负责人也差不多五年了。我的观点或许有片面之处，纯属个人观点，与 Twitter 公司或者 Apache 基金会无关。

任何程序或代码，只要能在 Linux 系统上正常地运行，就能被这些框架调度和运行，这么说对吗？ Marathon 的开发者说 Marathon 能够运行“可在 shell 中执行”的任何程序或代码。不过，这话有点空洞，让人琢磨不透，:)

完全正确。  Marathon 和 Aurora 框架的本质就是调度集群的资源，执行用户提交的 Shell 代码。

两个框架有哪些不同？我费了半天劲，也没有找到能够很好地解释二者的关键区别的资料。

确实， Aurora 和 Marathon 提供了相似的功能特性，都属于“常驻服务的调度器”。换句话说，用户提交如何运行常驻服务的脚本代码，两个框架将尽全力保证常驻服务的持续运行。

下面粗略地谈谈两个框架的不同，包括每个框架的缺陷。我可以负责任地说，框架的开发者非常了解这些缺陷，正在设法修正。

易用程度

安装 Aurora ，给人感觉好似在拓荒，不容易。 用户要控制和使用 Aurora ，要么使用命令行程序，要么使用某个 thrift 客户端调用 Aurora 对外暴露的 thrift API （正在开发 REST API ，目前还不可用）。 用户会感到犯难，因为他们得使用领域特定语言（ DSL ）配置 Aurora 。这种做法的好处是方便分享配置的模板和通用模式。

与之相比， Marathon 很容易上手，用户很快就能运行一个 “Hello World”服务。 Marathon 提供非常棒的文档，描述多种环境下如何运行一个服务。Marathon 提供 REST API ，方便用户编写调用 Marathon 的定制工具。 Marathon 使用 JSON 作为配置格式，容易上手，但有为了使用而使用之嫌。

目标用户

Aurora 一直是为大型工程组织而而设计的。 在 Twitter 公司，计算机集群包含数万台机器，几百个工程师在使用它，它也是支撑 Twitter 业务的关键。这势必要求保证集群系统的扩展性、稳定性和安全性。因此，我们只会为 Aurora 添加能够在生产环境中扩展的特性（例如，我们把 Aurora 的 Docker 支持标记为一个 beta 特性，因为 Docker 本身以及 Mesos-Docker 进程都存在需要解决的问题）。 Aurora 还提供了抢占等功能，从而支持在同一个集群中混合部署关键业务服务和原型、实验任务。

很难评价 Marathon 的扩展性。 Marathon 总是很快推出新特性（ 例如， 添加 Docker 支持），从实践的角度，感觉太过冒进。这不能总是归因于 Marathon ，其它各层也难逃干系。 Marathon 没有提供抢占的功能。

所有权

重点是搞清楚一个项目的所有权和管治模式。这不仅决定了项目的开放性，更决定了哪些人和哪些公司拥有否定决议的权力。

• Marathon 的拥有者是 Mesosphere 公司

这是好事还是坏事，不同的人有不同的看法。首先，用户可以付费购买 Marathon 的支持和额外功能；其次， Marathon 项目存在商业销售， Mesosphere 公司的商业利益最终决定该项目的走向。

• Aurora 的拥有者是 Apache 基金会（ ASF ）

Aurora 项目采用 ASF 的管治模式，完全由社区驱动。 Aurora 没有付费客户，现在也没有软件商店。

小结  如果你是一个新手，准备在 Mesos 上运行服务，我推荐使用 Marathon ，既容易上手，又方便融入 Mesos 生态系统。如果你准备为公司构建具有战略意义的私有云平台，敬请考虑使用 Aurora ，因为它本就是为此而生，而且已经在实践中得到证明。

第 2 个解答

两个框架我都用过，下面是我的经验总结。

Aurora

[+] 还能调度周期性任务
[+] 细粒度、可扩展、基于文件的配置
[+] 支持命名空间，所以多个环境可以共存
[-] 只读的用户界面，没有官方 API
[~] 文件配置和命令行执行的模式很麻烦（好处是更容易扩充功能集）

Marathon

[+] 很容易安装和使用
[+] 提供用户控制界面和扩展功能的 API （有些 API 功能目前都没包含在用户界面中） 
[+] 监听 API 调用的事件总线
[-] 只能处理常驻任务
[-] 部署-运行-清理三个步骤的区分不是很清晰，必须写在一行脚本里

即使 Aurora 的功能更强，我还是愿意选择使用 Marathon ，因为 Aurora 太复杂，没有用户控制界面，没有提供 API 。

第 3 个解答

我使用 Marathon 的经验更多些。

务虚：

• 相对而言， Marathon 是经过检验的产品，已经用在 AirBnB 的生产环境中。 Aurora 只是一个处于早期阶段的 Apache 项目。
• 两个框架都开源且开发活跃。大家既可以请求官方代码库合并自己的贡献，又可以指出官方代码库存在的问题。

务实：

• Marathon 不能调度批处理任务和轮转任务
• Marathon ( 0.8.x ) 有友好的用户界面，更好的任务执行状态监控

至于你的第二个问题，用户可以运行任何命令或者 Docker 容器， Mesos 保证了资源的隔离。假定你的机群中 50% 是 CentOS 节点， 50% 是 Ubuntu 节点。如果你请求执行一个任务  apt-get  ，有 50% 的可能会无法执行。 Mesos 和 Marathon 对节点的实际系统一无所知。

第 4 个解答

声明：我只有 Marathon 的使用经验，没用过 Aurora 。  

关于第一个问题：从本质上说， Apache Aurora 相当于 Marathon Chronos ，即它能够调度和执行常驻服务和轮转（批处理）任务。请参考  Aurora 用户指南

关于第二个问题：是的，任何程序或代码都能被两个框架调度和执行能够。目前用 cgroups 和 Docker 运行程序，你也可以 指定自己的容器机制

原文链接：Marathon vs Aurora and their purposes（翻译：柳泉波）

=======================

译者介绍

柳泉波，读书喝茶踢球写程序。

原文发布时间为：2015-05-10

本文作者：bnuhero

本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。

原文标题：Mesos框架对比：Marathon 和 Aurora