在Mesos上部署任务有几种做法，一种是自行开发框架，一种是利用已有的框架。框架在Mesos是专用术语，由于Mesos的二级调度机制，具体任务的调度均由框架来处理。因此部署现有的平台或者引擎到Mesos上，均需要开发对应的框架，例如Hadoop，Spark，Kafka，等等。框架跟Mesos的交互关系如下图所示意：
Kafka的框架在Mesos中的交互如图所示：
框架有2个任务，一个是调度Scheduler，一个是执行Executor。Scheduler的核心任务是从Mesos申请和释放资源，然后进行内部任务的调度。如果打算在Mesos上部署各种长期运行的无状态低延迟类服务，例如中间件，微服务架构，等等，或者希望基于Mesos提供数据中心统一任务管理系统，就需要针对这类长期运行的服务开发相关的框架，因此这是一个普遍需求，目前Mesos上有3种框架支持这种服务：Marathon，Aurora和Singularity。
Marathon是第一个在Mesos上支持长期运行服务的框架(也支持周期性调度执行的任务)。Marathon是Meosphere公司主推的套件DCOS(意思是数据中心操作系统，这名字起得好)的重要组件，由于DCOS是商业产品，因此未来Marathon是否会商业化还很难说。这也是目前不少公司(如Airbnb，Paypal)从Marathon切换到Aurora的原因之一。就功能而言，Marathon提供容错，健康监测(由服务自行提供健康检查URL)，回滚，滚动升级，以及服务发现(利用额外组件Mesos-DNS)和均衡(利用修改的HAProxy)。
Marathon核心架构是基于Scala和Akka Actor实现的，因此Marathon的高可用设计完全基于Akka集群。在调度策略上，没有看到Marathon在这上面有特别的考虑，基本上按照FIFO队列来进行。
总体而言，Marathon的设计很简单，只提供了必要的功能，但是由于Marathon的界面良好，因此容易上手，初期尝试Mesos做容器云或者微服务框架的公司大都会选择Marathon作为他们的入门选择。不过，本人并不建议不熟悉Scala语言的团队轻易采用Marathon，不论采用什么框架，如果对于核心组件缺乏控制力，这比什么都不用更糟糕。
Aurora是Twitter推出的框架，相比Marathon，Aurora的功能要强大许多，但由于缺乏任何可视化界面，因此并不适合对Mesos一无所知的团队来入门。为了更好地支持容错和回滚，Aurora采用高可用存储来记录状态，包含任务的配置信息，对资源的需求配额信息，以及Mesos的主机属性。高可用存储采用基于Paxos协议的复制状态机，本公众号对这点如何设计已经多次做出说明。Aurora另一个强大之处在于对SLA的支持，默认情况下，对于服务型应用SLA处于开启状态，Aurora提供相应的Metric工具定期收集服务质量数据。这些数据包含：Platform Uptime，如果平台发生错误导致任务被重新调度，或者手工触发任务的重新调度，都会导致该数据重新计算；Job Uptime，这很好理解；MTTA，表示待分配的平均时间，用来记录某任务分配之前的平均等待时间，该Metric有许多维度的计数，包含CPU，内存，磁盘，这些数据会用来做Aurora的调度器装箱算法依据使用；MTTR，表示待分配的任务进入运行状态前等待的平均时间，该Metric跟MTTA类似，只不过记录的时间点在于任务进入运行状态而不是分配状态。此外，Aurora还支持任务抢占，尽管抢占作为Mesos的重要改进属性，已经在MESOS-155的Issue上跟进，但那是Mesos内核层面的支持，而Aurora则是在框架这一层支持把优先权低的任务杀掉然后部署高优先权任务。抢占是Borg区分于其余数据中心操作系统的关键特性之一。在调度算法上，Aurora采用基于CPU的公平调度算法，对于每个任务来说，内存和存储尺寸是硬限制，但CPU是软隔离，就是说每100毫秒就需要针对任务对CPU的使用情况进行评估，如果超过了任务开始使用所要求的CPU配额，那么就会对之后的CPU使用采取限制，因此从这点来看，Aurora是一个以提高集群利用率为设计目标之一的系统。Aurora文档很少，但却是最值得深入研究的Mesos框架，本公众号会在以后给出Aurora的深入细节剖析。
Singularity是企业软件咨询公司HubSpot推出的方案，初衷本是打算封装Marathon和Chronous等来提供统一框架，但后来HubSpot放弃了整合Marathon而选择自行实现(从另一个角度来看，开发这类框架并不是多么复杂的事情)。Singularity提供部署，健康监测(由部署的服务自行提供健康检查URL)，回滚，以及服务调度。在调度功能上，Singularity目前还比较弱，支持4种调度策略：
贪婪：尽可能占据所有分配到的资源
分离：避免同一个部署请求的多个实例在同一个Slave上
主机分离：避免同一个部署请求的多个实例在同一个主机上
乐观：同一个部署请求多个实例可能会部署在一起
Singularity在未来打算改进资源调度功能。除了部署，回滚，调度之外，Singularity的一个值得称道的设计在于记录部署的历史信息，短时间内的部署存放在Zookeeper内，而长期部署信息则存放在MySQL里便于运维进行历史信息跟踪。Singularity设计简单，但却比Marathon功能更为丰富，适合希望采用Mesos的入门级团队使用。
除了以上三种框架，Netflix如何应用Mesos的经验也是值得所有公司学习的，这不光在于Netflix是为数不多的几家基于IaaS的大数据公司之一，还在于Netflix从11年开始就致力于自身的服务治理，推出完整的NetflixOSS微服务套件。从15年开始，Netflix把NetflixOSS微服务体系搬迁到Mesos平台以更好的利用统一资源管理体系。他们的主要工作被称为一个叫Titan的调度系统，由于尚且没有开源因此我们还无法得知具体细节，然而Titan的核心组件Fenzo刚刚在过去的MesosCon 2015上正式公开，它本身并不是一个框架，只是一个资源调度库。Fenzo本质是一个装箱(Bin Packing)算法的实现，可以放到任何Mesos框架中使用。装箱(Bin Packing)，既把箱子装入容器是工业中常遇到的算法问题，是经典的组合优化问题。设有许多具有同样结构和负荷的箱子B1，B2，… ，每个箱子的负荷为C ，今有n个负荷为w_j的物品J1，J2，…，Jn需要装入箱内，0<w_j<C，装箱问题就是指寻找一种方法，使得能以最小数量的箱子数将J1，J2，…，Jn全部装入箱内。装箱是个NP完全问题，因此常用启发式求解，例如First Fitness算法，Fenzo就是采用了这种设计。Fenzo的装箱算法需要考虑CPU，内存，带宽等因素，可以以单一维度来计算装箱Fitness值，也可以以它们的组合来计算Fitness。组合的时候，目前权重是一样的，使用者也可以插件形式实现自己的权重组合。Fenzo使用软硬两种限制对任务进行分配，软限制是在Fitness值打分基础之上的贪心策略，硬限制则是任务所必须的资源要求。在调度时，首先计算出硬限制所需要的资源，如果系统可以满足需求，那么就会调用Fitness公式得出Fitness值，然后计算软限制所能占用的资源，最终分配资源是在两者之间做加权平均。通过对硬限制的指定，可以在调度时融合任务对资源的局部性要求，再加上插件机制，因此，你可以利用Fenzo任意调整调度算法。
Fenzo的另一个功能是Auto Scaling，这可以是根据规则来做Scaling操作，也可以根据算法，在Netflix内部，后者需要结合Scryer预测机制来决定是否自动扩容，算法目前基于傅立叶变换或者线性回归两种选择，这已超出本文介绍的范围。
因此，Fenzo是一个非常好的Mesos框架SDK，如果你想用它来改进Singularity，或者Aurora，乃至实现自己的Mesos框架，Fenzo都是一个出色的工具。Fenzo仍然在演进之中，例如对SLA的支持就在计划列表。
在Mesos生态系统里还有一些项目值得注意：
首先有一个叫做compose-executor。我们知道在Kubernetes里有一个优秀的设计叫做Pod，Kubernetes的负责人Brendan Burns在今年DockerCon上演讲曾把Pod当作一种架构设计模式，而compose-executor就是给Mesos增加Pod的功能。
Autodesk作为老牌的CAD公司，在云计算上面也经验颇为丰富。他们推出Ochopod项目负责Docker在Mesos(通过Marathon)和Kubernetes上进行编排，其目的是向容器开发者屏蔽Mesos和Kubernetes的使用细节。
Microservice-infrastructure，Apollo分别是Cisco和Capgemini在今年上半年推出的微服务架构PaaS项目。它们本身并没有包含任何代码，而是通过利用所有的开源组件，包括服务发现如etcd和consul，SDN如Weave和Calico(3层交换，本号以后会介绍)，IaaS的管理如Terraform以及资源管理和调度(目前都是通过Mesos和Marathon)来打包形成完整的Docker PaaS平台。
目前，Mesos 0.23版本已经有了2个新功能：动态资源保留和持久化卷管理。前者可以让Mesos Slave在启动时无需指定静态资源，而在运行中通过API来指定资源，后者则允许Mesos框架创建磁盘持久化卷服务，因此在Mesos上部署有状态的服务也成为了可能，例如MySQL，ElasticSearch，等等。那么在Mesos上部署这类业务有什么意义呢？主要还是在于借助Mesos的资源管理框架方便这类业务的部署，扩容，容错和版本管理。但这并不表明以Mesos为基础就可以随心所欲地提供这类后端服务(BaaS)，在当前没有任何针对操作系统内核调度器的修改的前提下，直接以容器为载体提供BaaS会导致高IO的服务质量无法得到保证，除非是在SmartOS Zone这样的超级容器内部署，否则反而基于虚拟机的解决方案由于更好的IO隔离而表现更好。为什么RDS这类BaaS服务不适合直接部署在Linux集群的Mesos上，这涉及到操作系统内核的调度算法，这方面的话题本号以后会逐渐给出分析。
