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（翻译：柳泉波）

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

译者介绍

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

来自：http://dockone.io/article/370