為什么我要選擇使用Yarn來做Docker的調(diào)度引擎-創(chuàng)新互聯(lián)

編者按

Mesos 和 Yarn 都是非常優(yōu)秀的資源調(diào)度框架，社區(qū)也有很多的人分析二者的區(qū)別以及使用場景。之前 InfoQ 也有發(fā)問聊過二者的關(guān)系。目前業(yè)界用的較多的是 Mesos，這篇文章就是為了解釋為什么作者選擇使用 Yarn 而不是 Mesos，并介紹了如何基于 Yarn 開發(fā)分布式程序。本文首發(fā)于祝威廉的博客，經(jīng)授權(quán)由 InfoQ 轉(zhuǎn)載發(fā)布。

創(chuàng)新互聯(lián)公司專注于成都做網(wǎng)站、網(wǎng)站設(shè)計、網(wǎng)頁設(shè)計、網(wǎng)站制作、網(wǎng)站開發(fā)。公司秉持“客戶至上,用心服務(wù)”的宗旨,從客戶的利益和觀點(diǎn)出發(fā),讓客戶在網(wǎng)絡(luò)營銷中找到自己的駐足之地。尊重和關(guān)懷每一位客戶，用嚴(yán)謹(jǐn)?shù)膽B(tài)度對待客戶，用專業(yè)的服務(wù)創(chuàng)造價值，成為客戶值得信賴的朋友，為客戶解除后顧之憂。

前言

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

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

Yarn VS Mesos

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

可部署性

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

二次開發(fā)

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

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

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

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

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

底層天然就是分布式存儲系統(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 是為了支持離線短時任務(wù)的，所以可能對長任務(wù)的支持有限。其實(shí)大可不必?fù)?dān)心，譬如現(xiàn)在基于其上的 Spark Streaming 就是 7x24 小時運(yùn)行的，跑起來也沒啥問題。一般而言，要支持長任務(wù)，需要考慮如下幾個點(diǎn)：

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

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

Fault tolerance

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

日志收集到集群

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

資源隔離

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

小結(jié)

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

一些常見的誤解

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Yarn -> Adapter -> Framework -> Application

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

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

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

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

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

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

首先我們需要了解兩個概念：

啞應(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)用交互，需要有一個代理。而這個代理和被代理的啞應(yīng)用，具有相同的生命周期。典型的比如，某個服務(wù)被關(guān)停后，該事件會被分布式系統(tǒng)獲知，分布式系統(tǒng)會將該事件發(fā)送給 Nginx 的伴生組件，伴生組件轉(zhuǎn)化為 Nginx 能夠識別的指令，將停止的服務(wù)從 Nginx 的 ProxyBackend 列表中剔除。

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

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

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

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

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

了解了這個思路后，具體實(shí)施就變得簡單了，就是開發(fā)一個基于 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ù)的自動變更和通知。

現(xiàn)在看來，是不是這種概念完美的覆蓋了應(yīng)用之間的交互呢？

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

網(wǎng)頁標(biāo)題：為什么我要選擇使用Yarn來做Docker的調(diào)度引擎-創(chuàng)新互聯(lián)
本文鏈接：http://www.bm7419.com/article8/iheop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供云服務(wù)器、服務(wù)器托管、網(wǎng)站設(shè)計、靜態(tài)網(wǎng)站、網(wǎng)站營銷、標(biāo)簽優(yōu)化

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容