一種基于Docker的數(shù)據(jù)中心云平臺實現(xiàn)方法及系統(tǒng)

彭勇+謝劍+童遙+申光

摘要：為解決現(xiàn)有平臺即服務(wù)（PaaS）云平臺的可用性和兼容性等問題，提出了一種基于Docker的通用容器解決方案，并進一步提出基于該容器的云平臺系統(tǒng)架構(gòu)，詳細描述了各個子系統(tǒng)及其功能模塊的設(shè)計實現(xiàn)。認為通過引入動態(tài)調(diào)度模塊，并復用多個分布式系統(tǒng)的公共組件，將使該系統(tǒng)架構(gòu)的調(diào)度能力更加開放。

關(guān)鍵詞： PaaS；Docker；平臺架構(gòu)；資源調(diào)度

1 應用服務(wù)部署現(xiàn)狀

隨著信息化技術(shù)的深入發(fā)展，數(shù)據(jù)中心的應用服務(wù)數(shù)量急劇增加，原有采用實體機和虛擬機部署應用服務(wù)的方式面臨著以下的問題：

（1）數(shù)據(jù)中心資源利用率不高。

（2）應用環(huán)境管理復雜，維護效率不高。

（3）應用服務(wù)遷移困難。

（4）傳統(tǒng)應用服務(wù)部署啟動慢。

2 現(xiàn)有PaaS云平臺分析和Docker容器技術(shù)

2.1 現(xiàn)有PaaS云平臺分析

平臺即服務(wù)（PaaS）是云服務(wù)的一種[1]，服務(wù)提供商不僅提供按需索取的硬件和操作系統(tǒng)服務(wù)，還提供了應用程序平臺和解決方案。通過PaaS平臺，應用開發(fā)者可以很方便地把應用和服務(wù)托管在平臺之上，而不用關(guān)心它們底層的硬件配置和運行環(huán)境。目前，業(yè)界已涌現(xiàn)出眾多的PaaS云平臺[2]，但它們均存在很大的不足。首先就是應用的運行環(huán)境兼容性較差，單一化的運行托管環(huán)境會導致應用的兼容性降低，不利于PaaS平臺的快速擴張和通用性要求；其次，PaaS平臺內(nèi)置的基礎(chǔ)能力也不足，無法滿足應用提供者對于能力的多樣化需求[3]；另外，現(xiàn)有的PaaS云平臺一般僅提供針對特定編程語言的應用運行環(huán)境，如Google應用程序工程（GAE）[4]僅支持Python和Java運行環(huán)境，新浪應用程序工程（SAE）[5]僅支持Java和PHP5運行環(huán)境，因此急需提升平臺的可用性和擴展性。

2.2 Docker容器技術(shù)

Docker是基于Linux的LXC（Linux容器）技術(shù)，把應用包裝在容器里，使其具有移植性和獨立性。具體來講，Docker提供標準化的Image和Image共享等功能，能夠很簡便地在Docker內(nèi)部嵌入一個Web服務(wù)器（如Jetty、Tomcat等），更重要的是，使用Docker可以運行非常多的容器進程，針對不同Web服務(wù)能提供不同的Image，并將各類不同的應用運行環(huán)境統(tǒng)一封裝，對外提供統(tǒng)一管理和操作接口，提高PaaS平臺的可用性和靈活性。

3 基于Docker的PaaS云平臺設(shè)計

基于Docker的數(shù)據(jù)中心云平臺的系統(tǒng)架構(gòu)如圖1所示，下面對該PaaS云平臺涉及的主要實體和實體間的邏輯子模塊進行描述。

（1）云平臺調(diào)度子系統(tǒng)。

云平臺調(diào)度子系統(tǒng)是整個云平臺的大腦，用于合理地分配系統(tǒng)資源，具體說來就是一個容器到底落地在哪些物理服務(wù)器上[6]。調(diào)度子系統(tǒng)可細分為兩個部分：初次調(diào)度和動態(tài)調(diào)度。初次調(diào)度是當用戶第一次創(chuàng)建應用時進行的調(diào)度，包括資源的創(chuàng)建、刪除、修改等操作；而動態(tài)調(diào)度是指在系統(tǒng)運行過程中的調(diào)度，主要是針對某些負載過高、過低的容器進行scaling out、scaling in的調(diào)度，實現(xiàn)資源的合理分配、整合。

（2）路由控制子系統(tǒng)。

路由控制子系統(tǒng)在PaaS云平臺中對所有進來的請求進行路由，該系統(tǒng)分為兩層：第1層是從外部域名到內(nèi)部臨時域名的路由，第2層是從內(nèi)部臨時域名到容器的路由[7]。提供內(nèi)部臨時域名是為了方便應用開發(fā)者在提交應用之后再次檢查確認，路由控制子系統(tǒng)還提供負載均衡、健康檢查、會話粘滯等高級功能。

（3）通用容器子系統(tǒng)。

通用容器可抽象出兩層，分別為適配層和容器層。適配層一方面可以作為駐留結(jié)點采集主機負載等信息，另一方面可以適配底層的容器。容器層則是在Docker 應用程序編程接口（API）的基礎(chǔ)上封裝出不同的Web容器，比如Docker-Jetty、Docker-Tomcat等。同時還引入了鏡像服務(wù)器這個集中式鏡像管理模塊。

（4）平臺支撐子系統(tǒng)。

平臺支撐子系統(tǒng)是平臺中的基礎(chǔ)模塊，提供基礎(chǔ)能力的支持，比如：API 服務(wù)器將系統(tǒng)的能力統(tǒng)一抽象出restful的HTTP接口，Memcached提供不同容器之間的session共享，Cache提供高性能的分布式對象緩存服務(wù)，Mysql提供原生的關(guān)系型數(shù)據(jù)庫，F(xiàn)reedisk提供小文件存儲的服務(wù)。

4 基于Docker的PaaS云平臺實現(xiàn)

本系統(tǒng)分為資源調(diào)度子系統(tǒng)、路由控制子系統(tǒng)、通用容器、平臺支撐子系統(tǒng)4個子系統(tǒng)。

4.1 資源調(diào)度子系統(tǒng)的實現(xiàn)

資源調(diào)度子系統(tǒng)是整個系統(tǒng)的核心，當PaaS應用請求通過API 服務(wù)器到達系統(tǒng)內(nèi)部時，是由資源調(diào)度子系統(tǒng)決定數(shù)據(jù)流的走向。

對于調(diào)度子系統(tǒng)，我們在實現(xiàn)時又細分為初次調(diào)度和動態(tài)調(diào)度[8]。

初次調(diào)度是指請求第1次到來時的調(diào)度，調(diào)度子系統(tǒng)在收到申請部署應用之后，通過該次調(diào)度決定承載該應用的多個容器分別落在哪幾臺物理服務(wù)器上。

而動態(tài)調(diào)度是指在系統(tǒng)運行過程中，通過對應用狀態(tài)和容器狀態(tài)的監(jiān)測控制，對應用動態(tài)地進行擴容、縮容等。

資源調(diào)度子系統(tǒng)主要包括的模塊如下所述。

（1）初次資源調(diào)度器：實現(xiàn)所有初次資源操作請求的中轉(zhuǎn)和協(xié)調(diào)，實現(xiàn)方式分為兩步。第1步先取出所有的物理服務(wù)器，針對不同的請求策略使用不同的過濾器來過濾物理服務(wù)器，得到可用的服務(wù)器列表，保證主機的可用性。第2步是引入權(quán)重和打分概念，初次資源調(diào)度器通過不同的權(quán)重計算每個主機的得分，然后按照主機的得分從高到低排序，并把應用部署多個副本（默認是2個）到得分高的主機上。

（2）動態(tài)資源調(diào)度器：實現(xiàn)動態(tài)調(diào)度，動態(tài)地增加、減少應用后端容器的數(shù)量。動態(tài)資源調(diào)度器獲取到主機和Docker容器的負載信息后，按如下策略完成應用副本擴充：根據(jù)相應的調(diào)度策略選擇負載最低的主機，在該主機上部署此應用的副本，同時向路由子系統(tǒng)發(fā)送請求，請求修改路由的指向，使得新加入的應用副本可接收請求，從而實現(xiàn)負載均衡。當集群中所有主機都接近于高負載狀態(tài)時，將停止應用副本的擴充，并向管理員發(fā)出告警郵件。同理，若發(fā)現(xiàn)某應用的所有副本的平均訪問量過低，則按一定策略進行應用副本的收縮，此外，在副本擴充和收縮的過程中，添加定期碎片整理，在保證同一應用的多個副本分布在不同主機的前提下，盡量將分散的應用匯集到部分主機上。

（3）節(jié)點代理：一方面作為駐留進程運行在每個計算節(jié)點上，周期性地向初次資源調(diào)度器上報心跳數(shù)據(jù)，心跳數(shù)據(jù)包含CPU利用率、內(nèi)存使用率和硬盤剩余空間等信息；另一方面適配底層的Docker容器，并獲取其上每個容器的負載數(shù)據(jù)，包括CPU占用率、內(nèi)存使用率、硬盤讀寫狀態(tài)等。

4.2 路由控制子系統(tǒng)的實現(xiàn)

路由控制子系統(tǒng)維護了整個系統(tǒng)的路由信息，包括外部域名到內(nèi)部臨時域名和內(nèi)部臨時域名到容器（ip+端口）的映射，在底層通過對Nginx反向代理服務(wù)器的控制來實現(xiàn)Web請求的分發(fā)和比例控制。

路由控制子系統(tǒng)包括如下所述的主要模塊。

（1）APP路由器：整個PaaS云平臺路由的核心控制組件，該組件負責維護1份包含所有應用路由策略的路由表，并根據(jù)特定的任務(wù)調(diào)度算法控制Nginx以完成對應用訪問請求的路由，實現(xiàn)多個應用副本間的負載均衡、健康檢查、會話粘滯等功能。該模塊在接收到域名增加或刪除操作的時候，先進行合法性判斷，確定合法之后再判斷是否需要更新路由表，如果需要則通知Ngnix控制器進行路由表的更新操作。

（2）Ngnix控制器：跟Nginx同機部署。在收到APP路由器的更新路由信息的通知后，從數(shù)據(jù)庫中加載最新的路由信息，并通過Java的Velocity技術(shù)生成對應的配置文件，替換當前Nginx的配置文件并重啟Nginx，從而使得路由信息及時生效。

（3）Tengine：在Nginx的基礎(chǔ)上，針對大訪問量網(wǎng)站的需求，添加了高級功能和特性，比如一致性hash，會話保持，健康檢查，根據(jù)服務(wù)器狀態(tài)自動上線、下線等。

4.3 通用容器的實現(xiàn)

基于對Docker的封裝，提供了多種Web容器，比如Java的容器、PHP的容器等。另外，為了方便平臺管理者快速發(fā)布、刪除容器，還創(chuàng)新性地引入鏡像服務(wù)器這個集中式鏡像管理模塊。

4.4 平臺支撐子系統(tǒng)的實現(xiàn)

該平臺還包括其他一些支撐組件，具體如下所述。

（1）API服務(wù)器：整個系統(tǒng)對外提供的接口，使用Spring框架實現(xiàn)，把系統(tǒng)的能力通過Restful的HTTP接口暴露出來，方便系統(tǒng)管理員調(diào)用。

（2）Memcached：整個PaaS平臺容器的內(nèi)存共享池，通過在容器內(nèi)部把session信息重定向到該共享內(nèi)存池中，實現(xiàn)會話保持[9]。

（3）Nginx-Log：分析Nginx的日志信息，采集每個應用訪問量等信息。

（4）基礎(chǔ)能力：比如Mysql數(shù)據(jù)庫、定時任務(wù)等一些公用的服務(wù)。

5 結(jié)束語

針對現(xiàn)有應用服務(wù)部署存在的問題，以及現(xiàn)有PaaS云平臺兼容性和擴展性的問題，我們提出了一種基于Docker的數(shù)據(jù)中心PaaS云平臺實現(xiàn)方法。

未來可以使用容器逐步替換數(shù)據(jù)中心云平臺中所有基礎(chǔ)模塊，如監(jiān)測控制模塊、負載均衡模塊、服務(wù)管理模塊、日志收集模塊、消息中心管理模塊等，使數(shù)據(jù)中心云平臺計算、存儲進一步分離。

參考文獻

[1] 吳朱華. 云計算核心技術(shù)剖析[M]. 北京：人民郵電出版社， 2011

[2] 卜文軍， 鄒朝斌， 于佳琳. 熱點云計算平臺推薦[J]. 硅谷，2011， 10（5）：10-10. DOI： 10.3969/j.issn.1671-7597.2011.05.010

[3] 徐鵬， 陳思， 蘇森. 互聯(lián)網(wǎng)應用PaaS平臺體系結(jié)構(gòu)[J]. 北京郵電大學學報， 2012， 35（1）：120-124. DOI： 10.3969/j.issn.1007-5321.2012.01.028

[4] 李露. GAE的技術(shù)發(fā)展及應用[J]. 科技創(chuàng)業(yè)月刊， 2012， 26（8）：192-193. DOI： 10.3969/j.issn.1672-2272.2012.08.088

[5] 叢磊. 新浪云計算SAE的技術(shù)演變[J]. 程序員， 2014， 15（9）：90-95

[6] NIVODHINI M K， KOUSALYA K， MALLIGA S. Algorithms to Improve Scheduling Techniques in IaaS Cloud[C]// ICICES 2013， USA：IEEE， 2013：246-250. DOI： 10.1109/ICICES.2013.6508188

[7] 高允翔， 湯泳， 肖偉. 運營商私有云的DaaS構(gòu)建方案初探[J]. 郵電設(shè)計技術(shù)， 2012， 55（10）：20-22

[8] VAQUERO L M， RODERO-MERINO L， BUYYA R. Dynamically Scaling Application in the Cloud[J]. ACM SIGCOMM Computer Communication Review， 2011， 41（1）：45-52. DOI： 10.1145/1925861.1925869

[9] PETROVIC J. Using Memcached for Data Distribution in Industrial Environment[C]// ICONS 08， USA：IEEE， 2008：368-372. DOI：10.1109/ICONS.2008.51