共计 4822 个字符，预计需要花费 13 分钟才能阅读完成。
这期内容当中丸趣 TV 小编将会给大家带来有关 Mesos 如何理解，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
听过不少人在讨论 Mesos，然而并不是很明白 Mesos 到底能够解决什么问题，使用场景是怎样的，周伟涛（国内较早一批接触使用 Docker，Mesos 等技术的开发者）用一句话形容它，Mesos 能够管理每台机器的 CPU，内存等资源，让你像操纵单个资源池一样来操纵整个数据中心。
Apache Mesos 是一个集群管理器，提供了有效的、跨分布式应用或框架的资源隔离和共享，可以运行 Hadoop、MPI、Hypertable、Spark。
13 个问题带你深入了解 Mesos
（问题来自 OSChina 开源中国社区第 100 期高手问答 —— Apache Mesos）
Q1：对大多数人来说还不知道什么是 Mesos，请介绍下他是干什么的，有什么用，怎么用？
A1：你好，Mesos 在国内的资料目前虽然不多，但是你随便百度，谷歌一下，还是有一些的。这里我想拿一个例子来解释 Mesos，假设某公司需要频繁进行大数据计算，该任务运行时需要 N 多 CPU 和内存，为了满足这个需求，我们有两种思路：
思路一）使用小型机，单机即可为任务提供足够的资源；
思路二）分布式计算，即提供一批普通配置的机器（计算节点），也就是集群，将计算任务拆分到各机器上计算，然后汇总结果。
思路二是当前正在流行的做法，这种方式的优点不再多说。为了达到思路二的要求，我们需要建立数据中心（集群）。进一步，为了充分利用数据中心（集群）的资源（譬如为不同的任务分配不同资源，按任务优先级分配资源等），我们就需要一个工具来进行整个数据中心资源的管理、分配等，这个工具就是 Mesos。与 Mesos 类似的工具还有 YARN.
除此之外，Mesos 不仅为计算任务 Offer 资源，它也支持运行长时任务（譬如 Web 应用）。目前国外好多互联网公司都在使用 Mesos 来作为它们的集群管理工具，这里是一个 Powered by Mesos list：https://mesos.apache.org/documentation/latest/powered-by-mesos/
Q2：我们现在用 Cloudera 这套，能简单介绍下 Mesos 和 Cloudera 的差别吗？
A2：Mesos 的主要目标就是去帮助管理不同框架（或者应用栈）间的集群资源。比如说，有一个业务需要在同一个物理集群上同时运行 Hadoop，Storm 及 Spark。这种情况下，现有的调度器是无法完成跨框架间的如此细粒度的资源共享的。Hadoop 的 YARN 调度器是一个中央调度器，它可以允许多个框架 运行在一个集群里。
但是，要使用框架特定的算法或者调度策略的话就变得很难了，因为多个框架间只有一种调度算法。比如说，MPI 使用的是组调度算法，而 Spark 用的是延迟调度。它们两个同时运行在一个集群上会导致供求关系的冲突。还有一个办法就是将集群物理拆分成多个小的集群，然后将不同的框架独立地 运行在这些小集群上。再有一个方法就是为每个框架分配一组虚拟机。正如 Regola 和 Ducom 所说的，虚拟化被认为是一个性能瓶颈，尤其是在高性能计算（HPC）系统中。这正是 Mesos 适合的场景——它允许用户跨框架来管理集群资源。
Mesos 是一个双层调度器。在第一层中，Mesos 将一定的资源提供（以容器的形式）给对应的框架。框架在第二层接收到资源后，会运行自己的调度算法来 将任务分配到 Mesos 所提供的这些资源上。和 Hadoop YARN 的这种中央调度器相比，或许它在集群资源使用方面并不是那么高效。但是它带来了灵活性——比如说，多个框架实例可以运行在一个集群里。这是现有的这些调度器都无法实现的。就算是 Hadoop YARN 也只是尽量争取在同一个集群上支持类似 MPI 这样的第三方框架而已。更重要的是，随着新框架的诞生，比如说 Samza 最近就被 LinkedIn 开源出来了——有了 Mesos 这些新框架可以部署到现有的集群上，和其它的框架和平共处。
Q3：您好，Mesos 有哪些典型的应用场景？看了一些介绍，说是能做 Docker 的编排服务。与 OpenStack 这样的云平台管理物理机 CPU、内存，Cloudera Manager 管理 Hadoop 集群服务有什么区别？
A3：现在 Mesos 的应用场景非常多，譬如 1）Spark on Mesos（这是标配）2）Jenkins on Mesos
3）Mesos 做 docker 的编排服务等。
与 OpenStack 相比，首先，物理机，虚拟机都可以作为 Mesos 的集群节点；其次，粒度不同，Mesos 的基本计算单元是容器（LXC）, 而 OpenStack 的是 VM（听说现在也支持 Docker 容器技术了），前者资源利用率更高；最后，轻量级，Mesos 只负责 Offer 资源给 Framework，不负责调度资源。OpenStack 更贴近于 IaaS 层，而 Mesos 在 IaaS 之上。所以有人称其为 DCOS，或者分布式操作系统。
Q4：各方面边界在哪，有什么优劣势，谢谢。
A4：优点
资源管理策略 Dominant Resource Fairness(DRF), 这是 Mesos 的核心，也是我们把 Mesos 比作分布式系统 Kernel 的根本原因。通俗讲，Mesos 能够保证集群内的所有用户有平等的机会使用集群内的资源，这里的资源包括 CPU，内存，磁盘等等。很多人拿 Mesos 跟 k8s 相比，我对 k8s 了解不深，但是，我认为这两者侧重点不同不能做比较，k8s 只是负责容器编排而不是集群资源管理。不能因为都可以管理 Docker，我们就把它们混为一谈。
轻量级。相对于 YARN，Mesos 只负责 Offer 资源给 Framework，不负责调度资源。这样，理论上，我们可以让各种东西使用 Mesos 集群资源，而不像 YARN 只拘泥于 Hadoop，我们需要做的是开发调度器（Mesos Framework）。
提高分布式集群的资源利用率：这是一个 Generic 的优点。从某些方面来说，所有的集群管理工具都是为了提高资源利用率。VM 的出现，催生了 IaaS；容器的出现，催生了 K8s, Mesos 等等。简单讲，同样多的资源，我们利用 IaaS 把它们拆成 VM 与 利用 K8s/Mesos 把它们拆成容器，显然后者的资源利用率更高。（这里我没有讨论安全的问题，我们假设内部子网环境不需要考虑这个。)
缺点
门槛太高。只部署一套 Mesos，你啥都干不了，为了使用它，你需要不同的 Mesos Framework，像 Marathon，Chronos，Spark 等等。或者自己写 Framework 来调度 Mesos 给的资源，这让大家望而却步。
目前对 Stateful Service 的支持不够。Mesos 集群目前无法进行数据持久化。0.23 版本增加了 Persistent resource 和 Dynamic reserver，数据持久化问题将得到改善。
脏活累活不会少。Team 在使用 Mesos 前期很乐观，认为搞定了 Mesos，我们的运维同学能轻松很多。然而，根本不是那么回事儿，集群节点的优化，磁盘，网络的设置，等等这些，Mesos 是不会帮你干的。使用初期，运维的工作量不仅没有减轻，反而更重了。Mesos 项目还在紧锣密鼓的开发中，很多功能还不完善。
Q5：我想请教下，如果要做一个云服务平台，Mesos 和 Kubernates 怎么去选型
A5：目前的现状是 Mesos 和 K8s 的生态圈各自都发展的比较好，丢弃哪一个都很吃亏。不如按你个人的喜好，先选择一个投下去先用起来。比如数人云 直接一键部署，这样太方便了。可以快速体验 Mesos 的好处。
这个要看你的具体需求。据我所知，K8s 目前只支持 Docker 而且鲜有生产环境的用例；而 Mesos 不需要你的应用包到 Docker 里面并且其经历过生产环境的考验。但是，反过来，K8s 的社区更加活跃，其正在高速发展中，前景非常好。当然，上述都不是关键，一个好用的云平台更多的是要有好的产品理念。请参考数人云
Q6：对于长时间任务，有没有好的调度器算法或者策略
A6：长任务是依靠马拉松 Marathon 框架，对于 Docker，Mesos + Marathon 基本上是现在最成熟的分布式运行框架。长任务是依靠马拉松 Marathon 框架，对于 Docker，Mesos + Marathon 基本上是现在最成熟的分布式运行框架。
Q7：请问下 Mesos 和 Docker 结合，Mesos 只是能解决资源分配问题对么？
A7：对的，Mesos 负责资源分配，需要有个东东负责 Docker 的任务调度，这样就能将 Docker 实例自动下发到集群中运行。这个组件叫马拉松 Marathon。Mesos + Marathon 基本上现在最稳定的 Docker 集群化调度框架
Q8：Mesos 现在可以逐渐应用到生产环境了？
A8：Mesos 早就可以应用到生产环境了，国外的 Airbnb, Apple, Uber, Twitter，国内的携程，爱奇艺，还有我们公司数人科技都在生产环境使用了 Mesos。你在这里可以看到使用 Mesos 的列表 https://mesos.apache.org/documentation/latest/powered-by-mesos/
Q9：Mesos 和 Zookeeper 有什么关联吗？
A9：Zookeeper 是一个为分布式应用提供一致性服务的软件，而 Mesos 是一个分布式应用。所以在生产环境，我们需要使用 Zookeeper 来为 Mesos 提供一致性服务。
Q10：Mesos，Swarm，Kubernetes 之间有没有竞争关系？虽然这三家都说互相支持，但是这样做会不会太啰嗦了？
A10：Swarm 与 K8s 有很多交叉。Mesos 更多的是 Focus 在资源管理上，只是恰好可以使用 Container 做资源隔离。竞争与否，还需要看社区的走向吧。
Q11：你好，看了看这个框架想请教几个问题：
1. 这个框架是否自带日志搜集模块？2. 这个框架能否进行性能统计？3. 这个框架在某个节点资源耗尽时可否自动切换？如果所有节点资源耗尽是否容易崩溃，自恢复能力如何？4. 这个框架可否配置负载均衡？谢谢:)
A11：
带日志模块，但是功能比较简单，没有一个全局的展示
可以进行性能统计
Mesos 是根据当前的集群资源统计来决定给调度器分配多少资源的，资源耗尽只会导致新的应用无法部署，不会影响正在运行的东西。
可以配置负载均衡。并且 Mesos 本身也有多 Master 机制
Q12：请问 Mesos 怎样决定分配多少资源？分配的资源什么时候回收？
A12：Mesos 与其它的集群管理工具不同，Mesos 本身不负责分配资源，它只是将当前集群的剩余资源提供给注册到它的调度器，由调度器本身来决定使用多少资源，以及合适释放资源。
Q13：假设集群里有 3 台服务器，每台服务器可用内存 16G，现在调度器要运行一个任务需要 24G 内存，那么 Mesos 是把整个集群的 48G 内存当成一个整体来提供，还是会向调度器提供每台服务器剩余的内存, 也就是说下面两种情况哪种才是正确的：
1. 调度器先申请节点 1 的 16G 内存，再申请节点 2 的 8G 内存，用哪个节点的内存完全由调度器控制
2. 调度器一次过申请 24G 内存，由 Mesos 控制具体是用了哪个节点的内存。有可能是每个节点都分配了 8G；也有可能是一个节点 16G，另一个节点 8G
A13：看过 DPark 实现 Mesos 的调度器。你一个任务需要 24G 内存，这个任务就需要拆分才可以调度起来。每个小任务需要 16G 以下的内存。才能通过调度器，调度到具体服务器。调度器一般都是把任务调度到文件所在的机器上。由调度器控制使用哪里的资源，Mesos 告诉调度器哪些资源可用。
上述就是丸趣 TV 小编为大家分享的 Mesos 如何理解了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注丸趣 TV 行业资讯频道。
