為什么我要用Yarn來做Docker容器調度引擎

【編者的話】這篇文章是在一個微信群里和人聊天，然后整理出來的文字。當時Hulu推出了基于Yarn的Docker調度引擎。我正好那段時間也實現了一個類似的，經過交流，發現最后的實現基本是一致的。然而業界用的較多的是Mesos，這篇文章就是為了解釋為什么選擇用Yarn而不是Mesos來做。

前言

Mesos其實我不是非常熟悉，所以有些內容可能會有失偏頗，帶有個人喜好。大家也還是需要有自己的鑒別能力。

Mesos和Yarn都非常棒，都是可編程的框架。一個硬件，不能編程，就是死的，一旦可以編程就活了，就可以各種折騰，有各種奇思妙想可以實現，同樣的，一個軟件，只要是可編程的，基本也就活了，容易形成生態。

Yarn VS Mesos

我先說說在做容器調度引擎的時候，為什么選擇Yarn而不是Mesos。

可部署性

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

二次開發

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

其二，Yarn提供了非常多的擴展接口，很多實現都是可插拔。可替換的，在XML配置下，可以很方便的用你的實現替換掉原來的實現，沒有太大的侵入性，所以就算是未來Yarn升級，也不會有太大問題。

相比較而言，Mesos更像是一個已經做好的產品，部署了可以直接用，但是對二次開發并不友好。

生態優勢

Yarn 誕生于Hadoop這個大數據的“始作俑者”項目，所以在大數據領域具有先天優勢。

1. 底層天然就是分布式存儲系統HDFS，穩定高效。
2. 其上支撐了Spark、MR等大數據領域的扛頂之座，久經考驗。
3. 社區強大，最近發布版本也明顯加快，對于長任務的支持也越來越優秀。

談及長任務（long running services）的支持，其實大可不必擔心，譬如現在基于其上的Spark Streaming就是7x24小時運行的。一般而言，要支持長任務，需要考慮如下幾個點：

1. Fault tolerance，主要是AM的容錯
2. Yarn Security，如果開啟了安全機制，令牌等的失效時間也是需要注意的
3. 日志收集到集群
4. 還有就是資源隔離和優先級

大家感興趣可以先參考 Jira 。我看這個Jira 13年就開始了。說明這事很早就被重視起來了。

Fault tolerance

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

日志收集到集群

日志收集在2.6版本已經是邊運行邊收集了。

資源隔離

資源隔離的話，Yarn做的不好，目前有效的是內存，對其他方面一直想做支持，但一直有限。這估計也是很多人最后選擇Mesos的緣由。但是現在這點優勢Mesos其實已經蕩然無存，因為Docker容器在資源隔離上已經做的足夠好。Yarn和Docker一整合，就互補了。

總結

Mesos 和 Yarn 都是非常優秀的調度框架，各有其優缺點，彈性調度，統一的資源管理是未來平臺的一個趨勢，類似的這種資源管理調度框架必定會大行其道。

一些常見的誤解

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

然而，就像我在之前的一篇課程里，反復強調，Hadoop是一個軟件集合，包含分布式存儲，資源管理調度，計算框架三個部分。他們之間沒有必然的關系，是可以獨立開來的。而Yarn 就是一個資源管理調度引擎，其一開始的設計目標就是為了通用，不僅僅是跑MR。現在基于Yarn之上的服務已經非常多，典型的比如Spark。

這里還有另外一個誤區，MR目前基本算是離線批量的代名詞，這回讓人誤以為Yarn也只是適合批量離線任務的調度。其實不然，我在上面已經給出了分析，Yarn 是完全可以保證長任務的穩定可靠的運行的。

作者： 祝威廉