Marathon 框架和 Aurora 框架在Mesos的应用场景存在差异

Marathon 框架和 Aurora 框架都能在 Mesos 集群上调度和运行常驻服务。后者同样具有任务型业务调度能力。功能角度类似Marathon和Chronos的角色。

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 没有付费客户，现在也没有软件商店。