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

平臺概覽

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

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

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

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

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

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

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

以下圖2是Mesos的一個簡單結構圖：

圖2：Mesos結構

數(shù)據(jù)平臺的最終目標架構如下圖3所示：

圖3：平臺目標

組件容器化與部署

組件的容器化分為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ū)是另一個注意點。上面所列的三種不同的方法都可以達到目的，其中第一/三個可以寫在Dockerfile里，也可以在docker run時通過–env傳入。第二種只在docker run時通過volume方式掛載。另外，第三種額外設置了字符集編碼，推薦使用此方式。

主動設置heap

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

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

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

 

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

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

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

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

 

MESOS_systemd_enable_support  
MESOS_docker_mesos_image  
MESOS_docker_socket  
GLOG_max_log_size  
GLOG_stop_logging_if_full_disk 

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

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

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

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

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

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

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

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

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

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

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

除去提供維標準化和自動化外，基于Spark的Marathon還可以解決Mesos-Dispatcher的一些問題：

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

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

圖5：替代Spark Mesos Dispatcher

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

Checkpoint & Block

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

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

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

臨時文件

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

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

Coarse-Grained

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

圖6：Storm on Marathon

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

源生Web Console

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

Filebeat + Kafka + ELK

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

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

Metrics

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

ELK on Mesos

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

圖7：ELK on Mesos

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

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

監(jiān)控與運維

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

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

• Streaming監(jiān)控含拓撲監(jiān)控和業(yè)務監(jiān)控兩部分。
• Streaming拓撲監(jiān)控

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

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

拓撲監(jiān)控包括數(shù)據(jù)源和整個拓撲流程，需要用戶自己去整理和構建，更新的時候就能夠知道這個東西依賴誰、是否依賴線上服務，如果中途停的話會造成機器故障。業(yè)務監(jiān)控的話，第一個就是Topic Lag，Topic Lag每一個波動都是不一樣的，用這種方式監(jiān)控會頻繁報警，90%的中位數(shù)都是落在80—100毫秒范圍內(nèi)，就可以監(jiān)控到整個范圍。

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

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

Google cAdvisor足夠有效

• mount rootfs可能導致容器刪除失敗 #771
• –docker_only
• –docker_env_metadata_whitelist

Statsd + Watcher

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

Nagios

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

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

基礎監(jiān)控壓力

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

單個任務的容器生命周期

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

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

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

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