李 超 花 磊 宋云奎

（1.新華通訊社中國(guó)經(jīng)濟(jì)信息社有限公司 北京 100803）（2.中國(guó)科學(xué)院軟件研究所 北京 100190）

1 引言

近年來(lái)，互聯(lián)網(wǎng)公司業(yè)務(wù)迅速擴(kuò)展，用戶(hù)需求頻繁變化，傳統(tǒng)基于單體架構(gòu)的軟件系統(tǒng)難以適應(yīng)互聯(lián)網(wǎng)技術(shù)的快速發(fā)展。因此，微服務(wù)架構(gòu)應(yīng)運(yùn)而生，將單一應(yīng)用劃分成眾多規(guī)模較小、功能專(zhuān)一的服務(wù)。其中，每個(gè)服務(wù)對(duì)具體業(yè)務(wù)邏輯進(jìn)行封裝構(gòu)建，獨(dú)立運(yùn)行于生產(chǎn)環(huán)境中，通過(guò)服務(wù)模塊之間的相互配合以對(duì)外提供服務(wù)［1］。微服務(wù)架構(gòu)由于模塊自治性強(qiáng)，可以滿(mǎn)足互聯(lián)網(wǎng)應(yīng)用變化快、模塊獨(dú)立更新的需求。但是微服務(wù)模塊數(shù)量眾多、交互復(fù)雜，增加了運(yùn)維的難度與成本，如何應(yīng)對(duì)微服務(wù)快速頻繁的更新與部署已成為微服務(wù)架構(gòu)應(yīng)用亟需解決的主要問(wèn)題之一。

為了實(shí)現(xiàn)關(guān)注點(diǎn)或任務(wù)的分離，將微服務(wù)的開(kāi)發(fā)測(cè)試和運(yùn)行維護(hù)過(guò)程進(jìn)行嚴(yán)格區(qū)分，使得不同項(xiàng)目組具有不同的目標(biāo)與流程。開(kāi)發(fā)人員的目標(biāo)是快速將變更實(shí)現(xiàn)到生產(chǎn)環(huán)境，而運(yùn)維人員的目標(biāo)是保持生產(chǎn)環(huán)境的穩(wěn)定，這成為快速頻繁發(fā)布軟件的障礙。開(kāi)發(fā)和運(yùn)維人員之間的協(xié)作通常通過(guò)手工進(jìn)行，該過(guò)程低效且易錯(cuò)，因此將更改應(yīng)用、增加特性和修復(fù)錯(cuò)誤實(shí)現(xiàn)到生產(chǎn)環(huán)境中需要投入大量的人力和時(shí)間。為了快速響應(yīng)用戶(hù)需求以及微服務(wù)應(yīng)用的不斷變化，軟件企業(yè)需要應(yīng)對(duì)快速頻繁的微服務(wù)應(yīng)用發(fā)布，填補(bǔ)開(kāi)發(fā)和運(yùn)營(yíng)之間的鴻溝。DevOps是應(yīng)對(duì)微服務(wù)應(yīng)用開(kāi)發(fā)與運(yùn)維的新興技術(shù)，可以實(shí)現(xiàn)開(kāi)發(fā)和運(yùn)維兩個(gè)部門(mén)間的有效協(xié)作［2］。微服務(wù)應(yīng)用實(shí)例不僅需要部署到開(kāi)發(fā)環(huán)境以運(yùn)行測(cè)試用例或者檢查更新代碼，也需要不斷部署和重新部署到生產(chǎn)環(huán)境以提供服務(wù)。由于應(yīng)用會(huì)頻繁部署到不同環(huán)境，實(shí)現(xiàn)高效自動(dòng)化的應(yīng)用部署至關(guān)重要。同時(shí)，應(yīng)用需要從簡(jiǎn)單的開(kāi)發(fā)環(huán)境到復(fù)雜的分布式生產(chǎn)環(huán)境無(wú)縫對(duì)接，部署邏輯需要具有可移植性。

DevOps社區(qū)提供開(kāi)源工具（如Chef［3］，Puppet［4］，Ansible［5］）來(lái)支持部署過(guò)程自動(dòng)化以實(shí)現(xiàn)軟件的持續(xù)交付；在中間件與應(yīng)用層，可以獲取可重用的構(gòu)件（如腳本、模板）以實(shí)現(xiàn)部署自動(dòng)化；在基礎(chǔ)設(shè)施層，云計(jì)算平臺(tái)為應(yīng)用按需提供底層物理資源自動(dòng)化部署API。因此，本文結(jié)合各層次多種技術(shù)、服務(wù)和構(gòu)件以應(yīng)對(duì)各類(lèi)微服務(wù)應(yīng)用的部署問(wèn)題，從而實(shí)現(xiàn)高效的微服務(wù)組件組合和自動(dòng)化的微服務(wù)應(yīng)用組件部署。本文面向DevOps，提出了一種高效動(dòng)態(tài)的應(yīng)用部署引擎OpsFlow，設(shè)計(jì)與實(shí)現(xiàn)了技術(shù)框架以自動(dòng)生成OpsFlow，最后，通過(guò)實(shí)驗(yàn)評(píng)價(jià)了生成OpsFlow的開(kāi)銷(xiāo)，并且使用微服務(wù)應(yīng)用的實(shí)例研究驗(yàn)證了方法的有效性。

2 微服務(wù)應(yīng)用自動(dòng)化部署

2.1 應(yīng)用自動(dòng)化部署引擎OpsFlow

應(yīng)用部署引擎OpsFlow目標(biāo)是組合多種自動(dòng)化部署技術(shù)以應(yīng)對(duì)異構(gòu)應(yīng)用與部署環(huán)境，從而實(shí)現(xiàn)高效自動(dòng)化的微服務(wù)應(yīng)用部署。OpsFlow作為可移植可定制的部署邏輯包，為用戶(hù)或外部系統(tǒng)提供API以便于部署應(yīng)用實(shí)例，同時(shí)也提供管理邏輯對(duì)已部署的某些應(yīng)用組件進(jìn)行擴(kuò)展，具有以下功能：

1）為特定應(yīng)用實(shí)例指定編程語(yǔ)言以生成可移植包，使得應(yīng)用實(shí)例在本地主機(jī)開(kāi)發(fā)環(huán)境、本地服務(wù)器測(cè)試環(huán)境、遠(yuǎn)程云計(jì)算生產(chǎn)環(huán)境等不同的環(huán)境中運(yùn)行；

2）生成可執(zhí)行構(gòu)件（如腳本、編譯程序）以實(shí)現(xiàn)“原子”部署操作，其實(shí)現(xiàn)形態(tài)是安裝和配置軟件包的部署腳本，或是通過(guò)調(diào)用云服務(wù)接口來(lái)使用虛擬資源的代碼；

3）編排多個(gè)部署可執(zhí)行程序以形成云應(yīng)用部署模板。部署可執(zhí)行程序負(fù)責(zé)執(zhí)行部署計(jì)劃，協(xié)調(diào)部署操作，并創(chuàng)建特定應(yīng)用拓?fù)洌?/p>

4）提供公開(kāi)API以觸發(fā)部署計(jì)劃的執(zhí)行或創(chuàng)建應(yīng)用拓?fù)?，如圖1所示API可以被用戶(hù)或外部系統(tǒng)調(diào)用，例如，高層調(diào)度器可以根據(jù)當(dāng)前負(fù)載調(diào)用OpsFlow接口以創(chuàng)建更多應(yīng)用實(shí)例。

圖1 OpsFlow系統(tǒng)架構(gòu)

根據(jù)應(yīng)用拓?fù)鋭?dòng)態(tài)生成定制的OpsFlow引擎具有以下優(yōu)點(diǎn)：

1）只包含實(shí)現(xiàn)部署操作所必需的部署可執(zhí)行程序，具有較少的軟件規(guī)模、資源消耗和配置操作，以及較高的性能。

2）打包所需要的部署可執(zhí)行程序，以自包含方式部署特定應(yīng)用，彼此間相互獨(dú)立。由于不依賴(lài)于集中的中間件，避免了單一故障點(diǎn)，從而具有更高的可靠性。

3）使用開(kāi)源生態(tài)系統(tǒng)提供的可重用構(gòu)件（如Chef、Juju）自動(dòng)生成部署計(jì)劃，實(shí)現(xiàn)部署可執(zhí)行計(jì)劃的編排和執(zhí)行，開(kāi)發(fā)人員只需調(diào)用所需的API而無(wú)需手動(dòng)開(kāi)發(fā)粘連代碼。

2.2 OpsFlow部署引擎生成方法

OpsFlow的動(dòng)態(tài)生成方法如圖2所示，分為設(shè)計(jì)、構(gòu)建和運(yùn)行等三個(gè)階段，遵循通用規(guī)范使用不同技術(shù)實(shí)現(xiàn)。

圖2 OpsFlow部署引擎生成方法

1）設(shè)計(jì)階段：創(chuàng)建和維護(hù)應(yīng)用拓?fù)淠Ｐ?；根?jù)基礎(chǔ)設(shè)施、中間件和應(yīng)用組件選擇部署可執(zhí)行程序，這些可執(zhí)行程序可以定制開(kāi)發(fā)，也可以使用現(xiàn)有構(gòu)件（如Chef，Juju，fog，Jclouds）；將所需的部署可執(zhí)行程序關(guān)聯(lián)到應(yīng)用拓?fù)?。其中，部署可?zhí)行程序，既可以獨(dú)立開(kāi)發(fā)，也可以重用現(xiàn)有開(kāi)源社區(qū)提供的構(gòu)件。對(duì)于現(xiàn)有開(kāi)源部署構(gòu)件（如Chef Supermarket，Docker Hub），由于每個(gè)開(kāi)源社區(qū)獨(dú)立維護(hù)存儲(chǔ)庫(kù)，并且提供有限的搜索能力，因此缺乏全面的知識(shí)，難以選擇合適的構(gòu)件，本文通過(guò)整合知識(shí)庫(kù)的元模型來(lái)解決該問(wèn)題。部署需求來(lái)自于應(yīng)用拓?fù)?，可以通過(guò)需求參考文件來(lái)表達(dá)部署可執(zhí)行程序的需求以及與其他部署可執(zhí)行程序的關(guān)聯(lián)。

2）構(gòu)建階段：創(chuàng)建部署計(jì)劃，即部署可執(zhí)行程序，編排所有必需的部署可執(zhí)行程序，以創(chuàng)建特定應(yīng)用拓?fù)淠Ｐ偷膶?shí)例。部署計(jì)劃可以手工完成，也可以使用計(jì)劃自動(dòng)生成技術(shù)，如使用BPEL引擎自動(dòng)生成應(yīng)用部署的工作流程；在創(chuàng)建部署計(jì)劃時(shí)，所有必需的部署可執(zhí)行程序都已就緒，生成Ops-Flow部署引擎。

3）運(yùn)行階段：生成可定制的OpsFlow引擎；根據(jù)建模的應(yīng)用拓?fù)?，提供API以創(chuàng)建部署計(jì)劃，并部署與管理應(yīng)用實(shí)例；如果不需要部署和管理更多的應(yīng)用實(shí)例，則終止OpsFlow引擎。

2.3 OpsFlow部署引擎生成框架

OpsFlow部署引擎生成框架如圖3所示，包括設(shè)計(jì)、構(gòu)建和運(yùn)行等三個(gè)階段，具體包括以下幾個(gè)組件。

應(yīng)用拓?fù)淠Ｐ偷慕－h(huán)境：建立和維護(hù)應(yīng)用拓?fù)淠Ｐ?，并將所需的部署可?zhí)行程序關(guān)聯(lián)到這些拓?fù)淠Ｐ椭械慕M件和依賴(lài)項(xiàng)。

部署計(jì)劃產(chǎn)生器：動(dòng)態(tài)自動(dòng)生成部署計(jì)劃，能夠處理創(chuàng)建的應(yīng)用拓?fù)淠Ｐ?。為了將建模環(huán)境與計(jì)劃生成器分離，本文使用基于標(biāo)準(zhǔn)的建模方法（如TOSCA［10］）。為了達(dá)到自定義目標(biāo)而改進(jìn)部署計(jì)劃，則需要提供相應(yīng)的部署計(jì)劃開(kāi)發(fā)環(huán)境，本文將Eclipse BPEL Designer作為BPEL工作流環(huán)境。

API生成器：生成部署可執(zhí)行程序，隱藏和抽象實(shí)現(xiàn)的技術(shù)細(xì)節(jié)，創(chuàng)建通過(guò)API訪(fǎng)問(wèn)的部署計(jì)劃，實(shí)現(xiàn)在不修改源碼的情況下包裝部署可執(zhí)行程序。例如，如何調(diào)用可執(zhí)行文件，如何傳遞輸入?yún)?shù)，以及如何收集輸出數(shù)據(jù)。如果涉及多個(gè)特定應(yīng)用的部署可執(zhí)行程序，手工為單個(gè)應(yīng)用包裝可執(zhí)行文件以實(shí)現(xiàn)API耗時(shí)費(fèi)力，那么就需要自動(dòng)化創(chuàng)建API。由于使用多種自動(dòng)化技術(shù)來(lái)部署異構(gòu)應(yīng)用，需要手工修改與細(xì)化部署計(jì)劃。特別是，當(dāng)使用工作流建模語(yǔ)言（如BPEL），集成各種技術(shù)非常復(fù)雜且容易出錯(cuò)，因此，將這些技術(shù)特點(diǎn)及其調(diào)用機(jī)制封裝在A(yíng)PI中，就可以使用HTTP等標(biāo)準(zhǔn)化通信協(xié)議來(lái)調(diào)用。部署計(jì)劃生成器不需要了解各種技術(shù)的調(diào)用機(jī)制細(xì)節(jié)，而只需了解如何調(diào)用API以支持自動(dòng)生成部署計(jì)劃。

部署引擎包裝器：生成自包含的OpsFlow引擎，作為可移植可執(zhí)行包，在運(yùn)行時(shí)部署應(yīng)用實(shí)例。API生成器和OpsFlow引擎包裝器都可以基于A(yíng)PI化框架實(shí)現(xiàn)，比如 Any2API［11］。

OpsFlow引擎運(yùn)行時(shí)環(huán)境：根據(jù)OpsFlow引擎的打包格式，使用API來(lái)部署和管理應(yīng)用實(shí)例。同時(shí)，通過(guò)使用可移植的虛擬化方法，可用于在不同的環(huán)境中打包和執(zhí)行OpsFlow引擎。

圖3 OpsFlow部署引擎生成框架

2.4 OpsFlow部署引擎生成框架實(shí)現(xiàn)

本文基于TOSCA實(shí)現(xiàn)了原型系統(tǒng)，其中的工具鏈用以應(yīng)對(duì)可移植性和可擴(kuò)展性，涵蓋了設(shè)計(jì)、構(gòu)建和運(yùn)行等三個(gè)階段。在設(shè)計(jì)階段，建模工具提供了可擴(kuò)展的基于TOSCA標(biāo)準(zhǔn)的建模環(huán)境以改善可移植性。并且，使用Winery［12］實(shí)現(xiàn)應(yīng)用拓?fù)浣?，以管理不同?lèi)型的組件和依賴(lài)關(guān)系。

在構(gòu)建階段，本文使用OpenTOSCA作為部署計(jì)劃生成器以動(dòng)態(tài)為特定應(yīng)用拓?fù)淠Ｐ蜕刹渴鹩?jì)劃，從而滿(mǎn)足應(yīng)用拓?fù)涞奶囟ú渴鹦枨?。?duì)于常見(jiàn)的通用組件類(lèi)型（如MySQL數(shù)據(jù)庫(kù)和Apache服務(wù)器），部署計(jì)劃生成器能夠自動(dòng)生成部署計(jì)劃，而無(wú)需手工進(jìn)行細(xì)化。

在運(yùn)行階段，基于工作流建模語(yǔ)言（如BPMN或BPEL）生成的部署計(jì)劃，需要在構(gòu)建時(shí)生成相應(yīng)的API以暴露部署可執(zhí)行程序所需功能，這些功能關(guān)聯(lián)到應(yīng)用拓?fù)淠Ｐ偷慕M件和依賴(lài)項(xiàng)。本文使用Any2API框架生成這些API，例如，為部署可執(zhí)行程序生成基于SOAP/WSDL的Web服務(wù)API，以支持在BPEL中實(shí)現(xiàn)的部署計(jì)劃，從而調(diào)用和處理底層的可執(zhí)行程序。另外，當(dāng)使用腳本語(yǔ)言（如Python或Ruby）與相關(guān)庫(kù)（rest-client）連接一起實(shí)現(xiàn)部署計(jì)劃時(shí)，生成基于RESTFul的Web API。由于生成的部署計(jì)劃也是通過(guò)調(diào)用API執(zhí)行的，基于A(yíng)PI的遞歸聚合可以支持眾多不同的拓?fù)淠Ｐ?。最后，Docker容器作為可移植的虛擬化技術(shù)在構(gòu)建時(shí)使用Dockerfile包裝OpsFlow引擎，同時(shí)使用Any2API執(zhí)行包裝操作。

3 實(shí)例研究

3.1 實(shí)驗(yàn)環(huán)境

本文以典型的網(wǎng)上商店應(yīng)用作為實(shí)例來(lái)分析應(yīng)用部署所面臨的問(wèn)題。圖4描述了網(wǎng)上商店應(yīng)用架構(gòu)，采用混合云部署方式，由左邊部署在A(yíng)mazon EC2的應(yīng)用和右邊部署在OpenStack的數(shù)據(jù)庫(kù)構(gòu)成，以避免將敏感數(shù)據(jù)暴露給公有云服務(wù)提供商。PHP應(yīng)用部署在A(yíng)pache服務(wù)器以展示用戶(hù)界面并執(zhí)行業(yè)務(wù)邏輯，數(shù)據(jù)庫(kù)采用MySQL主/從模式以提高應(yīng)用的可伸縮性與高可用性。應(yīng)用由不同組件構(gòu)成，采用不同部署技術(shù)。其中，Web應(yīng)用使用Unix Shell腳本部署，PHP模塊和Apache服務(wù)器使用Chef部署，Mysql數(shù)據(jù)庫(kù)使用Juju部署。同時(shí)，在基礎(chǔ)設(shè)施層（包括虛擬機(jī)和網(wǎng)絡(luò)配置）使用Fog部署，與云計(jì)算平臺(tái)（Amazon、OpenStack）通過(guò)API進(jìn)行交互。

實(shí)現(xiàn)該應(yīng)用部署涉及到多種類(lèi)型的部署腳本和構(gòu)件，需要考慮眾多技術(shù)細(xì)節(jié)和差異，除了特定應(yīng)用的Shell腳本外，Chef和Juju都需要特定部署引擎支持。此外，應(yīng)用拓?fù)湟远嘣品绞讲渴?，即Amazon作為公有云服務(wù)提供者，而OpenStack作為私有云管理平臺(tái)。

通用的自動(dòng)化部署框架（如 OpenTOSCA［6］，Terraform［7］，Brooklyn［8］）通過(guò)引入統(tǒng)一的元模型進(jìn)行抽象以實(shí)現(xiàn)不同部署可執(zhí)行程序的編排，使得不同方法使用相應(yīng)的元模型，但需要手工對(duì)特定部署模塊進(jìn)行適配開(kāi)發(fā)而不能自動(dòng)實(shí)現(xiàn)。同時(shí)，由于通用的部署引擎需要支持多種部署方法，通常是重量級(jí)模塊，維護(hù)復(fù)雜度高。

3.2 開(kāi)銷(xiāo)分析

實(shí)驗(yàn)使用三種公開(kāi)的Chef cookbooks來(lái)部署Apache服務(wù)器、PHP運(yùn)行時(shí)環(huán)境和MySQL數(shù)據(jù)庫(kù)，實(shí)現(xiàn)兩個(gè)Ruby腳本在A(yíng)mazon EC2云基礎(chǔ)設(shè)施上部署虛擬服務(wù)器，使用Amazon關(guān)系數(shù)據(jù)庫(kù)服務(wù)（RDS）部署MySQL數(shù)據(jù)庫(kù)實(shí)例。

圖4 部署結(jié)構(gòu)圖

該實(shí)驗(yàn)系統(tǒng)部署在一臺(tái)虛擬機(jī)（4個(gè)2.8 GHz主頻64位的虛擬CPU，4 GB內(nèi)存），使用Virtual Box Hyperviso，在Debian Linux容器中完成部署可執(zhí)行程序的處理和調(diào)用。本文監(jiān)測(cè)容器層的所有度量，關(guān)注部署可執(zhí)行程序和API實(shí)現(xiàn)相關(guān)的度量，執(zhí)行每個(gè)部署可執(zhí)行程序20次（其中，10次有API實(shí)現(xiàn)，10次沒(méi)有API實(shí)現(xiàn)）。每組10次執(zhí)行中的5次是初始執(zhí)行（在干凈的部署環(huán)境中運(yùn)行，而沒(méi)有執(zhí)行任何操作），另外5次是后續(xù)執(zhí)行。生成API實(shí)現(xiàn)的平均時(shí)間是構(gòu)建階段的開(kāi)銷(xiāo)，為8s～33s，其中包括檢索特定部署可執(zhí)行程序的依賴(lài)項(xiàng)。由于對(duì)生成的API進(jìn)行了簡(jiǎn)化，運(yùn)行時(shí)具有較少的執(zhí)行時(shí)間和較小的內(nèi)存開(kāi)銷(xiāo)。此外，當(dāng)直接使用簡(jiǎn)單的部署可執(zhí)行程序，編排組件會(huì)減少生成API實(shí)現(xiàn)的復(fù)雜性。因此，資源的總體消耗取決于所選的編配方式，同時(shí)可以復(fù)用API實(shí)現(xiàn)在不同的遠(yuǎn)程環(huán)境中運(yùn)行可執(zhí)行程序，以減少大型運(yùn)行環(huán)境的開(kāi)銷(xiāo)。本文從設(shè)計(jì)、構(gòu)建和運(yùn)行等三個(gè)階段對(duì)應(yīng)用部署開(kāi)銷(xiāo)進(jìn)行評(píng)估，實(shí)驗(yàn)結(jié)果如下：

1）設(shè)計(jì)階段：生成API所需的時(shí)間，實(shí)驗(yàn)結(jié)果如圖5所示；

2）構(gòu)建階段：部署可執(zhí)行程序所需時(shí)間，實(shí)驗(yàn)結(jié)果如圖6所示；

3）運(yùn)行階段：可執(zhí)行程序運(yùn)行所需內(nèi)存，實(shí)驗(yàn)結(jié)果如圖7所示。

圖5 生成API實(shí)現(xiàn)時(shí)間

圖6 部署執(zhí)行時(shí)間

圖7 運(yùn)行內(nèi)存使用

4 相關(guān)工作

與傳統(tǒng)的通用部署引擎不同，OpsFlow在運(yùn)行時(shí)不依賴(lài)于集中的中間件。論文［13］利用可擴(kuò)展的通用部署引擎來(lái)部署和管理各種應(yīng)用，通過(guò)減少生成定制引擎的步驟來(lái)減少構(gòu)建時(shí)的開(kāi)銷(xiāo)。與Ops-Flow相比有以下幾個(gè)缺點(diǎn)：1）通用部署引擎提供的API并不適合所有的部署場(chǎng)景，需要實(shí)現(xiàn)多種部署技術(shù)，具有較高的復(fù)雜性，因而難以維護(hù)和擴(kuò)展；2）通用部署引擎通常采用集中式中間件，存在單點(diǎn)失效的問(wèn)題，因此需要維護(hù)其可靠性。3）使用通用部署引擎通常需要領(lǐng)域知識(shí)，通過(guò)二次開(kāi)發(fā)來(lái)包裝現(xiàn)有的API，從而實(shí)現(xiàn)多應(yīng)用組件部署的編排。4）通用部署引擎不是專(zhuān)門(mén)針對(duì)給定的應(yīng)用拓?fù)洌虼诉\(yùn)行開(kāi)銷(xiāo)較高。Bootware［14］首先創(chuàng)建部署引擎，然后用其部署應(yīng)用實(shí)例，該方法使用通用部署引擎，而OpsFlow是面向特定應(yīng)用動(dòng)態(tài)生成的部署引擎。論文［15］將不同類(lèi)型的部署可執(zhí)行程序轉(zhuǎn)換為基于TOSCA標(biāo)準(zhǔn)的構(gòu)件，便于現(xiàn)有多樣化開(kāi)源生態(tài)系統(tǒng)所提供內(nèi)容的復(fù)用。該方法雖然能夠有效實(shí)現(xiàn)設(shè)計(jì)階段和構(gòu)建階段的部署自動(dòng)化，但是在運(yùn)行階段需要通用部署引擎來(lái)部署和管理應(yīng)用拓?fù)?。云提供商提供了建模和編排工具?6］，同時(shí)提供了PaaS（Platform-as-a-Service）服務(wù)［17］，調(diào)用該服務(wù)可以部署和管理應(yīng)用實(shí)例，而不需要顯式建模應(yīng)用拓?fù)?。文獻(xiàn)［18］提出了基于Xen的云平臺(tái)自動(dòng)部署框架。文獻(xiàn)［19～20］提出了PM、VM和應(yīng)用等三個(gè)層次的云應(yīng)用部署的描述語(yǔ)言。但以上方法難以實(shí)現(xiàn)多云或混合云部署，將應(yīng)用或部分應(yīng)用自動(dòng)化遷移到不同的提供者非常困難。同時(shí)，API是由提供者預(yù)先定義的，并且必須通過(guò)開(kāi)發(fā)自定義的粘合代碼來(lái)手動(dòng)包裝，因此不適用于特定部署場(chǎng)景。

5 結(jié)語(yǔ)

當(dāng)前互聯(lián)網(wǎng)應(yīng)用的用戶(hù)需求快速變化，高效自動(dòng)部署技術(shù)是縮短軟件發(fā)布周期的關(guān)鍵。DevOps技術(shù)有助于實(shí)現(xiàn)快速自動(dòng)化部署過(guò)程，通過(guò)不斷迭代交付微服務(wù)來(lái)縮短發(fā)布周期。本文面向DevO-ps，提出了一種高效動(dòng)態(tài)的應(yīng)用部署引擎OpsFlow及其生成方法，設(shè)計(jì)并實(shí)現(xiàn)了技術(shù)框架以支持所提出方法，最后，實(shí)驗(yàn)結(jié)果表明，生成部署引擎具有較小的開(kāi)銷(xiāo)。