可部署性

先說明下，這里探討的是Yarn或者M(jìn)esos集群的部署，不涉其上的應(yīng)用。Yarn除了依賴JDK，對操作系統(tǒng)沒有任何依賴，基本上放上去就能
跑。Mesos因?yàn)槭荂/C++開發(fā)的，安裝部署可能會(huì)有庫依賴。
這點(diǎn)我不知道大家是否看的重，反正我是看的相當(dāng)重的。軟件就應(yīng)該是下下來就可以Run。所以12年的時(shí)候我就自己開發(fā)了一套Java服務(wù)框架，開發(fā)完之后
運(yùn)行個(gè)main方法就行。讓應(yīng)用包含容器，而不是要把應(yīng)用丟到Tomcat這些容器，太復(fù)雜，不符合直覺。

二次開發(fā)

Yarn 對Java/Scala工程師而言，只是個(gè)Jar包，類似索引開發(fā)包Lucene，你可以把它引入項(xiàng)目，做任何你想要的包裝。 這是其一。

其二，Yarn提供了非常多的擴(kuò)展接口，很多實(shí)現(xiàn)都是可插拔?？商鎿Q的，在XML配置下，可以很方便的用你的實(shí)現(xiàn)替換掉原來的實(shí)現(xiàn)，沒有太大的侵入性，所以就算是未來Yarn升級，也不會(huì)有太大問題。

相比較而言，Mesos更像是一個(gè)已經(jīng)做好的產(chǎn)品，部署了可以直接用，但是對二次開發(fā)并不友好。

生態(tài)優(yōu)勢

Yarn 誕生于Hadoop這個(gè)大數(shù)據(jù)的“始作俑者”項(xiàng)目，所以在大數(shù)據(jù)領(lǐng)域具有先天優(yōu)勢。

底層天然就是分布式存儲(chǔ)系統(tǒng)HDFS，穩(wěn)定高效。
其上支撐了Spark、MR等大數(shù)據(jù)領(lǐng)域的扛頂之座，久經(jīng)考驗(yàn)。
社區(qū)強(qiáng)大，最近發(fā)布版本也明顯加快，對于長任務(wù)的支持也越來越優(yōu)秀。

長任務(wù)支持

談及長任務(wù)（long running
services）的支持，有人認(rèn)為早先Yarn是為了支持離線短時(shí)任務(wù)的，所以可能對長任務(wù)的支持有限。其實(shí)大可不必?fù)?dān)心，譬如現(xiàn)在基于其上的
Spark Streaming就是7x24小時(shí)運(yùn)行的，跑起來也沒啥問題。一般而言，要支持長任務(wù)，需要考慮如下幾個(gè)點(diǎn)：

Fault tolerance，主要是AM的容錯(cuò)。
Yarn Security，如果開啟了安全機(jī)制，令牌等的失效時(shí)間也是需要注意的。
日志收集到集群。
還有就是資源隔離和優(yōu)先級。如果資源隔離做的太差，會(huì)對長時(shí)任務(wù)產(chǎn)生影響。

大家感興趣可以先參考Jira。我看這個(gè)Jira 13年就開始了，說明這事很早就被重視起來了。下面我們隊(duì)提到的幾個(gè)點(diǎn)做下解釋。

Fault tolerance

Yarn 自身高可用。目前Yarn的Master已經(jīng)實(shí)現(xiàn)了HA。
AM容錯(cuò)，我看從2.4版本（看的源碼，也可能更早的版本就已經(jīng)支持）就已經(jīng)支持 keep containers across
attempt
的選項(xiàng)了。什么意思呢？就是如果AM掛掉了，在Yarn重新啟動(dòng)AM的過程中，所有由AM管理的容器都會(huì)被保持而不會(huì)被殺掉。除非Yarn多次嘗試都沒辦
法把AM再啟動(dòng)起來（默認(rèn)兩次）。 這說明從底層調(diào)度上來看，已經(jīng)做的很好了。

日志收集到集群

日志收集在2.6版本已經(jīng)是邊運(yùn)行邊收集了。

資源隔離

資源隔離的話，Yarn做的不好，目前有效的是內(nèi)存，對其他方面一直想做支持，但一直有限。這估計(jì)也是很多人最后選擇Mesos的緣由。但是現(xiàn)在這
點(diǎn)優(yōu)勢Mesos其實(shí)已經(jīng)蕩然無存，因?yàn)镈ocker容器在資源隔離上已經(jīng)做的足夠好。Yarn和Docker一整合，就互補(bǔ)了。

小結(jié)

Mesos 和 Yarn 都是非常優(yōu)秀的調(diào)度框架，各有其優(yōu)缺點(diǎn)，彈性調(diào)度，統(tǒng)一的資源管理是未來平臺(tái)的一個(gè)趨勢，類似的這種資源管理調(diào)度框架必定會(huì)大行其道。

一些常見的誤解

脫胎于Hadoop，繼承了他的光環(huán)和生態(tài)，然而這也會(huì)給其帶來一定的困惑，首先就是光環(huán)一直被Hadoop給蓋住了，而且由于固有的慣性，大家會(huì)理所當(dāng)然的認(rèn)為Yarn只是Hadoop里的一個(gè)組件，有人會(huì)想過把Yarn拿出來單獨(dú)用么？

然而，就像我在之前的一篇課程里，反復(fù)強(qiáng)調(diào)，Hadoop是一個(gè)軟件集合，包含分布式存儲(chǔ)，資源管理調(diào)度，計(jì)算框架三個(gè)部分。他們之間沒有必然的關(guān)
系，是可以獨(dú)立開來的。而Yarn
就是一個(gè)資源管理調(diào)度引擎，其一開始的設(shè)計(jì)目標(biāo)就是為了通用，不僅僅是跑MR。現(xiàn)在基于Yarn之上的服務(wù)已經(jīng)非常多，典型的比如Spark。

這里還有另外一個(gè)誤區(qū)，MR目前基本算是離線批量的代名詞，這回讓人誤以為Yarn也只是適合批量離線任務(wù)的調(diào)度。其實(shí)不然，我在上面已經(jīng)給出了分析，Yarn 是完全可以保證長任務(wù)的穩(wěn)定可靠的運(yùn)行的。

如何基于Yarn開發(fā)分布式程序

本文不會(huì)具體教你如何使用Yarn的API，不過如果你想知道Yarn的API，但是又覺得官方文檔太過簡略，我這里倒是可以給出兩個(gè)建議：

代碼使用范例可以參看Spark Yarn相關(guān)的代碼。算的上是一個(gè)非常精簡的Yarn的adaptor。
買本Yarn相關(guān)的書，了解其體系結(jié)構(gòu)也有助于你了解其API的設(shè)計(jì)。

接下來的內(nèi)容會(huì)探討以下兩個(gè)主題：

基于Yarn開發(fā)分布式程序需要做的一些準(zhǔn)備工作
基于Yarn開發(fā)容器調(diào)度系統(tǒng)的一些基本思路

基于Yarn開發(fā)分布式程序需要做的一些準(zhǔn)備工作

肯定不能擼起袖子就開始干。開始動(dòng)手前，我們需要知道哪些事情呢？

Yarn原生的API太底層，太復(fù)雜了

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

最好是能開發(fā)一個(gè)解決一類問題的Framework

Yarn只是一個(gè)底層的資源管理和調(diào)度引擎。一般你需要基于之上開發(fā)一套解決特定問題的Framework。以Spark為例，他是解決分布式計(jì)算
相關(guān)的一些問題。而以我開發(fā)的容器調(diào)度程序，其實(shí)是為了解決動(dòng)態(tài)部署Web應(yīng)用的。在他們之上，才是你的應(yīng)用。比如你要統(tǒng)計(jì)日志，你只要在Spark上開
發(fā)一個(gè)Application 。 比如你想要提供一個(gè)推薦系統(tǒng)，那么你只要用容器包裝下，就能被容器調(diào)度程序調(diào)度部署。

所以通常而言，基于Yarn的分布式應(yīng)用應(yīng)該符合這么一個(gè)層次：

Yarn -> Adapter -> Framework -> Application

Adapter 就是我第一條說的，你自個(gè)封裝了Yarn的API。 Framework就是解決一類問題的編程框架，Application才是你真正要解決業(yè)務(wù)的系統(tǒng)。通過這種解耦，各個(gè)層次只要關(guān)注自己的核心功能點(diǎn)即可。

保證你上層的Framework/Application可以移植

Spark是個(gè)典型，他可以跑在Mesos上，也可以跑在Yarn上，還可以跑在自己上面（Standalone），實(shí)時(shí)上，泡在Yarn上的，以及跑Standalone模式的，都挺多的。這得益于Spark本身不依賴于底層的資源管理調(diào)度引擎。

這其實(shí)也是我上面說的兩條帶來的好處，因?yàn)橛辛薃daptor，上層的Framework可以不用綁死在某個(gè)資源調(diào)度引擎上。而Framework則可以讓Applicaiton 無需關(guān)注底層調(diào)度的事情，只要關(guān)注業(yè)務(wù)即可。

另外，你費(fèi)盡心機(jī)開發(fā)的Framework上，你自然是希望它能跑在更多的平臺(tái)上，已滿足更多的人的需求，對吧。

基于Yarn開發(fā)容器調(diào)度系統(tǒng)的一些基本思路

首先我們需要了解兩個(gè)概念：

啞應(yīng)用。所謂啞應(yīng)用指的是無法和分布式系統(tǒng)直接進(jìn)行交互，分布式系統(tǒng)也僅僅透過容器能進(jìn)行生命周期的控制，比如關(guān)閉或者開啟的應(yīng)用。典型的比如MySQL、Nginx等這些基礎(chǔ)應(yīng)用。他們一般有自己特有的交互方式，譬如命令行或者socket協(xié)議或者HTTP協(xié)議。
伴生組件。因?yàn)橛辛藛?yīng)用的存在，分布式系統(tǒng)為了能夠和這些應(yīng)用交互，需要有一個(gè)代理。而這個(gè)代理和被代理的啞應(yīng)用，具有相同的生命周期。典型
的比如，某個(gè)服務(wù)被關(guān)停后，該事件會(huì)被分布式系統(tǒng)獲知，分布式系統(tǒng)會(huì)將該事件發(fā)送給Nginx的伴生組件，伴生組件轉(zhuǎn)化為Nginx能夠識(shí)別的指令，將停
止的服務(wù)從Nginx的ProxyBackend列表中剔除。

在容器調(diào)度系統(tǒng)中，如果Yarn的NodeManager直接去管理Docker則需要Yarn本身去做支持，我覺得這是不妥的。Yarn的職責(zé)就是做好資源管理，分配，調(diào)度即可，并不需要和特定的某個(gè)技術(shù)耦合，畢竟Yarn是一個(gè)通用型的資源調(diào)度管理框架。

那基于上面的理論，我們基于Yarn，開發(fā)一套框架，這個(gè)框架會(huì)是典型的 master-slave結(jié)構(gòu)（這是Yarn決定的）。這個(gè)框架的 slaves 其實(shí)都是Docker 的伴生對象。master 可以通過這些Slave 對容器實(shí)現(xiàn)間接的管理。

我們簡單描述下他們的流程：

用戶提交Application，申請資源；
Yarn啟動(dòng)Framework的master；
Yarn啟動(dòng)Framework的slave；
slave 連接上master，并且發(fā)送心跳，從而master知道slave的狀況slave啟動(dòng)Docker，slave與被啟動(dòng)的這個(gè)docker container 一一對應(yīng)；
slave定時(shí)監(jiān)控Container；
slave發(fā)現(xiàn)container crash，slave自動(dòng)退出，Yarn獲得通知，收回資源；
master發(fā)現(xiàn)有節(jié)點(diǎn)失敗，發(fā)出新的節(jié)點(diǎn)要求，重新在另外一臺(tái)服務(wù)器上啟動(dòng)slave，重復(fù)從2開始的步驟。

這里還有一個(gè)問題，如果slave 被正常殺掉，可以通過JVM ShudownHook 順帶把Container也關(guān)掉。
但是如果slave被kill -9
或者異常crash掉了，那么就可能導(dǎo)致資源泄露了。目前是這個(gè)信息是由master上報(bào)給集群管理平臺(tái)，該平臺(tái)會(huì)定時(shí)清理。你也可以存儲(chǔ)該信息，譬如放
到Redis或者M(jìn)ySQL中，然后啟動(dòng)后臺(tái)清理任務(wù)即可。

了解了這個(gè)思路后，具體實(shí)施就變得簡單了，就是開發(fā)一個(gè)基于Yarn的master-slave程序即可，然后slave去管理對應(yīng)的Docker容器，包括接受新的指令。master提供管理界面展示容器信息，運(yùn)行狀態(tài)即可。

當(dāng)然，你還可以再開發(fā)一套Framework B專門和Nginx交互，這樣比如上面的系統(tǒng)做了節(jié)點(diǎn)變更，通知B的master，然后B的master 通過自己的伴生組件Slave 完成Nginx的更新，從而實(shí)現(xiàn)后端服務(wù)的自動(dòng)變更和通知。