由浅入深 | 如何优雅地写一个Mesos Framework

上周小数羞涩出镜，和数人云架构师春明一块儿为你们进行了在线直播的干货分享，今天小数抱来了实录，你们能够一睹为快啦！
本文从Mesos的基础概念讲起，不懂Mesos的小伙伴也彻底没有问题，一步一步教你写出优雅的Framework，让Mesos更增强大好用：）

今天主要和你们聊一聊Mesos、Marathon，以及数人云刚刚开源不久的一个Mesos Framework——Swan。

什么是Mesos

微服务概念起来以后，不少大型互联网公司须要把资源（好比说几千台机器、几万台机器）抽象工做，让更多人来使用。以前你们的作法比较粗暴，一个部门分几百台机器，一个项目分几百台机器，而后把程序裸跑在一些硬件或者虚拟机上，但这个过程当中资源的利用率不是很高。

另外一方面，有些增长资源的场景中，增长一些机器很是缓慢，安装、作机器的provision等等都很困难。所以一些聪明的工程师就萌生了一个想法：能不能把这些资源都抽象，须要的时候分配给不一样的人来使用？这个背景诞生了Mesos，即资源调度的工具。资源调度器Mesos不是创新，它源自于Google Omega的论文，由Twitter的公司最先推出来。

最近一段时间使用Mesos的API以及看代码时间比较多，接下和你们分享一下我对Mesos内部的理解。

Mesos的内部构成

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。

至此，简单介绍了Mesos内部的一些动做。接下来介绍Mesos提出的一些概念。

Mesos概念解析

Mesos master&slave

Mesos是一个分布式的系统，分master和slave， master的部分主要协调任务的分发、一些资源的调度。slave是负责执行的部分，好比一个任务最终是slave去执行的。固然，能够配在master执行。Mesos是一个双层调度，slave处于下层，也就是说能够动态的增长或者减小一些slave而不影响整个的任务池资源的变化，不影响上一层的任务。

Executor

Executor是真正的执行任务的逻辑。Mesos平台不太区分须要执行什么任务，因此它给用户一些灵活性，能够写不一样的Executor。好比最经常使用的Mesos运行容器的部分，就是一个Executor。还有Map Reduce的大型任务，一个Map、一个Reduce， Executor均可以执行。它的表现形式能够是一个二进制，Mesos在运行时，slave会把Executor从远程一个URL上拉下来，而后开始执行Executor。

Scheduler

Scheduler的意思是调度， Mesos master和slave把资源收上来以后，再把这些任务交给Scheduler，由Scheduler决定应该运行什么Task。

Framework

Framework是双层调度的上一层，也就是由Framework来决定到底该执行什么任务，而后执行多少这样的任务。

Offer

Offer是Mesos资源的抽象，好比说有多少CPU、多少memory，disc是多少，都放在Offer里，打包给一个Framework，而后Framework来决定到底怎么用这个Offer。

Task

Task其实是运行的小任务。有两大类Task，一大类咱们叫Long Running Task，好比Docker的一个进程或者其它的进程。另一类是Batch类型任务，这类应用很是普遍，好比说Map Reduce这么一个小任务或者是定时任务。

Mesos内部工做原理

这里分别介绍一下刚才提到的这些名词，说一说它们都是如何工做的。

Mesos master & slave

Mesos master是整个集群的核心，master为了保证高可用实际上是能够跑多个master，分布式系统为了保证尽可能的高可用，实际上是能够有多个master在那儿运行的。好比倒了几个master，不会影响整个服务。Mesos master主要内部的工做有：Framework注册或者Framework出了什么问题，它来保证Framework的生命周期；slave的添加、slave的异常、slave的任务分配，我把它叫作slave的Lifecycle；Task Management，好比说Mesos master可能记录了哪些Task运行在哪些slave上；Resource Allocation&Offer，就是说slave有什么资源汇报给master，而后由master把这些任务交给注册在这个master上的一些Framework。

slave能够动态添加和减小，它lost不会影响整个服务，只是把这个事件（好比说一个slave掉了）由master去通知Framework。在Mesos slave代码里有大量执行器，即Executor的逻辑，由于全部Executor都是在slave上执行的，包括把Executor从远程拉下来、开始执行Executor、开始执行launch task，维护task的生命周期，task fail了如何去作等等。

Mesos Framework

Mesos的定位是一些资源的调度，它把任务的调度交给了Framework来作，Mesos只关心资源以及把资源给了谁， Framework来决定哪些资源怎么去使用。Mesos鼓励Framework在上面共生。想象一下，做为一个大型公司，有不少的资源，有核心的一组人来维护Mesos的集群，不断的往Mesos上添加资源和减小资源，而把Framework执行的能力交给其它的组、须要资源的那些组，各个组就能够写本身的Framework，丢到整个大的Mesos集群上来执行了。Mesos框架上和执行上各类各样的Framework，而Mesos自己也不了解为何Framework工做，它只是知道把Offer给Framework，而后Framework告诉它来执行什么样的Executor。

两个比较流行的Framework

Marathon Framework，它的任务偏Long Running，核心是application。由于Mesos只关注task自己，task偏向于小任务，不会产生什么巨大的效应，而在企业里面尤为是弹性应用，更可能是一个应用，它有不少的实例来执行，这就是Marathon来作的。

Chornous是一个偏Job、定时任务类型，若是把定时任务以Docker形式发出来，这个Chornous是很是适合的。传统的的Cron Job也是解决这类问题， Cron Job其实有很大的痛点，由于Cron Job是跑在主机上的，主机有limit的限制，如何把Cron Job放在多机上，须要有一个很好的哈希算法。到底如何把一堆单台机器很难执行的多个job水平分布在不少机器上，很麻烦。可是有了这个Chornous的Framework，事情就变得简单多了。

Scheduler/Scheduler Driver

它们俩区分度不是太大，有一些区分。Scheduler是作任务分配的，它从master上获得一个Offer的事件，拿到Offer后，决定到底接受这个Offer仍是拒绝，接受这个Offer以后，把什么样的Task放在这个Offer上， Framework也开始占用这个Offer，这是Scheduler作的事情。Scheduler Driver实际上是偏消息通讯的那一部分，而Scheduler可定制化特别强，在代码里看到Scheduler实际上是一个java的abstract glass，至关于一个interface，Framework本身去实现这么一个东西。若是想写一个Framework，其实大部分时间在如何写好一个Scheduler实现这一部分。

Executor/Executor Driver

若是Executor和Scheduler是对应的， Executor就是执行的这一部分。Mesos container这个Executor是Mesos本身提供的，不用写Executor就能够launch一个Docker的任务。但若是有一些本身的需求，就须要去实现一个Executor，好比七牛和乐视实现了一些Executor。

举例来讲，处理图片、处理文件的Executor，偏向于这种小任务，写一个Executor来实现这个interface，最终打成一个二进制，放在一个URL里面。在Framework，slave就能够把这个Executor拉下来，而后执行这个Tasks。Executor是一个独立的二进制，它和master、和slave之间的通讯是要支持RBC的。

Marathon

刚才已经提到了Marathon基本的功能，Marathon做为一个Long Running上一层的调度机制，为用户作了不少有意义的事情。单纯一个Mesos的话作不了什么，由于Task的力度特别小，Mesos的功能更偏重于资源的管理、资源的调度，Marathon更偏向于一些任务。

Marathon提出了几个概念，最核心的概念叫application，还有Group的application，是一组的application。一个application是什么呢？好比一个Rails的任务、NodeJS任务或者其它的一些任务，在部署的时候并非部署一个Task，而是部署很是多的Task，application就是一组Task。这个Task在Marathon里面叫instance，能够选择scale down或者scale up这些instance，这些任务最终交给Mesos，Mesos调度到不一样的slave上。

围绕着这个application，Marathon就提供了一些概念叫Group，Group是一组application。举例来讲，在内部可能有不少的微服务，这些微服务达到同一个目标，好比说服务之间还有调用、还有依赖，这时去发一个Group application就比较好用。但实际工做中，由于生产级别的服务对稳定性的要求很高， Group之间其实假设服务和服务之间是有必定的依赖。

Marathon提供了一个有意思的feature—— rolling update。假若有APP的新版本上来，它能够经过必定的机制去发多个版本，并且能够多个版本共存。若是那个新版本没有问题的话，能够继续preceeding deployment。若是有问题的话，能够Rollback。这时有两个概念Deployment和Version，能够选定哪个Version，想Rollback哪一个Version。Deployment是每次update，每次更新、每次从新的Deployment、每次scale，都会在内部生成一个Deployment，和应用一对多有关。有趣的是Deployment之间是不能够重叠的，Deployment是一种部署排队的机制，Deployment不能够多个同时进行，既想update又想scale，会让Marathon崩溃。

Marathon scale和rolling update的功能都很是有用，好比新浪微博如今有一个大的事件，须要更多的Task顶上来，马上 scale up，只要资源足够就能够无限多的Task生成。Rollback，若是有一个版本有问题，能够瞬间Rollback到之前一个健康的版本。

虽然Mesos对下面的资源作了一些抽象，可是有时候有一些倾向性，好比但愿CPU使用率比较高的一些任务调度到CPU比较好的机器上，须要一种在调度上的倾向性来知足刚才的场景。不少调度器都有相似的功能，叫Constraints，好比一台主机的label，要把Task打到一组主机这样的Label上或者是Host name like，这是Marathon作的，Mesos不用作这类的事情。

Marathon的接口很是友好，都是HTTP的接口。Mesos的接口by design不是面向最终用户，因此它的接口并非那么友好。马拉松的UI也很是漂亮，尤为是新版。

Mesos调度器Swan

最后介绍一下Swan（https://github.com/Dataman-Cl... ）这个项目，Swan是最近数人云作的一个Mesos的Framework，定位是作一个General Purpose Long Running Task的Framework。数人云使用马拉松较长时间，发现不太知足需求，好比很难作一些定制化，控制不住它的发展趋势。咱们但愿研发一款工具既有马拉松的功能又自主可控、添加一些想要的featur，具体的feature会在下文中逐一介绍。

咱们但愿这个通用性的Framework在任何状况下，服务不会受到影响。由于Mesos HA这方面已经作得很好，因此Framework不会是单点，首先Swan要支持HA，由于受到Swarmkit启发比较大， Swarmkit天生就是Raft协议，在一堆manager中只要有一个活的，就能健康的对外服务。

Marathon没怎么作服务发现，无非是把端口暴露出来，哪一个任务在哪些IP和端口上，经过API的形式告诉给外面。Swan里内置服务发现，会有一个列表告诉外面哪些服务跑在哪些端口、哪些APP上。

DNS是服务发现的另外一种。主流的一些Framework都把DNS这个功能放在了比较核心的位置，好比K8s里面的SkyNet，Mesos曾经之前有Mesos DNS，以及Swarmkit，Swarm的服务发现分为DNS Round Robin和IPVS两种，把DNS放在Swan这个模块里更加的可控。它不单是一个DNS，同时是一个DNS的代理。这样最终能实现的效果，在企业内部经过咱们的DNS和用户的DNS来混搭，来达到一种Mesos内部和外部互相调用，在浏览器上既能够访问Mesos内部的东西又能够访问外面的东西，达到比较完美的效果。

Proxy，并不单是Proxy，还有负载均衡。最多见的Proxy的工具备HAProxy或者nginx。 HAProxy和nginx虽然很优秀、性能很好，缺点是可控性太差，很难控制它。HA可编程的能力不好，Nginx可编程的能力不错，新浪微博有一个项目叫upsync-module，很是优秀。以前评估过这个项目，发现集成这两个的难度很大。

个人分享就到这里，谢谢你们。