何震葦,嚴麗云,李慧云,張 凌,陸 鋼
(中國電信股份有限公司廣州研究院 廣州510630)
高速發展的互聯網業務平臺面臨用戶需求頻繁變化和用戶規模快速增長的問題,互聯網業務平臺需要具備快速部署、可靠運行和彈性擴展的能力。隨著互聯網業務平臺的發展趨于技術多樣化、架構復雜化和集群規模化,其部署管理也變得越來越困難。云計算IaaS技術實現了業務平臺硬件資源的池化共享,簡化了業務平臺在硬件層面上的部署過程。云計算PaaS技術則實現了中間件數據庫等平臺軟件的池化共享,在一定程度上也簡化了業務平臺軟件層面的部署過程。然而傳統純IaaS和純PaaS的應用部署方式都存在一定的局限性,純IaaS方式基于虛擬機鏡像模板,缺乏對基礎軟件和應用軟件部署層面的支持,需要較多的軟件手工安裝配置操作,部署效率較低,而純PaaS方式則無法自主選擇集群的架構和依賴的基礎軟件,部署的靈活性較差。
Docker和Cloudify等新興PaaS平臺的出現,為解決上述問題提供了構建簡單、靈活、高效、全堆棧、全流程的互聯網業務平臺部署方案的可能。
互聯網云業務平臺通常由若干個服務器集群構成,每個服務器集群又由若干個服務器節點構成,每個服務器節點又由硬件資源和包含若干層軟件的軟件棧構成,在云環境中部署的業務平臺硬件依賴于底層云資源池的計算、存儲和網絡資源。互聯網云業務平臺的典型部署架構如圖1所示。
互聯網云業務平臺的部署需要處理3種依賴關系:軟件依賴關系、拓撲依賴關系和資源依賴關系。
(1)軟件依賴關系
業務平臺節點的軟件通常由多個層次的軟件堆棧構成,上層軟件的安裝依賴于下層軟件的安裝。整個軟件堆棧從下到上一般可分為4層:操作系統、平臺軟件、技術框架和應用程序。操作系統通常是類Linux操作系統,如Ubuntu、CentOS;平臺軟件通常是數據庫、Web服務器等擁有獨立的進程空間和服務端口的服務器軟件,如Tomcat、MySQL等;技術框架是依附在平臺軟件上,提供特定語言相關的軟件功能的框架或類庫,如SSH(Struts+Spring+Hibernate)、Log4J等;應用程序是指實現業務邏輯、提供業務相關功能的程序或軟件分組。
在業務平臺的部署環境中,同一個集群的節點、不同集群的節點甚至不同業務平臺的節點可能采用相同或類似(至少有兩層相同)的軟件棧,例如圖1中負載均衡集群和Web服務集群中的負載均衡器就采用完全相同的Nginx軟件棧。而另一方面,不同的互聯網業務平臺甚至同一個平臺的類似集群有可能使用不同的技術框架,例如圖1的Web服務集群A使用Tomcat+SSH框架實現Web頁面服務,而Web服務集群B則使用NodeJS+DozerJS框架實現Web API服務。
(2)拓撲依賴關系

圖1 典型互聯網云業務平臺部署架構
大型互聯網業務平臺往往涉及多個集群,每個集群又由若干個節點或子集群構成,節點與節點之間通過服務端口通信,業務平臺的部署需要建立業務平臺的拓撲結構,解決節點與節點、節點與集群以及集群與集群之間的關系。節點與節點的關系一般是通信關系,源節點通過服務端口與目標節點建立通信連接,平臺部署時需要將目標節點的服務端口(如IP、端口、URL等)配置到源節點上,并保證源節點與目標節點的3層鏈路可通達。節點與集群的關系通常是從屬關系,包括網絡從屬和節點從屬,網絡從屬是指集群的節點與集群屬于同一子網,節點從屬是指集群的節點由集群的某個主節點管理或控制,集群的部署需要根據從屬關系對網絡和集群主節點進行相應的配置,同時通過從屬關系可對整個集群的節點進行批量操作,如批量配置、批量重啟。集群與集群的關系可以是從屬關系或者通信關系,集群從屬關系的建立需要將子集群的子網加入父集群的子網中,將子集群的主節點服務端口加入父集群主節點配置中,集群的通信關系需要解決不同集群子網之間的路由轉發問題。
(3)資源依賴關系
互聯網云業務平臺通常基于共享的云資源池構建,業務平臺的部署需要估算業務平臺的資源需求,根據資源需求從云資源池中申請恰當規格和額度的虛擬機、虛擬存儲和虛擬網絡資源,將業務平臺的節點和集群與底層的云資源綁定。在大規模、混合云的部署場景中,業務平臺的各個集群可能會由不同的云資源池甚至不同的云資源平臺提供資源,業務平臺部署不僅要適配各種類型的云資源接口,還需要屏蔽不同云資源池的資源接口差異性。
互聯網業務平臺的自動部署就是在平臺的部署過程中盡可能自動地解決上述的軟件依賴關系、拓撲依賴關系和資源依賴關系,由部署平臺自動完成業務平臺的各種資源、子集群、節點和軟件的分配、安裝和配置,并將開發團隊提交的應用包加載到相應的應用節點上,最終讓整個業務集群準確無誤地運行。
互聯網業務平臺的自動化部署的關鍵需求如下。
(1)自動處理業務節點的軟件依賴關系
能夠按照軟件堆棧的層次結構自動完成業務節點整個軟件棧的各層軟件的安裝、配置和啟動,可復用具有相同或相似層次軟件棧的安裝步驟。
(2)自動處理業務平臺的拓撲依賴關系
能夠方便地建立業務平臺的拓撲模型,描述平臺的集群、子集群、節點之間的從屬關系、通信關系和依賴關系,根據從屬關系和依賴關系遞歸完成整個集群的部署,根據通信關系自動完成節點和網絡的相關參數配置。可復用具有相同結構的集群拓撲和部署流程。
(3)支持主流的云資源平臺
支 持OpenStack、CloudStack、vSphere等 業 界 主 流 的 云資源平臺,提供一致的計算、存儲和網絡資源訪問接口。
(4)支持任意語言/框架/架構
支持任意語言、任意技術框架和任意拓撲架構的互聯網云業務平臺自動部署。
(5)提升業務平臺的部署密度和部署效率
在相同規格的服務器上能夠部署更多的節點,壓縮節點的軟件棧以提升單個節點的部署效率,增加平臺節點部署的并行度,以提升整個集群的部署效率。
在諸多開源PaaS平臺中,Docker和Cloudify是兩款熱門的與環境、語言無關的PaaS平臺,可用于部署任意語言開發的互聯網應用,前者側重于軟件層面的鏡像化部署,后者側重于全堆棧的標準化部署。
Docker是一個開源的容器引擎,遵從Apache 2.0開源協議。Docker像集裝箱一樣將應用及其相關依賴進行整體打包,部署到任何支持Docker的環境中運行,讓應用的開發、部署和運維都變得簡單。Docker自2013年開源后不久就得到了Google、微軟、IBM、RedHat等業界巨頭公司的關注和支持,在2014年已成為關注程度排名第二的開源軟件,僅次于OpenStack。Docker將各種環境依賴和應用程序一起打包成標準的鏡像文件,利用輕量級的容器虛擬化技術進行資源隔離和應用運行,多個容器共享同一個操作系統,從而可以快速進行應用的部署、啟動、銷毀和移植,并降低每個應用實例的資源開銷。
Docker平臺可以解決互聯網業務平臺部署的軟件依賴關系和部署效率問題。
(1)簡化業務節點的軟件依賴關系
Docker可以將業務節點軟件棧上的一層或多層軟件打包成鏡像,記錄鏡像之間的層次依賴關系,多個鏡像可以像積木一樣層層疊加,部署軟件時只需要指定頂層鏡像,Docker就能根據鏡像的依賴關系從下往上依次安裝鏡像,從而完成整個節點軟件棧的安裝部署。
(2)標準化節點軟件的管理和部署接口
由于業務模塊及其依賴關系被打包成標準化的鏡像,可以統一各類軟件的打包、存儲、安裝和運行接口,降低節點軟件自動化部署難度。
(3)提升業務節點的部署速度
由于不需要部署Guest操作系統,Docker鏡像大小通常為MB級,無論是鏡像的打包、傳輸,還是安裝的速度都比傳統的虛擬機鏡像方式要快得多。同時,Docker將業務節點的軟件棧標準化,將其進行整體打包后存儲在Docker鏡像倉庫中,部署時只需要從Docker鏡像倉庫中獲取需要的鏡像進行移植即可。因此,Docker將傳統的應用部署流程“安裝—配置—運行”轉變為“復制—運行”,從而大大提升了業務節點的部署速度。
Cloudify是一個支持TOSCA(topology and orchestration specification for cloud application)標準的云編排和部署平臺,同樣遵循Apache 2.0開源協議。TOSCA提供標準化的云應用編排模型,由標準化組織OASIS制定,可用于構建云環境下的各類復雜應用集群的全生命周期管理模型,通過結構化的描述語言定義應用節點能力、應用軟件堆棧和應用節點關系,通過基于工作流的管理計劃支撐云應用的部署、調度、升級自動化。
Cloudify是第一個支持TOSCA 1.1規范的開源部署平臺,提供基于TOSCA模型的應用集群部署全流程支持,包括應用集群編排、集群部署、集群監控、彈性調度和應用升級等環節。同時,Cloudify也是一個全面支持硬件、網絡和軟件部署的全堆棧部署平臺,不僅集成了OpenStack、CloudStack等IaaS層的云資源管理平臺,實現硬件資源、NFV網絡的分配與配置,還集成了Puppet、Chef等軟件配置平臺,可實現業務平臺軟件的安裝和配置。
Cloudify平臺可以解決互聯網業務平臺集群拓撲依賴關系和云資源依賴關系問題。
(1)復雜業務集群的編排與模板化
采用TOSCA的YAML模型對業務集群的架構、節點、關系以及所依賴的硬件、軟件資源和配置腳本進行形式化描述,形成應用集群模板,將復雜的業務集群變成結構化、可視化、可復用的模型。
(2)無縫對接主流云資源平臺
Cloudify從3.0版本采用與OpenStack一樣的Python語言重寫,能夠與OpenStack進行代碼級的無縫集成,可實現計算、存儲、網絡資源的分配、設置和調度,同時Cloudify也 提 供 了 官 方 的 插 件 與CloudStack、vSphere、AWS、MS Azure等主流IaaS平臺對接。
(3)平臺部署全流程自動化
由Cloudify的工作流引擎驅動TOSCA模型中的部署流程,以串行或并行的方式依次調用各個節點的管理操作API,執行節點的安裝、配置和啟動的任務,從而完成整個集群的自動化部署。
互聯網應用集群自動化部署平臺通過Docker鏡像技術打包應用節點的軟件依賴關系,通過TOSCA模型定義應用集群的拓撲依賴關系,通過Cloudify適配底層云資源,并驅動整個部署流程的執行。集群自動部署平臺需遵循以下設計原則。
·高內聚、松耦合:實現相同職責的業務邏輯聚合在同一個模塊中,模塊與模塊之間通過接口或消息機制解耦。
·高可用、高容錯:部署平臺的核心部件采用集群架構部署,以避免單點故障,同時部署的中間狀態應持久化保存,即使系統宕機也能快速恢復部署流程。
·輕量級、易擴展:部署平臺由輕量級的內核和可擴展的插件構成,平臺內核僅提供核心的部署模型管理和部署流程驅動功能,保持平臺架構與核心部件相對穩定,云資源適配、資源調度、資源監控等功能通過插件機制擴展。
·開源化、低成本:借鑒互聯網業界的最佳技術實踐,盡量采用成熟度高、活躍度高、應用廣泛開源PaaS平臺框架構建部署平臺,避免重復“造車輪”,以降低平臺的構建成本,提高平臺構建效率。
互聯網云應用集群自動部署平臺基于開源云計算平臺Docker、Cloudify和OpenStack構建,整個互聯網應用集群部署平臺由門戶、PaaS管理器、IaaS管理器、鏡像倉庫和應用集群5部分構成,體系架構如圖2所示。其中鏡像倉庫存儲了應用集群所需的操作系統、基礎軟件、技術框架和應用軟件等鏡像,IaaS管理器以API的形式提供應用集群計算、存儲和網絡資源的申請、配置、調度和銷毀服務,PaaS管理器提供TOSCA部署模型解析、部署流程執行、資源監控和彈性調度等自動部署的核心功能,應用集群節點通過預裝的虛擬機監視器(VMM)和Docker引擎實現應用軟件棧的加載和運行。PaaS管理器通過調度流程引擎和TOSCA容器,執行應用集群部署流程,通過管理代理調用OpenStack和Docker引擎的管理接口,完成整個應用集群的部署。

圖2 互聯網業務自動化部署平臺總體架構
鏡像倉庫負責存儲OVF系統鏡像、基礎軟件鏡像、技術框架鏡像庫和應用工件鏡像,整個鏡像倉庫由OVF鏡像倉庫和Docker鏡像倉庫構成。OVF系統鏡像倉庫存放應用節點的系統級鏡像,其內容包括操作系統、Docker引擎和Cloudify節點代理,該鏡像倉庫由OpenStack的鏡像管理模塊Glance實現;Docker鏡像倉庫存放基礎軟件、技術框架和應用工件等輕量級的Docker層次化鏡像,基于Docker registry模塊實現。
PaaS管理器是整個部署平臺的核心模塊,基于最新的Cloudify 3.1穩定版構建,實現了基于TOSCA模型的應用集群部署、監控和調度服務。整個PaaS管理器由REST服務器、TOSCA容器、工作流引擎、策略引擎、消息總線、管理代理和管理插件構成。REST服務器將PaaS管理器的所有服務封裝成REST API,向門戶提供輕量級、標準化的服務調用接口。TOSCA容器負責TOSCA模型的解析、存儲和加載,為流程引擎和上層應用提供應用集群的靜態元數據和運行時狀態數據。工作流引擎負責執行TOSCA模型定義的各種管理流程,包括集群部署、彈性調度和故障恢復等。策略引擎根據平臺采集的監控指標進行操作決策,并通過工作流引擎或管理代理執行具體的管理操作。管理代理封裝了各類軟硬件資源的管理、配置、激活和調度接口,平臺的管理能力可通過管理插件擴展,通過OpenStack插件無縫對接OpenStack平臺,實現計算、存儲、網絡資源的分配和調度,通過Docker插件對接Docker引擎,實現對Docker容器和鏡像的管理。需要指出的是,Cloudify 3.1尚未提供官方的Docker管理插件,需要基于Cloudify的插件機制開發Docker插件才能對接Docker平臺,實現Docker鏡像安裝和應用容器運行。
Docker引擎是驅動Docker容器加載運行應用軟件棧的核心模塊,它駐留在應用節點上,負責Docker鏡像的上傳下載和Docker容器的啟動銷毀。Docker引擎是應用節點上的一個守護服務進程,該守護進程在后臺啟動了一個服務進程,接收Docker客戶端(即Docker管理插件)發送的請求,根據客戶端的請求類型,通過路由與分發調度機制執行相應的任務,進行鏡像和容器的處理。
通過一個簡單的示例描述部署平臺在云應用集群部署過程中核心部件的協作關系。假設要部署的應用集群由一個負載均衡器、兩個Web服務集群和一個數據庫服務器構成,其中每個Web服務器集群由2~4個Web服務器構成。如圖3所示,應用集群的拓撲模型采用TOSCA規范描述,每個方框表示一個邏輯節點(可以是集群或服務節點),每個箭頭表示節點的依賴關系或通信關系,每個節點由名字、屬性和操作構成,部分節點列出了節點的鏡像、節點的最小實例數、最大實例數,例如“(服務A,2:4)”表示該節點依賴的鏡像名稱為服務A,最小實例數為2,最大實例數為4。應用集群拓撲模型由TOSCA容器加載,當拓撲模型加載到內存之后,模型節點的屬性和節點的操作就可以通過REST API進行訪問。應用集群的部署流程由基于BPEL(business process execution language)的流程模型描述,流程模型由任務節點、控制節點和有向連接構成,任務節點通過部署模型的API、其他任務節點或者子流程完成若干部署步驟,控制節點實現部署過程的分支和循環控制,有向連接定義了任務節點的執行次序。應用集群部署流程由流程引擎負責加載和執行。
流程引擎執行應用集群部署流程,開始進行應用集群部署,流程引擎順序或并行地執行部署任務節點,部署任務節點可以調用應用集群模型相應節點的部署操作API,通知模型節點執行部署操作。模型節點首先調用OpenStack的資源管理API創建虛擬機,為每個節點安裝操作系統和Docker引擎,然后調用節點上Docker引擎的API完成集群節點軟件鏡像安裝和加載。由于Docker鏡像采用分層結構組織,上層的鏡像可以共享下層的鏡像,多個容器可以共用同一個只讀的鏡像,Docker引擎能夠自動識別Docker鏡像的依賴關系,確保每個服務器都有所需的軟件鏡像,且每個軟件鏡像層只下載和安裝一次。

圖3 部署平臺核心部件協作關系
從上述分析可以看出,本部署平臺的部署過程具有如下特點。
·支持任意技術框架:Docker鏡像技術可以將任意的軟件、類庫、框架及其依賴關系打包成標準化的Docker鏡像文件,統一了各種軟件的構建、存儲、分發、安裝和運行過程。
·支持任意拓撲架構:可通過TOSCA模型靈活地編排和復用業務集群的拓撲結構。
·支持全堆棧、全流程自動部署:通過對接云資源平臺和Docker平臺,實現從硬件到軟件的全堆棧安裝配置,通過流程引擎和TOSCA容器驅動整個集群部署流程的自動化執行。
·部署速度快、效率高:輕量級的Docker鏡像和容器技術降低了軟件安裝文件的存儲和傳輸開銷,秒級的Docker容器啟動時間讓業務平臺快速就緒成為可能。
利用互聯網應用部署平臺進行集群部署可分為3個階段:集群模板設計階段,由有經驗的架構師完成集群模板的設計;集群模板實例化階段,由團隊的部署工程師將集群模板實例化為實際部署的模型;集群模板部署執行階段,由部署平臺基于部署模型自動完成集群部署。各階段的流程介紹如下。
有經驗的架構師、系統工程師或管理員通過TOSCA模型設計器設計可復用的TOSCA應用集群模板,并將集群模板發布在自服務門戶上。
(1)應用集群部署模型配置
開發者通過自服務門戶選擇一個合適的TOSCA應用集群模板,調整模板中的節點和關系,使之與要部署的應用集群架構一致,調整節點綁定的系統鏡像和頂層Docker鏡像,使之與要部署的集群節點一致。
(2)集群部署包打包上傳
通過自服務門戶的集群打包功能將TOSCA模板文件和新增的本地鏡像文件打包成CSAR(cloud service archive)部署包,通過管理門戶上傳CSAR部署包。
(3)新增鏡像保存與部署服務調用
門戶解析CSAR部署包,將新增鏡像保存在Docker鏡像倉庫中,并將TOSCA模型文件發送給PaaS管理器,調用PaaS管理器的集群部署服務。
(4)TOSCA部署模型解釋
將TOSCA的集群拓撲模型解釋成拓撲對象模型,保存在TOSCA容器中,將部署管理流程定義加載到工作流引擎中。
PaaS平臺工作流引擎執行集群部署流程,調用管理代理的接口依次執行虛擬機創建、網絡配置、節點鏡像安裝、容器運行、容器配置等任務,自動完成整個應用集群的部署。
部署工程師可通過自服務門戶手工執行完整的集群部署流程、子集群部署流程或者單個節點的部署操作。
基于Docker、Cloudify等開源PaaS技術構建的互聯網業務自動部署平臺,較好地平衡了部署效率與部署靈活性的問題,通過Docker節點支持任意的軟件堆棧,通過TOSCA/Cloudify部署模型支持復雜的集群架構,實現了復雜互聯網集群全堆棧、全流程的自動化部署,支撐互聯網業務平臺更好地應對用戶需求的快速變化和用戶規模的快速增長。
1 Miglierina M.Application deployment and management in the cloud.Proceedings of the 16th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing,Timisoara,Romania,2014
2 孫宏亮.Docker源碼分析(一):Docker架構.http://www.infoq.com/cn/articles/docker-source-code-analysis-part1,2014 Sun H L.Docker source code analysis(I):Docker architecture.http://www.infoq.com/cn/articles/docker-source-code-analysispart1,2014
3 Cloudify 3.2 architecture overview.http://getcloudify.org/guide/3.2/overview-architecture.html,2014
4 徐鵬,陳思,蘇森.互聯網應用PaaS平臺體系結構.北京郵電大學學報,2012,35(1):120~124 Xu P,Chen S,Su S.PaaS platform architecture for internet application.Journal of Beijing University of Posts and Telecommunications,2012,35(1):120~124
5 張海瑞.云平臺自動化部署模塊的設計與實現(碩士學位論文).哈爾濱:哈爾濱工業大學,2013 Zhang H R.Design and implementation of the automatic deployment module for cloud platform(master dissertation).Harbin:Harbin Institute of Technology,2013