先說說為什么選擇yarn而不是Mesos,這個(gè)之前也和一個(gè)人討論過。

        1. 首先是可部署性。Yarn如果打包JDK后可以沒有任何依賴的，Mesos因?yàn)槭荂/C++開發(fā)的，

安裝部署可能會(huì)有庫(kù)依賴。 這點(diǎn)我不知道大家是否看的重，反正我是看的相當(dāng)重的。軟件就應(yīng)該是

下下來就可以Run。所以12年的時(shí)候我就自己開發(fā)了一套Java服務(wù)框架，開發(fā)完之后運(yùn)行個(gè)main方法就行。

        讓應(yīng)用包含容器，而不是要把應(yīng)用丟到tomcat這些容器，太復(fù)雜，不符合直覺。

        2. 二次開發(fā)。Yarn其實(shí)就是個(gè)Jar包，而且和Lucene也一樣，提供了非常多的擴(kuò)展接口，很多實(shí)現(xiàn)都是可插拔

可替換的，在xml配置下，可能就能用你的實(shí)現(xiàn)替換掉原來的實(shí)現(xiàn)，沒有太大的侵入性，所以就算是未來Yarn升級(jí)，

也不會(huì)有太大問題。Mesos我不知道這種二次開發(fā)性如何。

        當(dāng)然， Mesos和Yarn 都非常棒，都是可編程的框架。一個(gè)系統(tǒng)，只要是可編程的，基本就有活了。一個(gè)硬件，不能編程，就是死的，一旦可以編程

就活了，就可以各種折騰，有各種奇思妙想可以實(shí)現(xiàn)。

        上面是說Mesos和Yarn的選型。我再說說為啥選擇要對(duì)Yarn再進(jìn)行一次封裝。

        1. 首先，Yarn為了靈活，或者為了能夠滿足開發(fā)者大部分的需求，底層交互的API就顯得比較原始了。自然造成開發(fā)難度很大。這個(gè)也不是我一個(gè)人覺得，現(xiàn)在Apache的twill,以及Hulu他們開發(fā)的時(shí)候Core那一層，其實(shí)都是為了解決這個(gè)問題。那為什么我沒有用Twill呢，第一是文檔實(shí)在太少，第二是有點(diǎn)復(fù)雜，我不需要這么復(fù)雜的東西。我覺得，Twill與其開發(fā)這么多功能，真的不如好好寫寫文檔。

        2. 還有就是為了隔離，讓上層你開發(fā)的Framework可以移植。Spark是個(gè)典型,他可以跑在Mesos上，也可以跑在Yarn上 ,還可以跑在自己上面，就是因?yàn)镾park的Framework不依賴于底層的Core,這個(gè)Core其實(shí)就是適配。我封裝了

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

        3. 這些做好后，你想要開發(fā)組件，其實(shí)就是基于Core再開發(fā)個(gè)Framework,如果你想開發(fā)應(yīng)用，就是針對(duì)Framework開發(fā)了。

        Framework是個(gè)什么概念，其實(shí)就是類似Spark,類似MR,他們都是一個(gè)在Yarn之上的Framework,你開發(fā)的MR程序，Spark程序則是應(yīng)用。

        我們說容器解決了資源隔離，解決了庫(kù)的依賴問題。同樣的，Yarn對(duì)操作系統(tǒng)也沒有任何要求，沒有任何庫(kù)的依賴，把Yarn和容器結(jié)合，基本上算是天作之合，整套資源管理，調(diào)度編排可以跑在一個(gè)混合的系統(tǒng)上(比如你的集群由100臺(tái)centos,100臺(tái)Ubuntu構(gòu)成)，也不需要擔(dān)心庫(kù)的依賴。部署起來也會(huì)很簡(jiǎn)單。