为什么用Yarn来做Docker容器调度引擎

为什么用Yarn来做Docker容器调度引擎

先说说为什么选择yarn而不是Mesos,这个之前也和一个人讨论过。

        1. 首先是可部署性。Yarn如果打包JDK后可以没有任何依赖的，Mesos因为是C/C++开发的，

安装部署可能会有库依赖。 这点我不知道大家是否看的重，反正我是看的相当重的。软件就应该是

下下来就可以Run。所以12年的时候我就自己开发了一套Java服务框架，开发完之后运行个main方法就行。

        让应用包含容器，而不是要把应用丢到tomcat这些容器，太复杂，不符合直觉。

        2. 二次开发。Yarn其实就是个Jar包，而且和Lucene也一样，提供了非常多的扩展接口，很多实现都是可插拔

可替换的，在xml配置下，可能就能用你的实现替换掉原来的实现，没有太大的侵入性，所以就算是未来Yarn升级，

也不会有太大问题。Mesos我不知道这种二次开发性如何。

        当然， Mesos和Yarn 都非常棒，都是可编程的框架。一个系统，只要是可编程的，基本就有活了。一个硬件，不能编程，就是死的，一旦可以编程

就活了，就可以各种折腾，有各种奇思妙想可以实现。

        上面是说Mesos和Yarn的选型。我再说说为啥选择要对Yarn再进行一次封装。

        1. 首先，Yarn为了灵活，或者为了能够满足开发者大部分的需求，底层交互的API就显得比较原始了。自然造成开发难度很大。这个也不是我一个人觉得，现在Apache的twill,以及Hulu他们开发的时候Core那一层，其实都是为了解决这个问题。那为什么我没有用Twill呢，第一是文档实在太少，第二是有点复杂，我不需要这么复杂的东西。我觉得，Twill与其开发这么多功能，真的不如好好写写文档。

        2. 还有就是为了隔离，让上层你开发的Framework可以移植。Spark是个典型,他可以跑在Mesos上，也可以跑在Yarn上 ,还可以跑在自己上面，就是因为Spark的Framework不依赖于底层的Core,这个Core其实就是适配。我封装了

Yarn后，上层的Framework是看不到的Yarn的API的。

        3. 这些做好后，你想要开发组件，其实就是基于Core再开发个Framework,如果你想开发应用，就是针对Framework开发了。

        Framework是个什么概念，其实就是类似Spark,类似MR,他们都是一个在Yarn之上的Framework,你开发的MR程序，Spark程序则是应用。

        我们说容器解决了资源隔离，解决了库的依赖问题。同样的，Yarn对操作系统也没有任何要求，没有任何库的依赖，把Yarn和容器结合，基本上算是天作之合，整套资源管理，调度编排可以跑在一个混合的系统上(比如你的集群由100台centos,100台Ubuntu构成)，也不需要担心库的依赖。部署起来也会很简单。