JRC用戶需求多樣復(fù)雜，用戶要求的資源配置也大小不一，系統(tǒng)更新部署步驟繁瑣，人工操作亦有極大的安全風(fēng)險(xiǎn)，與此同時(shí)，用戶的資源需求也越來越多，大集群支持、資源節(jié)省亦是我們應(yīng)該重點(diǎn)關(guān)注的問題。

本文就來介紹一種我們京東為了解決上述問題而研發(fā)的基于docker的實(shí)時(shí)計(jì)算平臺(tái)。

現(xiàn)狀以及問題

storm集群結(jié)構(gòu)：

storm拓?fù)浣Y(jié)構(gòu)：

storm瓶頸

從storm架構(gòu)圖可以看出，storm整個(gè)集群對(duì)zookeeper的依賴非常大，無論是拓?fù)渑渲?、分配信息、心跳、錯(cuò)誤信息，均存儲(chǔ)在zookeeper中，而nimbus每次分配、更新任務(wù)，均需要從zookeeper中獲取這些信息，因此nimbus的壓力非常大，特別是當(dāng)單集群worker使用量超過5000時(shí)，每次分配、更新任務(wù)所耗的時(shí)間經(jīng)常需要幾分鐘，其中特別是worker心跳對(duì)zookeeper所造成的壓力影響最甚。

眾所周知，京東業(yè)務(wù)廣泛，對(duì)實(shí)時(shí)計(jì)算的需求也很大，對(duì)應(yīng)所要求的集群規(guī)模也不可能小，因此京東對(duì)于上述這些問題也必須做出改變以適應(yīng)自身業(yè)務(wù)的發(fā)展，其中***的改變即是對(duì)拓?fù)鋺?yīng)用結(jié)構(gòu)的改變，增設(shè)了TopologyMaster角色，把metrics、心跳、背壓等信息均由TopologyMaster處理，大大減輕了nimbus及zookeeper壓力，當(dāng)然啦，還有很多很多很不錯(cuò)的改動(dòng)，但這不是本文的重點(diǎn)，就不在此累贅了。改變后的拓?fù)浣Y(jié)構(gòu)為

為響應(yīng)京東集群資源上云號(hào)召，京東實(shí)時(shí)計(jì)算平臺(tái)雖然解決了大集群、資源隔離等用戶或集群所面臨的重要問題，但若直接把整個(gè)storm照搬上彈性云平臺(tái)虛擬機(jī)使用，則無法滿足資源隔離需求，屆時(shí)，集群用戶任務(wù)之間的相互影響很可能帶來各種不可預(yù)見的問題，因此我們必需對(duì)storm底層進(jìn)行一次完整的改造。

技術(shù)架構(gòu)實(shí)現(xiàn)

如圖所示，我們將Storm的Nimbus功能進(jìn)行拆分，將拓?fù)涞闹饕芾砺毮芙唤oTopologyMaster，改造后的storm在我們內(nèi)部稱之為Mars，意寓發(fā)現(xiàn)新大陸。

Mars主要有以下幾個(gè)特性。

1.二級(jí)調(diào)度

改造后的Nimbus只需管理TopologyMaster的調(diào)度，其它如UI訪問、命令下發(fā)、拓?fù)涓?、分配、背壓、metrics、心跳等，均由TopologyMaster負(fù)責(zé)處理，真正實(shí)現(xiàn)了完整意義上的二級(jí)調(diào)度。

2.資源隔離

改造后每個(gè)docker實(shí)例下只有一個(gè)supervisor，并且每個(gè)supervisor里只用一個(gè)worker，通過每個(gè)docker一個(gè)worker來進(jìn)行worker級(jí)別的資源隔離。此外，我們引入了組的概念，不用用戶申請(qǐng)的資源也可以統(tǒng)一放到一個(gè)組上，一個(gè)任務(wù)只能運(yùn)行在一個(gè)組內(nèi)，并通過產(chǎn)品化來引入權(quán)限管理，以此保證不同用戶申請(qǐng)的資源不會(huì)被他人占用。

3.全高可用(High Availability)

基礎(chǔ)進(jìn)程HA

我們?cè)诿總€(gè)docker實(shí)例里內(nèi)置一個(gè)管理進(jìn)程mars admin，并配置crontab每分鐘檢測(cè)mars admin進(jìn)程狀態(tài)，保證mars admin發(fā)生異常后自動(dòng)重啟。Mars admin管理著supervisor進(jìn)程、進(jìn)行日志服務(wù)的doctor進(jìn)程、抓取日志的bee進(jìn)程，這些進(jìn)程的啟停與更新由mars admin來執(zhí)行，保障每個(gè)docker實(shí)例里的基礎(chǔ)進(jìn)程的HA。

Nimbus HA

我們通過Zookeeper來實(shí)現(xiàn)Active-Standby模式的nimbus ha，由于改造后nimbus的工作內(nèi)容很少，因此單機(jī)執(zhí)行完全足夠滿足需求。

TopologyMaster HA

TopologyMaster會(huì)定期與Nimbus進(jìn)行心跳交互，若Nimbus檢測(cè)到TM心跳超時(shí)，則會(huì)重新調(diào)起一個(gè)新的TM，新的TM會(huì)將自身信息寫入Zookeeper中，其它Container與Supervisor將通過Zookeeper來識(shí)別到新的TM，從而保障TM的HA。

Container/Worker HA

Container會(huì)定期與TM進(jìn)行交互，若TM檢測(cè)到Container心跳超時(shí)，則會(huì)重新從資源池里調(diào)起一個(gè)新的Container接管原來失效Container的任務(wù)，并把新的任務(wù)分配寫入Zookeeper中，以便其它Container識(shí)別新的Container的位置，從而保障Container的HA。

4.自動(dòng)部署

由于一個(gè)docker一個(gè)worker，而一個(gè)docker實(shí)例可以理解為一個(gè)虛擬機(jī)，用戶資源申請(qǐng)具有隨機(jī)性、配置個(gè)性化等特點(diǎn)，因此對(duì)我們配置管理上必需具有自適應(yīng)性。對(duì)此我們通過提供一個(gè)特殊鏡像，通過產(chǎn)品化把JRC與云平臺(tái)資源申請(qǐng)打通，并把資源配置、包部署等功能產(chǎn)品化，以達(dá)到自動(dòng)部署的目的。

總結(jié)

基于docker的實(shí)時(shí)計(jì)算平臺(tái)是京東自行研發(fā)的全新的、自動(dòng)化的實(shí)時(shí)計(jì)算平臺(tái)，它基于storm理念，通過重新設(shè)計(jì)整個(gè)底層架構(gòu)及運(yùn)行邏輯，并添加背壓、壓縮、限速、監(jiān)控、日志等輔助功能，經(jīng)過產(chǎn)品化并與彈性云平臺(tái)打通，達(dá)到了用戶申請(qǐng)即可用、配置個(gè)性化、大規(guī)模集群的要求，操作高效且自動(dòng)化。

36大數(shù)據(jù)(www.36dsj.com)成立于2013年5月，是中國(guó)訪問量***的大數(shù)據(jù)網(wǎng)站。36大數(shù)據(jù)(微信號(hào):dashuju36)以獨(dú)立第三方的角度，為大數(shù)據(jù)產(chǎn)業(yè)生態(tài)圖譜上的需求商 、應(yīng)用商、服務(wù)商、技術(shù)解決商等相關(guān)公司及從業(yè)人員提供全球資訊、商機(jī)、案例、技術(shù)教程、項(xiàng)目對(duì)接、創(chuàng)業(yè)投資及專訪報(bào)道等服務(wù)。