Mesos官方称之为分布式系统内核，它把数据中心的CPU、内存、磁盘等抽象成一个资源池。

它主要是一个两级调度系统。首先可以看到上图中左侧的Mesos agent会在所有集群的每一台机器上部署一个agent。当这个agent启动后会向master注册，携带了一些每个机器的统计资源，由master来决定给每个框架分配多少资源。分配算法默认采用的是分级主导资源分配算法。所谓分级就是各个框架它是有角色的概念，每个角色可以选择它的一个权重。它的主导资源公平是指每个框架可能有一些是以CPU为主导，有一些是以内存为主导的，诸如此类。

主导资源公平就是说这些主导资源所在整个资源中占据的比例是公平的。当然也可以选择自己定义一个算法来替换这个分配算法。

上图中右侧是部署在Mesos上的一系列框架，当这些框架收到资源之后，它就会根据自己的需求来调度自身的任务。

Upone是为云处理服务定制的容器调度框架，支持长期服务和定期服务。

MARATHON是一个在Mesos上一个比较著名的跑长时任务的一个调度框架。CHR是一个跑定时任务的框架。

而Upone同时可以支持跑定时任务和长期任务，并且拥有一些MARATHON和CHR都没有的功能。

上图是一个Mesos启动任务的流程图。中间的绿色部分是调度器，也就是upone。如图所示，第一步是client来完成一个注册的功能，当任务没有到来的时候，master会不停地给upone发送一个offer，这个offer就是里面包含了一些资源的信息。当upone没有收到任何启动任务的时候，它会不停拒绝这个offer，以便Mesos master上面还有其它一些框架，它们可以利用这些offer。当这个任务到来的时候，upone会把这个任务放到任务队列里，等到下一个offer到来的时候就可以选择它想要的选择的那些offer，把这些任务放到这个上面去，然后告诉master，由master通知Mesos agent，告诉它需要启哪些任务，以及需要哪些CPU和内存。最后agent就会通知对应的执行器。

Upone是一个容器调度的方案，所以它的执行器都是docker的执行器。这样一个启动流程就完成了。

接下来它的状态反馈都是异步的通知，我们需要upone来订阅它的一些通知来完成。

Upone跟Mesos master的交互是通过Mesos提供的api/v1/scheduler方案来处理的。

当要和Mesos进行通讯的时候，首先要开启一个长链接来订阅Mesos的一些事件。

上图列出的是一些常用的事件。第一个是已经订阅成功的事件，还有就是之前提到的offer的事件。包含了一些机器的资源的信息，可能会通知你这个资源不再有效了。还会告知一些状态变更的事件。接下来是一个失败的事件，它会告诉我们整个节点已经丢失或执行器已经被无端停止了。这时通常会伴随update事件，因为在上面会跑不同的任务，当一个失败的事件发生的时候，伴随这些任务其实都已经丢失了。最后一个是心跳的事件。

对于offer的处理，upone主要提供了两种消息，一种是接受。如果接受这个offer，它要把启动的信息还有它所需的资源信息统统告知master；如果要拒绝了offer，它可以选择拒绝这个offer需要有多长时间。当然也可以用一个消息来取消之前设定的拒绝时间。

任务状态的变更和upone可能产生联动，当一个任务变成running状态的时候，upone会更新负载均衡器。如果任务已经丢失之后，我们需要通过upone的调度来完成任务的迁移工作。

我们开源了一个基于ngx_lua的动态负载均衡方案Slardar。

当任务下发到Mesos，它帮你把任务创建出来之后，它会有一个running的事件告知upone。这时就可以把它更新到Slardar负载均衡器上。

Upone的更新是采用蓝绿更新的方案，就是当更新的请求发出之后，upone首先会根据新的配置去告知Mesos它要创建一篇新的APP。当这些APP成功地运行之后，upone会去把新的APP地址更新到Slardar里面，同时会摘掉旧的地址。等到一个可配置的时间之后，如果是短链接，就可以把旧的任务关闭了。

对任务进行健康检查的第一项就是是否开启这个健康检查，第二个是上一次健康检查的时间，下面是一些健康检查的服务列表。

预处理功能就是可以在接入到APP之前可以载入相关的动态脚本来执行一些预处理的功能。比如对APP进行一些频率限制，或者对APP进行一些参数的转换。

以频率限制为例，可以在访问APP前载入引入limit相关脚本完成处理。

同时，我们还提供命令行工具，以便APP所有者通过upone手动操作上述负载均衡和更新部署的相关功能。

收到Mesos offer后，可以自定义策略来决定任务调度方案。

随机调度是尽可能让同一应用的各个任务分布到不同的机器。

但随机调度有一个缺点就是它认为所有的Slave都具备了相同的特质， 所以我们加入了对机器和任务属性的调度方案。

Consul是一个配置中心和注册服务中心。上图是一个GPU的例子。比如它给这个任务贴了一个GPU的标签，当offer到来的时候，upone可以去consul中获取所有slave的一些相关信息。

我们还需要一个实时的策略，根据机器的weight/local进行动态调度。

上图是一个监控系统，我们可以从这个监控系统中获取我们所有节点的load情况。

基本上所有的组件都会和Consul发生联系。Upone的所有APP和配置都是从consul加载的，还会从Consul拉取属性信息。当所有APP启动之后，它会往Consul中注册它的服务以便Slardar可以及时地知道服务的情况。Upone是APP所有者的入口，而Slardar是APP用户的入口。

通过Raft分布式一致性协议来实现高可用。

领导选举是通过心跳机制来触发，term充当逻辑时钟的作用。

日志复制是指领导者把一条指令（能被复制状态机执行）附加到日志中，发起附加条目RPC请求给其它角色。

强领导者的意思是日志条目只能从leader发送给其它的服务器。

各个应用可以在创建任务的时候制定自己的slack channel。当任务出现异常时，发送实时通知。