本文深入介紹了去哪兒網(wǎng)利用Mesos和Docker構(gòu)建私有云服務(wù)的全過程，分享了從無狀態(tài)應(yīng)用向有狀態(tài)應(yīng)用逐步過度的經(jīng)驗(yàn)與心得。

平臺概覽

2014年下半年左右，去哪兒完成了有關(guān)構(gòu)建私有云服務(wù)的技術(shù)調(diào)研，并最終拍定了Docker/Mesos這一方案。下圖1展示了去哪兒數(shù)據(jù)平臺的整體架構(gòu)：

圖1：去哪兒數(shù)據(jù)平臺的整體架構(gòu)

該平臺目前已實(shí)現(xiàn)了如下多項(xiàng)功能：

• 每天處理約340億/25TB的數(shù)據(jù);
• 90%的數(shù)據(jù)在100ms內(nèi)完成處理;
• 最長3h/24h的數(shù)據(jù)回放;
• 私有的Elasticsearch Cloud;
• 自動化監(jiān)控與報警。

為什么選擇Docker/Mesos

目前為止，這個數(shù)據(jù)平臺可以說是公司整個流數(shù)據(jù)的主要出入口，包括私有的Elasticsearch Cloud和監(jiān)控報警之類的數(shù)據(jù)。那么為什么選擇Docker/Mesos?

選擇Docker有兩大原因。第一個是打包：對于運(yùn)維來講，業(yè)務(wù)打完包之后，每天面對的是用腳本分發(fā)到機(jī)器上時所出現(xiàn)的各種問題。業(yè)務(wù)包是一個比較上層的話題，這里不做深入的討論，這里講的“打包”指軟件的Runtime層。如果用Docker的打包機(jī)制，把最容易出現(xiàn)問題的Runtime包裝成鏡像并放在registry里，需要的時候拿出來，那么整個平臺最多只執(zhí)行一個遠(yuǎn)程腳本就可以了，這是團(tuán)隊最看好的一個特性。第二個是運(yùn)維：Docker取消了依賴限制，只要構(gòu)建一個虛擬環(huán)境或一個Runtime的鏡像，就可以直接拉取到服務(wù)器上并啟動相應(yīng)的程序。此外Docker在清理上也較為簡單，不需要考慮環(huán)境卸載不干凈等問題。

以常見的計算框架來說，它們本質(zhì)上仍然屬于運(yùn)行在其上的Job的Runtime。綜合上述情況，團(tuán)隊選擇針對Runtime去打包。

選擇Mesos是因?yàn)樗銐蚝唵魏头€(wěn)定，而且擁有較成熟的調(diào)度框架。Mesos的簡單體現(xiàn)在，與Kubernetes相比其所有功能都處于劣勢，甚至?xí)l(fā)現(xiàn)它本身都是不支持服務(wù)的，用戶需要進(jìn)行二次開發(fā)來滿足實(shí)際要求，包括網(wǎng)絡(luò)層。不過，這也恰好是它的強(qiáng)項(xiàng)。Mesos本身提供了很多SDN接口，或者是有模塊加載機(jī)制，可以做自定義修改，平臺定制功能比較強(qiáng)。所以用Mesos的方案，需要考慮團(tuán)隊是否可以Hold住整個開發(fā)過程。

從框架層面來看，Marathon可以支撐一部分長期運(yùn)行的服務(wù)，Chronos則側(cè)重于定時任務(wù)/批處理。

以下圖2是Mesos的一個簡單結(jié)構(gòu)圖：

圖2：Mesos結(jié)構(gòu)

數(shù)據(jù)平臺的最終目標(biāo)架構(gòu)如下圖3所示：

圖3：平臺目標(biāo)

組件容器化與部署

組件的容器化分為JVM容器化和Mesos容器化。JVM容器化需要注意以下幾方面：

潛在創(chuàng)建文件的配置都要注意

java.io.tmpdir  
-XX:HeapDumpPath  
-Xloggc 

-Xloggc會記錄GC的信息到制定的文件中?，F(xiàn)在很少有直接用XLoggc配置的了(已經(jīng)用MXBean方式替代了)。如果有比較老的程序是通過-Xloggc打印GC日志的話，那么要額外掛載volume到容器內(nèi)。

時區(qū)與編碼

–env TZ=Asia/Shanghai  
–volume /etc/localtime:/etc/localtime:ro  
–env JAVA_TOOL_OPTIONS=”-Dfile.encoding=UTF-8 -Duser.timezone=PRC 

時區(qū)是另一個注意點(diǎn)。上面所列的三種不同的方法都可以達(dá)到目的，其中第一/三個可以寫在Dockerfile里，也可以在docker run時通過–env傳入。第二種只在docker run時通過volume方式掛載。另外，第三種額外設(shè)置了字符集編碼，推薦使用此方式。

主動設(shè)置heap

• 防止ergonomics亂算內(nèi)存

這是Docker內(nèi)部實(shí)現(xiàn)的問題。即使給Docker設(shè)置內(nèi)存，容器內(nèi)通過free命令看到的內(nèi)存和宿主機(jī)的內(nèi)存是一樣的。而JVM為了使用方便，會默認(rèn)設(shè)置一個人機(jī)功能會根據(jù)當(dāng)前機(jī)器的內(nèi)存計算一個堆大小，如果我們不主動設(shè)置JVM堆內(nèi)存的話，很有可能計算出一個超過 Memory Cgroup限制的內(nèi)存，啟動就宕掉，所以需要注意在啟動時就把內(nèi)存設(shè)置好。

CMS收集器要調(diào)整并行度

-XX:ParallelGCThreads=cpus  
-XX:ConcGCThreads=cpus/2 

CMS是常見的收集器，它設(shè)置并行度的時候是取機(jī)器的核數(shù)來計算的。如果給容器分配2個CPU，JVM仍然按照宿主機(jī)的核數(shù)初始化這些線程數(shù)量，GC的回收效率會降低。想規(guī)避這個問題有兩點(diǎn)，第一點(diǎn)是掛載假的Proc文件系統(tǒng)，比如Lxcfs。第二種是使用類似Hyper的基于Hypervisor的容器。

Mesos容器化要求關(guān)注兩類參數(shù)：配置參數(shù)和run參數(shù)。

需要關(guān)注的配置參數(shù)

MESOS_systemd_enable_support  
MESOS_docker_mesos_image  
MESOS_docker_socket  
GLOG_max_log_size  
GLOG_stop_logging_if_full_disk 

Mesos是配置參數(shù)最多的。在物理機(jī)上，Mesos默認(rèn)使用系統(tǒng)的Systemd管理任務(wù)，如果把Mesos通過Docker run的方式啟動起來，用戶就要關(guān)systemd_Enable_support，防止Mesos Slave拉取容器運(yùn)行時數(shù)據(jù)造成混亂。

第二個是Docker_Mesos_Image，這個配置告訴Mesos Slave，當(dāng)前是運(yùn)行在容器內(nèi)的。在物理機(jī)環(huán)境下，Mesos Slave進(jìn)程宕掉重啟，、就會根據(jù)executor進(jìn)程/容器的名字做recovery動作。但是在容器內(nèi)，宕機(jī)后executor全部回收了，重啟容器，Slave認(rèn)為是一個新環(huán)境，跳過覆蓋動作并自動下發(fā)任務(wù)，所以任務(wù)有可能會發(fā)重。

Docker_Socket會告訴Mesos，Docker指定的遠(yuǎn)端地址或本地文件，是默認(rèn)掛到Mesos容器里的。用戶如果直接執(zhí)行文件，會導(dǎo)致文件錯誤，消息調(diào)取失敗。這個時候推薦一個簡單的辦法：把當(dāng)前物理機(jī)的目錄掛到容器中并單獨(dú)命名，相當(dāng)于在容器內(nèi)直接訪問整個物理機(jī)的路徑，再重新指定它的地址，這樣每次一有變動Mesos就能夠發(fā)現(xiàn)，做自己的指令。

后面兩個是Mesos Logging配置，調(diào)整生成logging文件的一些行為。

需要關(guān)注的run參數(shù)

• –pid=host
• –privileged
• –net=host (optional)
• root user

啟動Slave容器的時候最好不加Pid Namespace，因?yàn)槿萜鲀?nèi)Pid=1的進(jìn)程一般都是你的應(yīng)用程序，易導(dǎo)致子進(jìn)程都無法回收，或者采用tini一類的進(jìn)程啟動應(yīng)用達(dá)到相同的目的。–privileged和root user主要是針對Mesos的持久化卷功能，否則無法mount到容器內(nèi)，–net=host是出于網(wǎng)絡(luò)效率的考慮，畢竟源生的bridge模式效率比較低。

圖4：去哪兒數(shù)據(jù)平臺部署流程圖

上圖4就是去哪兒數(shù)據(jù)平臺部署的流程圖。

基于Marathon的Streaming調(diào)度

拿Spark on Mesos記錄子，即使是基于Spark的Marathon調(diào)度，也需要用戶開發(fā)一個Frameworks。上生產(chǎn)需要很多代碼，團(tuán)隊之前代碼加到將近一千，用來專門解決Spark運(yùn)行在Master中的問題，但是其中一個軟件經(jīng)常跑到Master，對每一個框架寫重復(fù)性代碼，而且內(nèi)部邏輯很難復(fù)用，所以團(tuán)隊考慮把上層的東西全都跑在一個統(tǒng)一框架里，例如后面的運(yùn)維和擴(kuò)容，都針對這一個框架做就可以了。團(tuán)隊最終選擇了Marathon，把Spark作為Marathon的一個任務(wù)發(fā)下去，讓Spark在Marathon里做分發(fā)。

除去提供維標(biāo)準(zhǔn)化和自動化外，基于Spark的Marathon還可以解決Mesos-Dispatcher的一些問題：

• 配置不能正確同步;這一塊更新頻率特別慢，默認(rèn)速度也很慢，所以需要自己來維護(hù)一個版本。第一個配置不能正確同步，需要設(shè)置一些參數(shù)信息、Spark內(nèi)核核數(shù)及內(nèi)損之類，這里它只會選擇性地抽取部分配置發(fā)下去。
• 基于attributes的過濾功能缺失;對于現(xiàn)在的環(huán)境，所設(shè)置的Attributes過濾功能明顯缺失，不管機(jī)器是否專用或有沒有特殊配置，上來就發(fā)，很容易占滿ES的機(jī)器。
• 按role/principal接入Mesos;針對不同的業(yè)務(wù)線做資源配比時，無法對應(yīng)不同的角色去接入Mesos。
• 不能re-registery;框架本身不能重注冊，如果框架跑到一半掛掉了，重啟之后之前的任務(wù)就直接忽略不管，需要手工Kill掉這個框架。
• 不能動態(tài)擴(kuò)容executor。最后是不能擴(kuò)容、動態(tài)調(diào)整，臨時改動的話只能重發(fā)任務(wù)。

整個過程比較簡單，如下圖5所示：

圖5：替代Spark Mesos Dispatcher

不過還是有一些問題存在：

Checkpoint & Block

• 動態(tài)預(yù)留 & 持久化卷
• setJars
• 清理無效的卷

關(guān)于Checkpoint&Block，通過動態(tài)預(yù)留的功能可以把這個任務(wù)直接“釘死”在這臺機(jī)器上，如果它掛的話可以直接在原機(jī)器上重啟，并掛載volume繼續(xù)工作。如果不用它預(yù)留的話，可能調(diào)度到其他機(jī)器上，找不到數(shù)據(jù)Block，造成數(shù)據(jù)的丟失或者重復(fù)處理。

持久化卷是Mesos提供的功能，需要考慮它的數(shù)據(jù)永存，Mesos提供了一種方案：把本地磁盤升級成一個目錄，把這個轉(zhuǎn)移到Docker里。每次寫數(shù)據(jù)到本地時，能直接通過持久化卷來維護(hù)，免去手工維護(hù)的成本。但它目前有一個問題，如果任務(wù)已被回收，它持久化卷的數(shù)據(jù)是不會自己刪掉的，需要寫一個腳本定時輪巡并對應(yīng)刪掉。

臨時文件

• java.io.tmpdir=/mnt/mesos/sandbox
• spark.local.dir=/mnt/mesos/sandbox

如果使用持久化卷，需要修改這兩個配置，把這一些臨時文件寫進(jìn)去，比如shuffle文件等。如果配置持久化卷的話，用戶也可以寫持久化卷的路徑。

Coarse-Grained

Spark有兩種資源調(diào)度模式：細(xì)粒度和粗粒度。目前已經(jīng)不太推薦細(xì)粒度了，考慮到細(xì)粒度會盡可能的把所有資源占滿，容易導(dǎo)致Mesos資源被耗盡，所以這個時候更傾向選擇粗粒度模式。

圖6：Storm on Marathon

上圖6展示了基于Storm的Marathon調(diào)度，F(xiàn)link也是如此。結(jié)合線上的運(yùn)維和debug，需要注意以下幾方面：

源生Web Console

• 隨機(jī)端口
• OpenResty配合泛域名
• 默認(rèn)源生Web Console，前端配置轉(zhuǎn)發(fā)，直接訪問固定域名。

Filebeat + Kafka + ELK

• 多版本追溯
• 日常排錯
• 異常監(jiān)控

大部分WebUI上看到的都是目前內(nèi)部的數(shù)據(jù)處理情況，可以通過ELK查詢信息。如果任務(wù)曾經(jīng)運(yùn)行在不同版本的Spark上，可以把多版本的日志都追蹤起來，包括日常、問題監(jiān)控等，直接拿來使用。

Metrics

第三個需要注意的就是指標(biāo)。比如Spark ，需要配合Metrics把數(shù)據(jù)源打出來就行。

ELK on Mesos

目前平臺已有近50個集群，約100TB+業(yè)務(wù)數(shù)據(jù)量，高峰期1.2k QPS以及約110個節(jié)點(diǎn)，Elasticsearch需求逐步增多。

圖7：ELK on Mesos

上圖7是ELK on Mesos結(jié)構(gòu)圖，也是團(tuán)隊的無奈之選。因?yàn)镸esos還暫時不支持multi-role framework功能，所以選擇了這種折中的方式來做。在一個Marathon里，根據(jù)業(yè)務(wù)線設(shè)置好Quota后，用業(yè)務(wù)線重新發(fā)一個新的Marathon接入進(jìn)去。對于多租戶來講，可以利用Kubernetes做后續(xù)的資源管控和資源申請。

部署ES以后，有一個關(guān)于服務(wù)發(fā)現(xiàn)的問題，可以去注冊一個callback，Marathon會返回信息，解析出master/slave進(jìn)程所在的機(jī)器和端口，配合修改Haproxy做一層轉(zhuǎn)發(fā)，相當(dāng)于把后端整個TCP的連接都做一個通路。ES跟Spark不完全相同，Spark傳輸本身流量就比較大，而ES啟動時需要主動聯(lián)系Master地址，再通過Master獲取相應(yīng)集群，后面再做P2P，流量比較低，也不是一個長鏈接。

監(jiān)控與運(yùn)維

這部分包括了Streaming監(jiān)控指標(biāo)與報警、容器監(jiān)控指標(biāo)與報警兩方面。

Streaming監(jiān)控指標(biāo)與報警

• Streaming監(jiān)控含拓?fù)浔O(jiān)控和業(yè)務(wù)監(jiān)控兩部分。
• Streaming拓?fù)浔O(jiān)控

業(yè)務(wù)監(jiān)控

• Kafka Topic Lag
• 處理延遲mean90/upper90
• Spark scheduler delay/process delay
• Search Count/Message Count
• Reject/Exception
• JVM

拓?fù)浔O(jiān)控包括數(shù)據(jù)源和整個拓?fù)淞鞒蹋枰脩糇约喝フ砗蜆?gòu)建，更新的時候就能夠知道這個東西依賴誰、是否依賴線上服務(wù)，如果中途停的話會造成機(jī)器故障。業(yè)務(wù)監(jiān)控的話，第一個就是Topic Lag，Topic Lag每一個波動都是不一樣的，用這種方式監(jiān)控會頻繁報警，90%的中位數(shù)都是落在80—100毫秒范圍內(nèi)，就可以監(jiān)控到整個范圍。

容器監(jiān)控指標(biāo)與報警

容器監(jiān)控上關(guān)注以下三方面：

Google cAdvisor足夠有效

• mount rootfs可能導(dǎo)致容器刪除失敗 #771
• –docker_only
• –docker_env_metadata_whitelist

Statsd + Watcher

• 基于Graphite的千萬級指標(biāo)監(jiān)控平臺

Nagios

容器這一塊比較簡單，利用Docker并配合Mesos，再把Marathon的ID抓取出來就可以了。我們這邊在實(shí)踐的過程發(fā)現(xiàn)一個問題，因?yàn)镾tatsd Watcher容易出現(xiàn)問題，你直接用Docker的時候它會報一些錯誤出來，這個問題就是Statsd Watcher把路徑給掛了的原因。目前我們平臺就曾遇到過一次，社區(qū)里面也有人曝，不過復(fù)現(xiàn)率比較低。用的時候如果發(fā)現(xiàn)這個問題把Statsd Watcher直接停掉就好。指標(biāo)的話，每臺機(jī)器上放一個statsd再發(fā)一個后臺的Worker，報警平臺也是這個。

其實(shí)針對Docker監(jiān)控的話，還是存在著一些問題：

基礎(chǔ)監(jiān)控壓力

• 數(shù)據(jù)膨脹
• 垃圾指標(biāo)增多
• 大量的通配符導(dǎo)致數(shù)據(jù)庫壓力較高

單個任務(wù)的容器生命周期

• 發(fā)布
• 擴(kuò)容
• 異常退出

首先主要是監(jiān)控系統(tǒng)壓力比較大。原來監(jiān)控虛擬機(jī)時都是針對每一個虛擬機(jī)的，只要虛擬機(jī)不刪的話是長期匯報，指標(biāo)名固定，但在容器中這個東西一直在變，它在這套體系下用指標(biāo)并在本地之外建一個目錄存文件，所以在這種存儲機(jī)制下去存容器的指標(biāo)不合適。主要問題是數(shù)據(jù)膨脹比較厲害，可能一個容器會起名，起名多次之后，在Graphite那邊對應(yīng)了有十多個指標(biāo)，像這種都是預(yù)生成的監(jiān)控文件。比如說定義每一秒鐘一個數(shù)據(jù)點(diǎn)，要保存一年，這個時候它就會根據(jù)每年有多少秒生成一個RRD文件放那兒。這部分指標(biāo)如果按照現(xiàn)有標(biāo)準(zhǔn)的話，可能容器的生命周期僅有幾天時間，不適用這種機(jī)制。測試相同的指標(biāo)量，公司存儲的方式相對來說比Graphite好一點(diǎn)。因?yàn)镚raphite是基于文件系統(tǒng)來做的，第一個優(yōu)化指標(biāo)名，目錄要轉(zhuǎn)存到數(shù)據(jù)庫里做一些索引加速和查詢，但是因?yàn)槿萜鬟@邊相對通配符比較多，不能直接得知具體對應(yīng)的ID，只能通配符查詢做聚合。因?yàn)殚L期的通配符在字符串的索引上還是易于使用的，所以現(xiàn)在算是折中的做法，把一些常用的查詢結(jié)果、目錄放到里邊。

另一個是容器的生命周期?？梢宰鲆恍徲嫽蛘咦兏陌姹?，在Mesos層面基于Marathon去監(jiān)控，發(fā)現(xiàn)這些狀態(tài)后打上標(biāo)記：當(dāng)前是哪一個容器或者哪一個TASK出了問題，對應(yīng)擴(kuò)容和記錄下來。還有Docker自己的問題，這樣后面做整個記錄時會有一份相對比較完整的TASK-ID。

作者簡介：徐磊，去哪兒網(wǎng)平臺事業(yè)部運(yùn)維開發(fā)工程師，2015年加入去哪兒網(wǎng)，負(fù)責(zé)實(shí)時日志相關(guān)的開發(fā)與運(yùn)維工作。有多年電信、云計算行業(yè)經(jīng)驗(yàn)，曾供職于紅帽中國。