李 超，花 磊，宋云奎

(1.新華通訊社 中國經濟信息社有限公司，北京 100083；2.中國科學院 軟件研究所，北京 100190)

0 引 言

在云計算環(huán)境下，分布式應用通常具有多個應用組件，同時部署在眾多節(jié)點，因此云應用的配置管理面臨著巨大挑戰(zhàn)。首先，云計算引入了虛擬機(VM)，增加了配置管理的復雜度；同時，應用通常需要同時部署在多個云上，而云計算平臺的API缺少統(tǒng)一標準，導致了多云之間不可互操作。以云計算環(huán)境下典型的三層架構電子商務應用Rubis部署為例，分析分布式應用部署所面臨的問題。Rubis是基于Servlet的JavaEE應用，實現(xiàn)了類似于eBay的網上交易應用，提供了交互型事務處理功能，如注冊新用戶、瀏覽、購買商品、付款。管理員使用Apache作為Web服務器分發(fā)請求，Tomcat作為應用服務器處理請求，MySQL作為數(shù)據庫服務器提供數(shù)據存取?？蛻粽埱筇幚矸譃榕c資金相關的關鍵型業(yè)務處理和與瀏覽相關的非關鍵業(yè)務處理。在實際應用中，通常將關鍵業(yè)務部署在公司的私有云計算平臺，由本地主機集群組成；而非關鍵業(yè)務，部署在接近客戶的公有云中托管。公司會根據云計算市場上的虛擬機租用價格，將應用運行在不同的公有云計算平臺(如阿里云、百度云)，當價格調整則將應用從一個云遷移到另一個云并進行自動化配置部署。同時，需要細粒度的應用管理，這樣可以根據更新或遷移需要來決定操作WAR包還是其中的某個Servlet。

針對該典型的應用部署實例，當前的分布式應用部署技術無法適應云計算環(huán)境，主要表現(xiàn)在以下幾點:在云計算環(huán)境中，應用在VM中運行，而VM運行在物理機(PM)上，需要考慮多層部署問題；應用的運行環(huán)境是動態(tài)的，在整個生命周期內會在不同的云之間遷移,需要支持混合云部署；多個應用組件在不同云平臺上部署，并且組件依賴關系存在著多樣性，需要支持細粒度的應用部署管理。因此，文中提出了一個面向多云環(huán)境的可伸縮細粒度的應用自動部署框架CADep，用來管理云平臺內部與基于云的業(yè)務單元之間的交互，以連接各種部署進程和相關資源。CADep主要設計思想如下:使用分層描述方法對應用和執(zhí)行環(huán)境進行細粒度的描述；提供一組可重用組件,其中每個組件執(zhí)行特定功能;實現(xiàn)了基本部署管理機制以感知環(huán)境，并根據環(huán)境與業(yè)務應用做出相應調整。

1 相關工作

當前的許多應用部署研究都是專門針對單個云平臺或單一類型應用。文獻[1]提出了基于Xen的云平臺自動部署框架。文獻[2-3]提出了PM、VM和應用等三個層次的云應用部署的描述語言。文獻[4]提出了與云平臺無關的可移植的應用部署的編排語言。文獻[5]提出一種自動化部署與監(jiān)控Hadoop平臺的系統(tǒng)方案，自動化部署Hadoop平臺,并監(jiān)控集群及其中各個服務的狀態(tài)。文獻[6]提出一種結合Docker容器技術部署集群的解決方案，把Ambari及其運行環(huán)境和配置構建成Docker鏡像，并把多節(jié)點容器的運行和Hadoop集群的部署過程寫成Shell腳本，通過命令實現(xiàn)集群的自動化部署。文獻[7]對Apache ODE結構以及部署、執(zhí)行BPEL流程的原理進行分析，設計算法自動生成部署描述文件和服務的WSDL描述等，從而實現(xiàn)Apache ODE引擎環(huán)境下服務組合的自動化部署和執(zhí)行。文獻[8]基于用戶審計與SSH單向信任安全機制，著力于規(guī)范化、流程化，設計自動化部署方案。文獻[9]提出一種可運營的網絡自動化部署架構,并對電信運營商開展多業(yè)務、多租戶承載的云資源池網絡自動化部署技術選型給出了建議。文獻[10]利用可擴展的通用部署引擎來管理各種應用，從而減少生成定制引擎的步驟以減少構建開銷。Bootware[11]創(chuàng)建部署引擎以部署應用實例，其使用通用部署引擎。文獻[12]復用現(xiàn)有多樣化開源系統(tǒng)，將不同類型的部署可執(zhí)行程序轉換為基于TOSCA標準的構件。云提供商提供了建模和編排工具[13]，同時提供了PaaS(Platform-as-a-Service)服務[14]，調用該服務可以部署和管理應用實例，而不需要顯式建模應用拓撲。文獻[15]提出一種便于移動應用開發(fā)和部署的整合方案,從設備屬性、用戶偏好以及QoS需求等多重維度入手,采用體系結構驅動的方法對應用進行建模,并生成滿足用戶個性化需求的部署方案。以上方法難以實現(xiàn)多云混合部署場景，將應用或部分應用自動化遷移非常困難。同時，必須通過開發(fā)自定義的粘合代碼來手動包裝，因此只適用于特定部署場景，缺乏通用性。

2 分布式云應用自動部署框架CADep

2.1 架構設計

CADep設計目標是能夠描述復雜分布式應用，并自動實現(xiàn)整個應用或各應用組件的靈活部署。該框架提供了微內核機制，通過動態(tài)插入新的功能組件來應對新的應用和部署環(huán)境，從而具有靈活性，以支持部署規(guī)模的伸縮以及應用的動態(tài)重配。圖1描述了CADep架構，由以下幾個模塊構成：

(1)部署管理器(DM)：提供VM接口以管理VM及其應用，在PM中實例化VM及其應用。

(2)代理：部署在VM的軟件組件，使用插件對應用實例進行部署和管理，并支持不同部署技術(如Ansible、Puppet)。CADep使用輕量級微內核，插件可以靈活加入內核，通過異步消息實現(xiàn)服務器間通信。

(3)應用實例管理器：作為CADep的插件，在不同的軟件平臺上監(jiān)控應用實例并管理其生命周期。

(4)消息服務器：負責在DM和代理之間通過消息服務器進行異步通信，包括消息定義、消息服務器與應用實例的交互接口。

(5)構件和鏡像庫：可以從本地或公共存儲庫中管理和檢索軟件包與VM鏡像。鏡像庫將每個需要的VM鏡像映射到相應的基礎設施組件，所需的VM鏡像可以是公共VM鏡像庫中的可用鏡像或者是人工創(chuàng)建的鏡像文件。

(6)管理控制臺：基于Shell的控制臺和基于AngularJS的Web應用，提供不同用戶界面，將Java Bean轉換為JSON并通過REST與部署管理器進行交互。

CADep負責啟動VM并部署軟件，在軟件組件之間動態(tài)解析依賴關系，更新組件配置，并啟動所有組件。CADep以非侵入方式管理應用生命周期，支持應用組件彈性伸縮的熱重配，并且保持組件啟動或停止時的一致性。應用組件為其他應用組件提供服務，并且依賴于其他應用組件所提供的服務。應用組件使用消息隊列進行通信，并根據部署或啟動的服務執(zhí)行相應的操作，而這些操作由插件實現(xiàn)(如Java的Servlet、OSGi的Bundle)。CADep采用基于RESTFul的分布式通信技術，支持IaaS層或PaaS層的云應用部署，能夠滿足多云需求，如組件細粒度的分層描述，動態(tài)的依賴管理，并發(fā)的組件部署，多云的分布式部署，以及制定可配置的部署計劃。

2.2 部署方法

2.2.1 系統(tǒng)配置

CADep將分布式應用作為相互調用的組件集合，并且定義相關導入導出的相關變量。典型的分布式架構應用(如Rubis)通常包括表示層(如Apache)、邏輯層(如Tomcat)和數(shù)據層(如MySQL)。其中，組件是指Apache，而實例是指部署在特定主機的Apache實例，組件之間交換數(shù)據是字符串或結構化數(shù)據。分布式應用的組件需要導入導出變量(如IP地址或端口號)，需要來自其他應用的變量為“導入變量”，其他應用組件需要的變量為“導出變量”，例如，Apache導入來自于Tomcat變量，即應用服務器的IP地址和端口號。此外，組件可以繼承導入導出變量的默認值，如Tomcat組件可以繼承“應用服務器”組件的屬性。文中定義了組件與實例的導入導出變量，表1給出了Apache和MySQL的組件配置，其中，安裝參數(shù)是強制的組件屬性，指定了CADep的插件以管理部署組件實例。文中采用Ansible作為插件，導入變量列出了啟動前需要被解析的變量。例如，Tomcat導出IP變量，依賴組件將導入該變量；MySQL導出了其他組件所需要的變量，而無需從其他組件導入變量。

配置文件包括應用描述符與應用關系圖，前者包含應用的元信息(名稱、版本限定符)，后者描述了軟件組件(如虛擬機、云平臺、應用包)，并且定義了包含和運行時關系。包含關系描述了可以在一個組件上部署另一個組件，例如，在VM上部署Tomcat服務器，或者在Tomcat服務器上部署Web應用。運行時關系描述了共同工作的組件，例如，Web應用需要數(shù)據庫(包括數(shù)據庫的IP地址和端口)。這些信息通常采用硬編碼，而CADep在運行時解析，通過配置或管理API來更新組件(如JMX、REST)，可以并行部署Apache、Tomcat和MySQL。Tomcat部署時，在獲得數(shù)據庫位置之前，將無法啟動。數(shù)據庫部署并啟動后，CADep將更新Tomcat配置，以便獲得MySQL位置，從而形成運行時間依賴關系。

CADep列出了開發(fā)人員希望部署或可能部署的應用組件，包括部署的根節(jié)點(如VM、設備、遠程主機)、數(shù)據庫、應用服務器、應用模塊(如WAR，ZIP)。將應用作為組件的層次結構，準確追蹤系統(tǒng)中實現(xiàn)的實例，從而在動態(tài)部署中做出決策。分層模型解析包含關系，以及導入導出變量模型的運行時關系，同時，使用圖來決定哪些組件可以實例化以及如何部署。圖中建模的內容是各種粒度的組件，將應用組件進行捆綁，例如將給定的WAR與應用服務器相關聯(lián)。

CADep為部署的應用提供三個文件。第一個文件包含CADep配置的應用描述文件，該文件描述了應用信息，如應用名、功能描述、模型文件的位置等；第二個文件描述了應用組件之間的關聯(lián)圖，其中，組件是安裝的軟件，也可以是部署的VM等；第三個文件提供了部署組件所需的資源(如腳本、軟件包、配置文件)。在運行時，CADep首先實例化組件，對實例進行分層結構描述，然后對其配置以準備部署。如果根組件帶有子組件，那么必須在根實例中定義子實例，并且將實例的屬性覆蓋組件的屬性，例如，如果Tomcat組件導出具有默認值8080的端口屬性，則實例可能會以實際端口(如8081)覆蓋。

2.2.2 初始部署

文中使用三層架構的應用實例來描述CADep的工作方式。圖2描述了組件之間的依賴關系，在云計算平臺彈性伸縮的場景中，可以對多個Tomcat節(jié)點進行增刪，以適應負載的變化，但需要對Apache節(jié)點進行動態(tài)重新配置，使得請求轉發(fā)模塊可以感知所有可用的Tomcat節(jié)點。CADep在3個獨立的虛擬機中部署Apache、MySQL和Tomcat，并在特定依賴關系下更新配置文件，例如，CADep發(fā)現(xiàn)MySQL的IP地址和端口號時，發(fā)送到Tomcat節(jié)點，這樣它就可以更新配置并啟動。VM支持Apache、Tomcat或MySQL組件的部署，并且每個組件都以導入導出形式進行描述。有了該描述信息，CADep就能夠感知何時可以啟動部署組件，通過導入導出配置信息來實現(xiàn)組件之間的數(shù)據交換，同時，實現(xiàn)應用組件的生命周期管理，例如，在導入配置信息時啟動組件。

圖2 組件描述

2.2.3 動態(tài)重部署

當系統(tǒng)處于運行狀態(tài)，創(chuàng)建、更改或刪除實例時，需要指定要實例化或修改的組件，重命名組件實例并定義部署位置。例如，由于負載增加，需要自動添加新Tomcat實例的VM，創(chuàng)建新的VM實例，代理會監(jiān)測到運行環(huán)境的變化，并向DM發(fā)送通知。CADep提供了規(guī)則來響應檢測到的變化，DM執(zhí)行相應動作對環(huán)境變化做出響應。例如，CADep從本地Zabbix的Agent中獲取CPU等度量，如果度量超過閾值，則將運行狀態(tài)發(fā)送給DM。DM調用請求處理程序來響應該消息，添加完整路徑以及兩個實例到應用模型中。在添加過程的開始階段，這兩個新程序都沒有啟動，后來由DM部署并啟動它們。DM首先創(chuàng)建VM，向VM發(fā)送部署命令，并在上面部署新的Tomcat實例；然后，CADep代理將該實例的相關信息進行發(fā)布，即新Tomcat實例的IP地址和端口號；Apache負載均衡器會收到該信息，部署在該VM上的代理將調用一個CADep插件來更新Apache服務器的配置文件，這樣負載均衡器就可以感知這兩個Tomcat服務器。

3 實例研究

3.1 實驗1：部署時間比較

3.1.1 實驗環(huán)境

CADep解析組件的動態(tài)依賴關系，同時并發(fā)部署組件。CADep與典型的部署框架Cloudify、RightScale和Scalr進行部署時間的對比，每個框架分別重復部署10次。文中選擇阿里云作為部署應用的云計算平臺，使用Ansible作為CADep的安裝插件，部署Rubis應用。如果用戶可以使用Web瀏覽器連接并登錄Administration頁面，并創(chuàng)建數(shù)據庫，則表明部署成功。每個框架都有自己的生命周期管理，將所有這些狀態(tài)分成啟動和運行等兩個階段。

(1)啟動階段:客戶端發(fā)送“部署”請求到DM，DM處理請求，并獲得腳本和其他必要的文件，啟動腳本(包括設置代理、向DM發(fā)送啟動信息等)。具體步驟包括：資源供給、啟動虛擬機、部署Apache、MySQL、Administration。

(2)運行階段:系統(tǒng)執(zhí)行腳本，在服務器上運行服務或組件，包括預設狀態(tài)(下載tarball、傳輸腳本和必要的文件到VM、準備運行時環(huán)境等)，配置，安裝(將資源和配置文件放置到正確位置，并設置權限等)，預啟動(建立軟件組件的依賴關系)，啟動，生效(更新變量，配置監(jiān)控)。具體步驟包括：啟動Apache、MySQL、Administration。

3.1.2 實驗結果與分析

表2給出了應用部署時間的比較，部署時間為從啟動到最后一個組件正確安裝的時間。實驗結果表明，CADep的部署時間明顯比其他框架都要低；Scalr與CADep的部署階段的時間最為接近；運行階段的時間比CADep的少，這是由于其不解析服務間的動態(tài)依賴關系；在Scalr中，組件之間的依賴關系是通過WebUI中的配置來交換部署信息，雖然時間較短，但操作復雜，易于出錯。

表2 應用部署時間比較

s

3.2 實驗2：部署工作量

3.2.1 實驗環(huán)境

該實驗基于OSGi的SPECjms2007基準測試應用，部署在阿里云的VM上。OSGi應用通常由一個或多個OSGi組件構成，以提供應用的運行時環(huán)境并管理OSGi組件，如Joram、JNDI。使用阿里云的兩個VM實例，分別選擇Felix或Equinox作為底層OSGi框架以管理Joram實例、OSGi JNDI實例和JMS OSGi客戶端，由“osgi-bundle”安裝程序管理。由于Cloudify提供了腳本語言，可以用來表達分布式應用結構，故選擇了Cloudify作為比較對象，但CADep以分層結構描述應用，而Cloudify則以扁平結構描述應用。

3.2.2 實驗結果與分析

CADep用戶只需要為每個阿里云VM實例分別編寫一個部署計劃，而多個OSGi組件(包括Joram、CADep、JNDI)可以重用相同的部署計劃。然而，Cloudify用戶則需要為VM實例和每個組件分別編寫一個對應的部署計劃，總共需要編寫六個部署計劃，是CADep編寫部署計劃工作量的兩倍。該實驗結果表明，CADep具有細粒度描述組件的能力，具有較好的適用性，能夠減少開發(fā)部署計劃的工作量。

3.3 實驗3：部署復雜度

3.3.1 實驗環(huán)境

在多云平臺上部署流數(shù)據處理系統(tǒng)Storm集群以執(zhí)行流數(shù)據處理，將CADep和根據說明書手動部署時間進行比較。Storm由Zookeeper集群、Nimbus服務器、Storm管理器組成，需要安裝JZMQ、ZeroMQ和Python。該實驗在多云環(huán)境中進行，使用兩個公有云(阿里云和百度云)和一個私有云(Xen Serve)。CADep為這些云提供了三個IaaS插件，以協(xié)調IaaS平臺間的服務調用，其中每個插件都需要實現(xiàn)API Java接口。實現(xiàn)這些插件的代碼行數(shù)分別為：阿里云196行代碼，百度云387行代碼，而Xen Server是132行代碼。Zookeeper安裝在阿里云，Nimbus安裝在百度云，Storm安裝在Xen Server私有云平臺。

3.3.2 實驗結果與分析

Storm的在線安裝指南有8頁長度的篇幅，同時也有許多依賴的外部文檔鏈接。要求一名未曾安裝過Storm的軟件運維工程師按照安裝指南手動對其進行配置，其第一次安裝用了7小時18分鐘，第二次安裝用了4小時12分鐘，而第三次安裝則用了1小時14分鐘。理解描述不夠詳細的安裝說明、解決環(huán)境問題、尋找下載所需的依賴包以及調試等操作消耗了其大量時間。同樣的工作是由另一位從未配置安裝過Storm的軟件運維工程師使用CADep完成，時間主要用于編寫Zookeeper,Nimbus,Supervisors,JZMQ,ZeroMQ和Python的部署計劃。他編寫140行左右的Storm組件的部署腳本，配置之后可以通過CADep對Storm進行管理(部署、啟動、停止、反部署、更新)，并自動連接到其他應用。部署腳本開發(fā)時間大約是2小時35分鐘，其中，38分鐘用來設計組件，75分鐘用來編寫腳本，42分鐘用于調試和測試。如果需要從Internet上下載所需的包，安裝Storm需要26分鐘；如果從本地存儲庫檢索包，安裝Storm大約9分鐘。使用CADep自動化安裝Storm，可以使得開發(fā)者在多云上部署其應用，而無需了解實現(xiàn)的技術細節(jié)。同時，CADep保證了過程的可重復，為大規(guī)模系統(tǒng)部署提供了便利。該實驗結果表明，CADep能夠支持多云分布式環(huán)境的部署，同時降低了分布式應用部署的復雜性。

4 結束語

CADep是細粒度可伸縮的多云部署框架，基于輕量級微內核實現(xiàn)了基本部署機制，使用動態(tài)可插拔組件實現(xiàn)了應用部署的改進和擴展。同時，框架多層次細粒度描述應用和執(zhí)行環(huán)境，實現(xiàn)了組件(如PM、VM、應用)的精細管理。實驗結果表明，與典型的分布式應用部署框架相比，CADep具有較短的部署時間，有效降低了部署的工作量，減輕了部署的難度，適用于多云環(huán)境下復雜分布式應用的高效部署。

參考文獻：

[1] ZHANG Youhui, LI Yanhua, ZHENG Weimin.Automatic software deployment using user-level virtualization for cloud-computing[J].Future Generation Computer Systems,2013,29(1):323-329.

[2] DE ALFONSO C,CABALLER M,ALVARRUIZ F,et al.Infrastructure deployment over the cloud[C]//Third international conference on cloud computing technology and science.Athens,Greece:IEEE,2011:517-521.

[3] SEINTURIER L,MERLE P,FOURNIER D,et al.A component-based middleware platform for reconfigurable service-oriented architectures[J].Software Practice & Experience,2012,42:559-583.

[4] BINZ T,BREITER G,LEYMANN F,et al.Portable cloud services using TOSCA[J].IEEE Internet Computing,2012,16(3):80-85.

[5] 于金良,朱志祥,李聰穎.Hadoop平臺的自動化部署與監(jiān)控研究[J].計算機與數(shù)字工程,2016,44(12):2457-2461.

[6] 李 杰,劉廣鐘.Hadoop分布式集群的自動化容器部署研究[J].計算機應用研究,2016,33(11):3404-3407.

[7] 黃 亮,姚放吾,金仙力.Apache ODE環(huán)境下Web服務組合技術的研究[J].計算機技術與發(fā)展,2011,21(7):98-100.

[8] 王海俠,吳愛華,曾衛(wèi)明.基于JBoss和Tomcat的自動化部署研究[J].現(xiàn)代計算機,2015(13):38-42.

[9] 賴培源,馬衛(wèi)民,劉 藝,等.云資源池網絡自動化部署技術研究與實踐[J].電信科學,2015,31(7):96-103.

[10] LU Hongbin,SHTERN B,SIMMONS M,et al.Pattern-based deployment service for next generation clouds[C]//Ninth world congress on services.Santa Clara,CA,USA:IEEE,2013:464-471.

[11] VUKOJEVIC-HAUPT K,KARASTOYANOVA D,LEYMANN F.On-demand provisioning of infrastructure,middleware and services for simulation workflows[C]//6th international conference on service-oriented computing & applications.Koloa,HI,USA:IEEE,2013:91-98.

[12] ANDRIKOPOULOS V,REUTER A,GOMEZ-SAEZ S,et al.A GENTL approach for cloud application topologies[C]//Service-oriented and cloud computing.[s.l.]:[s.n.],2014:148-159.

[13] ROSNER T.Learning AWS OpsWorks[M].UK:Packt Publishing Ltd,2013.

[14] COUTERMARSH M.Heroku cookbook[M].UK:Packt Publishing Ltd,2014.

[15] 張曉薇,曹東剛,陳向群,等.一種網絡化移動應用部署方案優(yōu)化方法[J].軟件學報,2011,22(12):2866-2878.