先说说为什么选择yarn而不是Mesos,这个之前也和一个人讨论过。
首先是可部署性。Yarn如果打包JDK后可以没有任何依赖的,Mesos因为是C/C++开发的,
安装部署可能会有库依赖。 这点我不知道大家是否看的重,反正我是看的相当重的。软件就应该是
下下来就可以Run。所以12年的时候我就自己开发了一套Java服务框架,开发完之后运行个main方法就行。
让应用包含容器,而不是要把应用丢到tomcat这些容器,太复杂,不符合直觉。二次开发。Yarn其实就是个Jar包,而且和Lucene也一样,提供了非常多的扩展接口,很多实现都是可插拔
可替换的,在xml配置下,可能就能用你的实现替换掉原来的实现,没有太大的侵入性,所以就算是未来Yarn升级,
也不会有太大问题。Mesos我不知道这种二次开发性如何。
当然, Mesos和Yarn 都非常棒,都是可编程的框架。一个系统,只要是可编程的,基本就有活了。一个硬件,不能编程,就是死的,一旦可以编程
就活了,就可以各种折腾,有各种奇思妙想可以实现。
上面是说Mesos和Yarn的选型。我再说说为啥选择要对Yarn再进行一次封装。
首先,Yarn为了灵活,或者为了能够满足开发者大部分的需求,底层交互的API就显得比较原始了。自然造成开发难度很大。这个也不是我一个人觉得,现在Apache的twill,以及Hulu他们开发的时候Core那一层,其实都是为了解决这个问题。那为什么我没有用Twill呢,第一是文档实在太少,第二是有点复杂,我不需要这么复杂的东西。我觉得,Twill与其开发这么多功能,真的不如好好写写文档。
还有就是为了隔离,让上层你开发的Framework可以移植。Spark是个典型,他可以跑在Mesos上,也可以跑在Yarn上 ,还可以跑在自己上面,就是因为Spark的Framework不依赖于底层的Core,这个Core其实就是适配。我封装了
Yarn后,上层的Framework是看不到的Yarn的API的。这些做好后,你想要开发组件,其实就是基于Core再开发个Framework,如果你想开发应用,就是针对Framework开发了。
Framework是个什么概念,其实就是类似Spark,类似MR,他们都是一个在Yarn之上的Framework,你开发的MR程序,Spark程序则是应用。
我们说容器解决了资源隔离,解决了库的依赖问题。同样的,Yarn对操作系统也没有任何要求,没有任何库的依赖,把Yarn和容器结合,基本上算是天作之合,整套资源管理,调度编排可以跑在一个混合的系统上(比如你的集群由100台centos,100台Ubuntu构成),也不需要担心库的依赖。部署起来也会很简单。