摘要：由一个来管理在每个集群节点上的运行也称为在这些上运行。它最优的特点是消息在不同的之间传递，它抽象了，消息传递其实是一个事件的库。底层实际上依赖于，为了保证分布式存储最终一致性。在上运行的由两部分组成一个是，通过注册到来获取集群资源。
Mesos Architecture
上图显示了 Mesos 的主要组成部分。 Mesos 由一个 master daemon 来管理 slave daemon 在每个集群节点上的运行, mesos applications （ 也称为 frameworks ）在这些 slaves 上运行 tasks。
Mesos master&slave
首先，Mesos是一个分布式的架构，它分Mesos master和Mesos slave，slave和master分别有不同的职责。从Mesos的源代码可以看出Mesos实现得比较优雅——它是一个C++代码。代码中有大量的关键词叫process，它不是传统意义上的进程，而是一种抽象的libprocess，libprocess是它最核心的库。如果大家以前使用过Erlang的语言就知道libprocess实际是对Erlang的IO和通讯模型的一个抽象。
libprocess，在Erlang里面也叫进程，实际上是一个虚拟进程，在运行Erlang的VM上。它最优的特点是消息在不同的process之间传递，它抽象了process，消息传递其实是一个事件的库。向process里发一个消息，这个消息不是直接打到process，而是中间有一个buffer的过程。
这样做的优点是特别适合分布式的系统，以前最常用的做法是监听网络端口，有包来了，有一个模块专门负责解这个包，解开一个协议后把这个协议发到后面一个处理进程，这个处理的进程可能是IO操作，可能去做其它事情，然后里面有很多IO上的Block，最后构造出一个response，通过一个socket传给客户端。这是最常用的一个写网络程序的办法，但是这里有一个大的IO上Block的地方——后面处理的逻辑依赖于解包的逻辑。如果处理逻辑很快，但解包逻辑很慢，后面会拖慢，都在等解包。
后来人们想到一种IO处理的方式，让任何一个东西都是分离的，比如从某一个端口收到一个消息，有一个多带带的进程，一个线程或者其它的东西去处理这个唯一的请求。这个线程很重，后来大家又发明了一些其它的东西，比如golang里面去搞一个channel，Erlang里面去搞一个process。libprocess实际上做了IO方面的事情， Mesos大量使用这个模型。
Zookeeper
Mesos底层实际上依赖于Zookeeper，为了保证分布式存储最终一致性。在Mesos运行过程中产生了一些数据，最终都会落在Zookeeper。因为Mesos是多个master，为了达到HA的需求，只要一个master活的，那么整个服务就能得到保证。
protobuf
Mesos内部在通信里面选择了protobuf协议。好处是比较流行，各个语言的库都比较多，结构化的语义也比较强，所以Mesos内部选择了protobuf。
Master 使用 Resource Offers 实现跨应用细粒度资源共享，如 cpu、内存、磁盘、网络等。 master 根据指定的策略来决定分配多少资源给 framework ，如公平共享策略，或优先级策略。 为了支持更多样性的策略，master 采用模块化结构，这样就可以方便的通过插件形式来添加新的分配模块。
在 Mesos 上运行的 framework 由两部分组成：
一个是 scheduler ，通过注册到 master 来获取集群资源。
另一个是在 slave 节点上运行的 executor 进程，它可以执行 framework 的 task 。 Master 决定为每个 framework 提供多少资源， framework 的 scheduler 来选择其中提供的资源。当 framework 同意了提供的资源，它通过 master 将 task发送到提供资源的slaves 上运行。
资源供给的一个例子下图描述了一个 Framework 如何通过调度来运行一个 Task
事件流程:
Slave1 向 Master 报告，有4个CPU和4 GB内存可用
Master 发送一个 Resource Offer 给 Framework1 来描述 Slave1 有多少可用资源
FrameWork1 中的 FW Scheduler会答复 Master，我有两个 Task 需要运行在 Slave1，一个 Task 需要<2个CPU，1 GB内存="">，另外一个Task需要<1个CPU，2 GB内存="">
最后，Master 发送这些 Tasks 给 Slave1。然后，Slave1还有1个CPU和1 GB内存没有使用，所以分配模块可以把这些资源提供给 Framework2
当 Tasks 完成和有新的空闲资源时，Resource Offer 会不断重复这一个过程。、
当 Mesos 提供的瘦接口允许其来扩展和允许 frameworks 相对独立的参与进来，一个问题将会出现： 一个 framwork 的限制如何被满足在不被 Mesos 对这些限制所知晓的情况下？
例如， 一个 framework 如何得到数据本地化在不被 Mesos所知晓哪个节点存储着被该 framwork 所需要的数据？Mesos 通过简单的寄予 frameworks 能够拒绝 offers 的能力来回答了这个问题。 一个 framework 将拒绝 不满足其限制要求的 offers 并接受满足其限制要求的 offers.
特殊情况下，我们找到一个简单的策略 delay scheduling， 在该 frameworks 等待 一个限制时间来获取存储输入数据的节点， 并生成接近的优化过得数据点。
本篇主要分享了mesos的组成部分和事件流程。下周会详细介绍Mesos的概念解析和工作原理。
敬请期待。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/25178.html
本文原文是 Deploy a Mesos Cluster with 7 Commands Using Docker 这个教程将给你展示怎样使用 Docker 容器提供一个单节点的 Mesos 集群（未来的一篇文章将展示怎样很容易的扩展这个到多个节点或者是见底部更新）。这意味着你可以使用 7 个命令启动整个集群！不需要安装任何东西除了一个正在运行的 Docker 服务器。 将启动 4 个容器：...
摘要：第二部分介绍当当的弹性化中间件。第三部分当当的云化之路。下面部分是为当当运营人员与合作伙伴提供的系统，如商品价格库存等。下图是当当的监控系统以及限流系统的。当当采用的作业中间件是自研的，它可以将一个完整的作业拆分为多个相互独立的任务。 showImg(https://segmentfault.com/img/remote/1460000009999152); 6月24日，双态运维·乌镇...
摘要：之前提到的文件即可利用以下模板生成请注意，其中的与就是占位符。如将某一特定部署至生产环境并运行个实例。而另一种方式则是使用等负载均衡器即服务器端发现。可重配置且能够在变更发生后立即将请求路由至新实例。 如今与Mesos相关的文章可谓层出不穷，不过展示能够直接用于生产的完整基础设施的资料却相当少见。在今天的文章中，我将介绍各组件的配置与使用方式，旨在帮助大家利用Mesos构建起持续交付且...
摘要：一概述意为，即使用来监控容器的插件或者模块，既然有专业的等容器监控方案，为什么还要用传统的呢在刚出现时，还没有专业的容器监控方案公司已有的成熟实践，想直接集成到中虽然不太优雅使用来监控有几种方案，比如自己写，利用的获取信息，暴露接口给采集使 一.概述 Dockbix意为docker+zabbix，即使用zabbix来监控docker容器的插件或者模块，既然有专业的cadvisor、pr...
阅读 1556·2021-11-11 16:54
阅读 1833·2019-08-30 15:56
阅读 2252·2019-08-30 15:44
阅读 1083·2019-08-30 15:43
阅读 1687·2019-08-30 11:07
阅读 695·2019-08-29 17:11
阅读 1337·2019-08-29 15:23
阅读 2878·2019-08-29 13:01
