此时，可以通过界面或者 REST API 来创建一个应用，Marathon 会保持该应用的持续运行。
Mesos基本原理与架构
首先，Mesos自身只是一个资源调度框架，并非一整套完整的应用管理平台，本身是不能干活的。但是它可以比较容易的跟各种应用管理或者中间件平台整合，一起工作，提高资源使用效率。
架构
master-slave 架构，master 使用 zookeeper 来做 HA。
master 单独运行在管理节点上，slave 运行在各个计算任务节点上。 各种具体任务的管理平台，即 framework 跟 master 交互，来申请资源。
基本单元
master
负责整体的资源调度和逻辑控制。
slave
负责汇报本节点上的资源给 master，并负责隔离资源来执行具体的任务。 隔离机制当然就是各种容器机制了。
framework
framework 是实际干活的，包括两个主要组件：
? ?
scheduler：注册到主节点，等待分配资源；
executor：在 slave 节点上执行本framework 的任务。
framework 分两种：一种是对资源需求可以 scale up 或者 down 的（Hadoop、Spark）；一种是对资源需求大小是固定的（MPI）。
调度
对于一个资源调度框架来说，最核心的就是调度机制，怎么能快速高效的完成对某个 framework 资源的分配（最好是能猜到它的实际需求）。
两层调度算法：
master 先调度一大块资源给某个 framework，framework 自己再实现内部的细粒度调度。
调度机制支持插件。默认是 DRF。
基本调度过程
调度通过 offer 方式交互：
? ?
master 提供一个 offer（一组资源）给 framework；
framework 可以决定要不要，如果接受的话，返回一个描述，说明自己希望如何使用和分配这些资源（可以说明只希望使用部分资源，则多出来的会被 master 收回）；
? master 则根据 framework 的分配情况发送给 slave，以使用 framework 的 executor 来按照分配的资源策略执行任务。
过滤器
framework 可以通过过滤器机制告诉 master 它的资源偏好，比如希望分配过来的 offer 有哪个资源，或者至少有多少资源。 主要是为了加速资源分配的交互过程。
回头机制
master 可以通过回收计算节点上的任务来动态调整长期任务和短期任务的分布。
HA
master
master 节点存在单点失效问题，所以肯定要上 HA，目前主要是使用zookpeer来热备份。
同时 master 节点可以通过 slave 和 framework 发来的消息重建内部状态（具体能有多快呢？这里不使用数据库可能是避免引入复杂度。）。
framework 通知
framework 中相关的失效，master 将发给它的 scheduler 来通知。
Mesos配置项解析
Mesos的 配置项 可以通过启动时候传递参数或者配置目录下文件的方式给出（推荐方式，一目了然）。
分为三种类型：通用项（master 和 slave 都支持），只有 master 支持的，以及只有 slave 支持的。
通用项
? ?
--ip=VALUE 监听的 IP 地址
--firewall_rules=VALUE endpoint 防火墙规则，VALUE 可以是 JSON 格式或者存有
JSON 格式的文件路径。
? ? ? ?
--log_dir=VALUE 日志文件路径，默认不存储日志到本地 --logbufsecs=VALUE buffer 多少秒的日志，然后写入本地 --logging_level=VALUE 日志记录的最低级别
--port=VALUE 监听的端口，master 默认是 5050，slave 默认是 5051。
master 专属配置项
? ? ?
--quorum=VALUE 必备项，使用基于 replicated-Log 的注册表时，复制的个数 --work_dir=VALUE 必备项，注册表持久化信息存储位置
--zk=VALUE 必备项，zookeepr的接口地址，支持多个地址，之间用逗号隔离，可以为
文件路径
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
--acls=VALUE ACL 规则或所在文件
--allocation_interval=VALUE 执行 allocation 的间隔，默认为 1sec --allocator=VALUE 分配机制，默认为HierarchicalDRF --[no-]authenticate 是否允许非认证过的 framework 注册 --[no-]authenticate_slaves 是否允许非认证过的 slaves 注册
--authenticators=VALUE 对 framework 或 salves 进行认证时的实现机制 --cluster=VALUE 集群别名
--credentials=VALUE 存储加密后凭证的文件的路径 --external_log_file=VALUE 采用外部的日志文件
--framework_sorter=VALUE 给定 framework 之间的资源分配策略 --hooks=VALUE master 中安装的 hook 模块
--hostname=VALUE master 节点使用的主机名，不配置则从系统中获取 --[no-]log_auto_initialize 是否自动初始化注册表需要的 replicated 日志 --modules=VALUE 要加载的模块，支持文件路径或者 JSON --offer_timeout=VALUE offer 撤销的超时
--rate_limits=VALUE framework 的速率限制，比如qps
--recovery_slave_removal_limit=VALUE 限制注册表恢复后可以移除或停止的
slave 数目，超出后 master 会失败，默认是 100%
?
--slave_removal_rate_limit=VALUE slave 没有完成健康度检查时候被移除的速率
上限，例如 1/10mins 代表每十分钟最多有一个
?
--registry=VALUE 注册表的持久化策略，默认为 replicated_log，还可以
为 in_memory
? ? ? ? ? ?
--registry_fetch_timeout=VALUE 访问注册表失败超时 --registry_store_timeout=VALUE 存储注册表失败超时
--[no-]registry_strict 是否按照注册表中持久化信息执行操作，默认为 false --roles=VALUE 集群中 framework 可以所属的分配角色
--[no-]root_submissions root 是否可以提交 framework，默认为 true
--slave_reregister_timeout=VALUE 新的 lead master 节点选举出来后，多久之内
所有的 slave 需要注册，超时的 salve 将被移除并关闭，默认为 10mins
? ?
--user_sorter=VALUE 在用户之间分配资源的策略，默认为drf --webui_dir=VALUE webui实现的文件目录所在，默认
为 /usr/local/share/mesos/webui
?
--weights=VALUE 各个角色的权重