可部署性先說明下，這裏探討的是Yarn或者Mesos集群的部署，不涉其上的應用。Yarn除了依賴JDK，對操作系統沒有任何依賴，基本上放上去就能跑。Mesos因為是C/C++開發的，安裝部署可能會有庫依賴。這點我不知道大家是否看的重，反正我是看的相當重的。軟件就應該是下下來就可以Run。所以12年的時候我就自己開發了壹套Java服務框架，開發完之後運行個main方法就行。讓應用包含容器，而不是要把應用丟到Tomcat這些容器，太復雜，不符合直覺。二次開發Yarn對Java/Scala工程師而言，只是個Jar包，類似索引開發包Lucene，妳可以把它引入項目，做任何妳想要的包裝。這是其壹。其二，Yarn提供了非常多的擴展接口，很多實現都是可插拔。可替換的，在XML配置下，可以很方便的用妳的實現替換掉原來的實現，沒有太大的侵入性，所以就算是未來Yarn升級，也不會有太大問題。相比較而言，Mesos更像是壹個已經做好的產品，部署了可以直接用，但是對二次開發並不友好。生態優勢Yarn誕生於Hadoop這個大數據的“始作俑者”項目，所以在大數據領域具有先天優勢。底層天然就是分布式存儲系統HDFS，穩定高效。其上支撐了Spark、MR等大數據領域的扛頂之座，久經考驗。社區強大，最近發布版本也明顯加快，對於長任務的支持也越來越優秀。長任務支持談及長任務（longrunningservices）的支持，有人認為早先Yarn是為了支持離線短時任務的，所以可能對長任務的支持有限。其實大可不必擔心，譬如現在基於其上的SparkStreaming就是7x24小時運行的，跑起來也沒啥問題。壹般而言，要支持長任務，需要考慮如下幾個點：Faulttolerance，主要是AM的容錯。YarnSecurity，如果開啟了安全機制，令牌等的失效時間也是需要註意的。日誌收集到集群。還有就是資源隔離和優先級。如果資源隔離做的太差，會對長時任務產生影響。大家感興趣可以先參考Jira。我看這個Jira13年就開始了，說明這事很早就被重視起來了。下面我們隊提到的幾個點做下解釋。FaulttoleranceYarn自身高可用。目前Yarn的Master已經實現了HA。AM容錯，我看從2.4版本（看的源碼，也可能更早的版本就已經支持）就已經支持keepcontainersacrossattempt的選項了。什麽意思呢？就是如果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是完全可以保證長任務的穩定可靠的運行的。如何基於Yarn開發分布式程序本文不會具體教妳如何使用Yarn的API，不過如果妳想知道Yarn的API，但是又覺得官方文檔太過簡略，我這裏倒是可以給出兩個建議：代碼使用範例可以參看SparkYarn相關的代碼。算的上是壹個非常精簡的Yarn的adaptor。買本Yarn相關的書，了解其體系結構也有助於妳了解其API的設計。接下來的內容會探討以下兩個主題：基於Yarn開發分布式程序需要做的壹些準備工作基於Yarn開發容器調度系統的壹些基本思路基於Yarn開發分布式程序需要做的壹些準備工作肯定不能擼起袖子就開始幹。開始動手前，我們需要知道哪些事情呢？Yarn原生的API太底層，太復雜了如果妳想愉快的開發Yarn的應用，那麽對Yarn的API進行壹次封裝，是很有必要的。Yarn為了靈活，或者為了能夠滿足開發者大部分的需求，底層交互的API就顯得比較原始了。自然造成開發難度很大。這個也不是我壹個人覺得，現在Apache的Twill，以及Hulu他們開發的時候Adaptor那壹層，其實都是為了解決這個問題。那為什麽我沒有用Twill呢，第壹是文檔實在太少，第二是有點復雜，我不需要這麽復雜的東西。我覺得，Twill與其開發這麽多功能，真的不如好好寫寫文檔。最好是能開發壹個解決壹類問題的FrameworkYarn只是壹個底層的資源管理和調度引擎。壹般妳需要基於之上開發壹套解決特定問題的Framework。以Spark為例，他是解決分布式計算相關的壹些問題。而以我開發的容器調度程序，其實是為了解決動態部署Web應用的。在他們之上，才是妳的應用。比如妳要統計日誌，妳只要在Spark上開發壹個Application。比如妳想要提供壹個推薦系統，那麽妳只要用容器包裝下，就能被容器調度程序調度部署。所以通常而言，基於Yarn的分布式應用應該符合這麽壹個層次：Yarn->Adapter->Framework->ApplicationAdapter就是我第壹條說的，妳自個封裝了Yarn的API。Framework就是解決壹類問題的編程框架，Application才是妳真正要解決業務的系統。通過這種解耦，各個層次只要關註自己的核心功能點即可。保證妳上層的Framework/Application可以移植Spark是個典型，他可以跑在Mesos上，也可以跑在Yarn上，還可以跑在自己上面（Standalone），實時上，泡在Yarn上的，以及跑Standalone模式的，都挺多的。這得益於Spark本身不依賴於底層的資源管理調度引擎。這其實也是我上面說的兩條帶來的好處，因為有了Adaptor，上層的Framework可以不用綁死在某個資源調度引擎上。而Framework則可以讓Applicaiton無需關註底層調度的事情，只要關註業務即可。另外，妳費盡心機開發的Framework上，妳自然是希望它能跑在的平臺上，已滿足的人的需求，對吧。基於Yarn開發容器調度系統的壹些基本思路首先我們需要了解兩個概念：啞應用。所謂啞應用指的是無法和分布式系統直接進行交互，分布式系統也僅僅透過容器能進行生命周期的控制，比如關閉或者開啟的應用。典型的比如MySQL、Nginx等這些基礎應用。他們壹般有自己特有的交互方式，譬如命令行或者socket協議或者HTTP協議。伴生組件。因為有了啞應用的存在，分布式系統為了能夠和這些應用交互，需要有壹個代理。而這個代理和被代理的啞應用，具有相同的生命周期。典型的比如，某個服務被關停後，該事件會被分布式系統獲知，分布式系統會將該事件發送給Nginx的伴生組件，伴生組件轉化為Nginx能夠識別的指令，將停止的服務從Nginx的ProxyBackend列表中剔除。在容器調度系統中，如果Yarn的NodeManager直接去管理Docker則需要Yarn本身去做支持，我覺得這是不妥的。Yarn的職責就是做好資源管理，分配，調度即可，並不需要和特定的某個技術耦合，畢竟Yarn是壹個通用型的資源調度管理框架。那基於上面的理論，我們基於Yarn，開發壹套框架，這個框架會是典型的master-slave結構（這是Yarn決定的）。這個框架的slaves其實都是Docker的伴生對象。master可以通過這些Slave對容器實現間接的管理。我們簡單描述下他們的流程：用戶提交Application，申請資源；Yarn啟動Framework的master；Yarn啟動Framework的slave；slave連接上master，並且發送心跳，從而master知道slave的狀況slave啟動Docker，slave與被啟動的這個dockercontainer壹壹對應；slave定時監控Container；slave發現containercrash，slave自動退出，Yarn獲得通知，收回資源；master發現有節點失敗，發出新的節點要求，重新在另外壹臺服務器上啟動slave，重復從2開始的步驟。這裏還有壹個問題，如果slave被正常殺掉，可以通過JVMShudownHook順帶把Container也關掉。但是如果slave被kill-9或者異常crash掉了，那麽就可能導致資源泄露了。目前是這個信息是由master上報給集群管理平臺，該平臺會定時清理。妳也可以存儲該信息，譬如放到Redis或者MySQL中，然後啟動後臺清理任務即可。了解了這個思路後，具體實施就變得簡單了，就是開發壹個基於Yarn的master-slave程序即可，然後slave去管理對應的Docker容器，包括接受新的指令。master提供管理界面展示容器信息，運行狀態即可。當然，妳還可以再開發壹套FrameworkB專門和Nginx交互，這樣比如上面的系統做了節點變更，通知B的master，然後B的master通過自己的伴生組件Slave完成Nginx的更新，從而實現後端服務的自動變更和通知。
上一篇:大學進什麽社團比較好？下一篇:深圳匯極星嵌入式培訓怎麽樣