| 最近，有一个叫 Marathon的项目进行了开源，它的设计宗旨就是让用户在同一组服务器之上，更智能地运行多种应用程序和服务——Hadoop、Storm，甚至一个标准的Web应用。Marathon出自于一家初创公司 Mesosphere之手，这家公司主要就是想构建一个数据中心操作系统，不过这个系统是运行在 Mesos集群管理软件之上，这也是 Twitter基础设施的重要组成部分。该公司的联合创始人是前Airbnb的工程师Florian Leibert(也曾在Twitter工作过)和Tobias Knaup。 Marathon只不过占据了Mesosphere的一小部分，但是Leibert表示它很重要且有着非常大的吸引力。就目前而言，云计算和大数据的发展趋势已经从巩固阶段跳转到问题的解决阶段，未来可能需要多个分布式系统去处理那些特定的任务。 在阐述Marathon之前，我们应该了解一下它的发展历程(点击查看大图)：
网格计算将何去何从？ 其实早在“云计算”的概念泛滥之前，像“网格计算”和“集群计算”这些专业术语与“请求式”联系的更紧密一些。思路也很简单：很多组织机构(比如银行和研究所)都有着大量的服务器，他们希望尽可能高效地利用这些机器，那么通常也意味着这些服务器会形成一个资源池(当然也可以称之为“云”)，进而确保每一个应用程序或者任务都能得到它所需要的资源，而且还是按需分配。不再像以往的模式——为每个应用程序配置一个小集群，然后使用一个大集群托管所有的东西，这也是Platform Computing( 在2012年3月被 IBM收购)几年前对其私有云的定位。 然而，这一概念从未真正进入到主流企业之中，因为这些企业在很大程度上会选择虚拟服务器，而且倾向于考虑亚马逊EC2模式的虚拟服务器来配置自家的私有云。不过随着分布式计算的发展，尤其是Hadoop等云平台的出现，大大改变了互联网企业的IT环境，那些通用的“网格计算”或者“集群计算”的理念再次得到了回归。 不可否认，其中有一部分原因在于，管理不同的IT环境已经变得十分的复杂：这里运行的是分布式的Web应用，那边还有一个Hadoop集群，甚至某个角落的服务器上还跑着Storm或者Spark，冷不防的你就有了3个集群，而且每一个都需要维护。当然这些复杂性的问题不会出现在Google、Facebook或者Twitter的管理者面前，毕竟他们玩的就是 “效率和自动化”的游戏。
Mesos的架构 这些互联网“巨头”都有自己的软件来处理越来越多的工作负载：谷歌使用的是Borg(尽管该公司已经发表了一个尚未部署的Omega系统的研究论文);Twitter使用的就是Mesos;Facebook的系统称之为Corona(主要用于 Hadoop的工作负载设计，但该公司希望扩展到多种框架上)。 连线的Cade Metz撰写了一篇博文，其中详细介绍了Mesos、Borg和Omega，读者可以 点击阅读。当然，如果和硬件关联不上，那么类似 Mesos这样的软件毫无价值，即使很多大公司都很喜欢这个系统。Airbnb是一个Mesos的忠实用户，他们使用Mesos来管理完全运行在AWS上的工作负载。 |
