亚洲在线久爱草,狠狠天天香蕉网,天天搞日日干久草,伊人亚洲日本欧美

為了賬號安全,請及時綁定郵箱和手機立即綁定
已解決430363個問題,去搜搜看,總會有你想問的

kafka是否適合在docker中使用?單機集群是否有意義

kafka是否適合在docker中使用?單機集群是否有意義

呼啦一陣風 2019-05-31 07:02:31
kafka是否適合在docker中使用?單機集群是否有意義
查看完整描述

2 回答

?
jeck貓

TA貢獻1909條經驗 獲得超7個贊

可部署性

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

二次開發

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

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

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

生態優勢

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

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

長任務支持

談及長任務(long running
services)的支持,有人認為早先Yarn是為了支持離線短時任務的,所以可能對長任務的支持有限。其實大可不必擔心,譬如現在基于其上的
Spark Streaming就是7x24小時運行的,跑起來也沒啥問題。一般而言,要支持長任務,需要考慮如下幾個點:

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

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

Fault tolerance

Yarn 自身高可用。目前Yarn的Master已經實現了HA。
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?,F在基于Yarn之上的服務已經非常多,典型的比如Spark。

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

如何基于Yarn開發分布式程序

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

代碼使用范例可以參看Spark Yarn相關的代碼。算的上是一個非常精簡的Yarn的adaptor。
買本Yarn相關的書,了解其體系結構也有助于你了解其API的設計。

接下來的內容會探討以下兩個主題:

基于Yarn開發分布式程序需要做的一些準備工作
基于Yarn開發容器調度系統的一些基本思路

基于Yarn開發分布式程序需要做的一些準備工作

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

Yarn原生的API太底層,太復雜了

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

最好是能開發一個解決一類問題的Framework

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

所以通常而言,基于Yarn的分布式應用應該符合這么一個層次:

Yarn -> Adapter -> Framework -> Application

Adapter 就是我第一條說的,你自個封裝了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與被啟動的這個docker container 一一對應;
slave定時監控Container;
slave發現container crash,slave自動退出,Yarn獲得通知,收回資源;
master發現有節點失敗,發出新的節點要求,重新在另外一臺服務器上啟動slave,重復從2開始的步驟。

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

了解了這個思路后,具體實施就變得簡單了,就是開發一個基于Yarn的master-slave程序即可,然后slave去管理對應的Docker容器,包括接受新的指令。master提供管理界面展示容器信息,運行狀態即可。

當然,你還可以再開發一套Framework B專門和Nginx交互,這樣比如上面的系統做了節點變更,通知B的master,然后B的master 通過自己的伴生組件Slave 完成Nginx的更新,從而實現后端服務的自動變更和通知。





查看完整回答
反對 回復 2019-06-01
  • 2 回答
  • 0 關注
  • 1170 瀏覽
慕課專欄
更多

添加回答

舉報

0/150
提交
取消
微信客服

購課補貼
聯系客服咨詢優惠詳情

幫助反饋 APP下載

慕課網APP
您的移動學習伙伴

公眾號

掃描二維碼
關注慕課網微信公眾號