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 本