，

(上海大學(xué) 通信與信息工程學(xué)院，上海 201210 )

0 引言

目前，各科研院所、企業(yè)、高校等機(jī)構(gòu)掌握著大量的科研成果，其中部分成果以專利、論文的形式予以公開，但仍有較大部分的科研、產(chǎn)業(yè)成果存在于研發(fā)團(tuán)隊(duì)中。出于版權(quán)保護(hù)、利益等相關(guān)考慮，科研成果間的協(xié)同創(chuàng)新目前主要基于雙方互相信任的基礎(chǔ)上，協(xié)同門檻高，利益分配模糊。究其原因，不僅有政策、技術(shù)問題，也有體制問題。如何通過技術(shù)手段，降低協(xié)同創(chuàng)新門檻，讓各方能夠放心的提供己方成果，不受版權(quán)侵犯的困擾；在共享協(xié)同成果的同時(shí)，合理分配各自知識產(chǎn)權(quán)所創(chuàng)造的利益，使其版權(quán)、利益都能得到保護(hù)是解決問題的關(guān)鍵。隨著容器技術(shù)的蓬勃發(fā)展，集裝箱式的部署方式為軟件應(yīng)用的協(xié)同開發(fā)創(chuàng)新實(shí)踐提供了新的思路。

隨著云計(jì)算、移動(dòng)計(jì)算、物聯(lián)網(wǎng)、大數(shù)據(jù)和社交網(wǎng)絡(luò)的發(fā)展，面向智能應(yīng)用的生態(tài)環(huán)境有利于創(chuàng)新涌現(xiàn)，有利于實(shí)現(xiàn)全面透徹的感知、寬帶泛在的互聯(lián)和智能分析，但也對智能應(yīng)用的開發(fā)和創(chuàng)新模式帶來了新的挑戰(zhàn)[1]。而端云間協(xié)同的網(wǎng)絡(luò)架構(gòu)能夠集成海端數(shù)據(jù)和云端計(jì)算的優(yōu)勢，逐漸成為創(chuàng)新的技術(shù)驅(qū)動(dòng)力。

云計(jì)算是隨著網(wǎng)絡(luò)傳輸帶寬不斷提高而發(fā)展出的一種新的計(jì)算形式，區(qū)別于現(xiàn)有的在終端計(jì)算的方式，云計(jì)算將計(jì)算壓力承載在網(wǎng)絡(luò)的另一端，即云端，完成計(jì)算任務(wù)后再將結(jié)果返回給終端。云計(jì)算模式具有大規(guī)模、虛擬化、高可用性、高可擴(kuò)展性、按需服務(wù)，成本低廉等特點(diǎn)。目前各大企業(yè)和科研機(jī)構(gòu)正不斷推進(jìn)著云模式與現(xiàn)有技術(shù)的結(jié)合，云計(jì)算技術(shù)也成為業(yè)界技術(shù)創(chuàng)新實(shí)踐的活躍試驗(yàn)場。

容器是通過一種虛擬化技術(shù)來隔離運(yùn)行在主機(jī)上不同進(jìn)程，從而達(dá)到進(jìn)程之間、進(jìn)程和宿主操作系統(tǒng)相互隔離、互不影響的技術(shù)，可以提供輕量級的虛擬化,以便隔離進(jìn)程和資源[2]。容器能夠用來實(shí)現(xiàn)資源隔離，提高資源利用率。其輕量化的特性，使其能夠?qū)崿F(xiàn)虛擬機(jī)的功能下，各項(xiàng)開銷都遠(yuǎn)低于虛擬機(jī)的資源利用。容器的運(yùn)行效率基本接近于物理機(jī)，容器的操作可達(dá)到秒級甚至毫秒級，容器的一次構(gòu)建，多次復(fù)用的靈活性極大滿足了傳統(tǒng)應(yīng)用快速移云的需求。容器虛擬化技術(shù)的日益流行以及其諸多特性，逐漸成為業(yè)界和學(xué)術(shù)界研究和實(shí)踐的熱點(diǎn)。在實(shí)踐方面，容器促進(jìn)了微服務(wù)架構(gòu)的發(fā)展，使得傳統(tǒng)的大型軟件更易于平緩的轉(zhuǎn)換為高內(nèi)聚、低耦合的微服務(wù)架構(gòu)。同時(shí)，容器以及相關(guān)技術(shù)的日益成熟，促使了容器云平臺的誕生，為PaaS層(platform as Service)的實(shí)踐提供了一條新的技術(shù)途徑。在科研方面，根據(jù)文獻(xiàn)檢索引擎Web of Science上的統(tǒng)計(jì)結(jié)果顯示，圖1，容器以及虛擬化相關(guān)研究在近幾年愈加活躍，以論文為代表的科研成果數(shù)量從2014年開始顯著提升，是當(dāng)前學(xué)術(shù)界日益關(guān)注的研究熱點(diǎn)。容器與其他技術(shù)相比具有諸多優(yōu)勢，除了輕量化、彈性可伸縮的特性外，其鏡像分層機(jī)制和自動(dòng)化構(gòu)建的特性為本文提出基于容器的具有版權(quán)保護(hù)特性的協(xié)同開發(fā)架構(gòu)提供了技術(shù)基礎(chǔ)。

圖1 Web of science中容器與虛擬化文獻(xiàn)統(tǒng)計(jì)

1 國內(nèi)外相關(guān)研究進(jìn)展

容器本質(zhì)上是通過虛擬化操作系統(tǒng)的方式來管理代碼以及應(yīng)用程序，容器技術(shù)的發(fā)展從分配存儲到協(xié)調(diào)網(wǎng)絡(luò)都對現(xiàn)有架構(gòu)提供了新的思路，眾多研究者都在試圖用這樣一種輕量化、一次構(gòu)建多次復(fù)用的容器技術(shù)對現(xiàn)有框架進(jìn)行創(chuàng)新研究。眾多研究者關(guān)于容器架構(gòu)的研究，對我們提出具有版權(quán)保護(hù)功能的增量式開發(fā)架構(gòu)具有重要的借鑒意義。

Xinjie Guan設(shè)計(jì)了一種面向應(yīng)用程序的docker容器，基于AODC資源分配框架，最小化數(shù)據(jù)中心的應(yīng)用部署成本，并能夠根據(jù)云端應(yīng)用的工作負(fù)載自動(dòng)伸縮[3]。Xxx綜合考慮docker各種應(yīng)用的特征，云數(shù)據(jù)中心的可用性對AODC進(jìn)行建模，并提出了一種用于數(shù)據(jù)中心的可伸縮性算法。

Abdulrahman Azab提出socker概念，一種用于封裝運(yùn)行在Slurm上的docker容器的技術(shù)。不同于其他docker支持的用于HPC(High-performance computing)的容器平臺，socker使用底層的Docker引擎[4]。經(jīng)過測試，socker不僅安全，并且除了Docker引擎自身所帶來的開銷外并沒有引入更多的資源消耗。

當(dāng)本地存在docker鏡像時(shí)，此節(jié)點(diǎn)啟動(dòng)docker容器速度很快。但是如果該節(jié)點(diǎn)沒有鏡像時(shí)，從注冊中心下載鏡像會增加啟動(dòng)時(shí)間。Senthil Nathan提出了一種對容器鏡像進(jìn)行協(xié)作管理的系統(tǒng)CoMICon[5]。CoMICon的特點(diǎn)有：1、能夠在一組節(jié)點(diǎn)中啟用協(xié)作注冊中心。2、能夠存儲、刪除部分鏡像層。3、有助于注冊中心之間轉(zhuǎn)移鏡像。4、當(dāng)啟動(dòng)一個(gè)新的容器時(shí)，能夠從不同的注冊中心下載鏡像。經(jīng)過測試，CoMICon平均能夠增加可用鏡像數(shù)量3倍以上，減少應(yīng)用配置時(shí)間28%

由于容器和虛擬機(jī)不同的鏡像格式和不同的鏡像管理進(jìn)程阻礙了混合分布式云架構(gòu)的采用。German Molto提出了一種基于開源工具和標(biāo)準(zhǔn)的工作流，能夠在混合分布式基礎(chǔ)設(shè)施上引入一致的應(yīng)用程序，這些應(yīng)用需要同時(shí)部署在VM和Docker容器中。利用和擴(kuò)展TOSCA標(biāo)準(zhǔn)來描述應(yīng)用程序需求，并采用DevOps實(shí)踐，使得用于在不同平臺上執(zhí)行應(yīng)用程序所需工件的一致性創(chuàng)建[6]。

為了能夠在云端運(yùn)行應(yīng)用，我們需要確定一組能夠與容器相適應(yīng)的虛擬機(jī)，并且還要考慮到需求的多樣性。為此，在考慮到容器需求和虛擬機(jī)資源的異質(zhì)的情況下，Matteo Nardelli提出了一種用于容器部署的虛擬機(jī)彈性配置的公式(EVCD)[7]。并且以論證多個(gè)QoS度量指標(biāo)靈活性為目的評估了EVCD公式。

為了解決微服務(wù)體系結(jié)構(gòu)中服務(wù)發(fā)現(xiàn)的問題，Joe Stubbs提出了一種基于Serf 節(jié)點(diǎn)的自服務(wù)開源解決方案。Serf節(jié)點(diǎn)是由一個(gè)或多個(gè)Docker容器組成的鏡像。新鏡像部署在Serf節(jié)點(diǎn)集群內(nèi)，并在集群內(nèi)進(jìn)行自我宣傳，提供服務(wù)發(fā)現(xiàn)機(jī)制、監(jiān)視和自我修復(fù)，最終生成沒有主節(jié)點(diǎn)，同構(gòu)且完整的圖[8]。

復(fù)現(xiàn)已有科研成果的能力成為學(xué)術(shù)界日益重要的課題。在計(jì)算機(jī)科學(xué)技術(shù)中，由于公開的代碼和數(shù)據(jù)中有許多沒有正式說明的假設(shè)、依賴和配置，使得科研成果的復(fù)現(xiàn)性大大降低。 Jürgen Cito通過借助Docker容器克服了上述問題，提高了軟件及web工程中科研成果的復(fù)現(xiàn)性[9]。

與基于管理程序的虛擬化方法相比，容器的使用提供了更快的啟動(dòng)時(shí)間，減少了計(jì)算機(jī)資源的消耗。但目前缺少一種在設(shè)計(jì)階段針對容器進(jìn)行可部署性驗(yàn)證的工具。Fawaz Paraiso提出了一種對Docker容器進(jìn)行建模的方法，可以保證容器的可部署性和更好的管理[10]。

隨著越來越多的用戶希望在動(dòng)態(tài)、異構(gòu)環(huán)境中部署容器，跨越多個(gè)云和數(shù)據(jù)中心的容器部署能力和有效管理變得至關(guān)重要。Moustafa Abdelbaky提出了一個(gè)C-Ports原型框架，該框架利用約束規(guī)劃模型選擇資源，利用CometCloud分配和釋放資源。該原型已被有效地用于部署和管理由五個(gè)云和兩個(gè)集群組成的動(dòng)態(tài)環(huán)境中的容器[11]。

2 架構(gòu)研究

2.1 Docker介紹

Docker是一個(gè)開源項(xiàng)目，是目前非常流行的容器平臺，能夠使代碼在虛擬化的容器中自動(dòng)運(yùn)行。開發(fā)者使用docker技術(shù)可以避免協(xié)作開發(fā)過程中應(yīng)用只能運(yùn)行在自己機(jī)器上的困境。Docker將軟件以特定格式打包，并將其運(yùn)行在共享的操作系統(tǒng)中。容器技術(shù)不是虛擬機(jī)，Docker在打包應(yīng)用時(shí)并不打包操作系統(tǒng)，只打包所需依賴包和軟件應(yīng)用所需設(shè)置。這種機(jī)制保證了軟件運(yùn)行的高效，輕量級，自包含系統(tǒng)，不依賴底層平臺等特性。Docker能夠運(yùn)行并管理多個(gè)獨(dú)立的運(yùn)行在容器內(nèi)的應(yīng)用已獲得更好的計(jì)算密度。企業(yè)通過使用Docker建立的敏捷軟件交付生產(chǎn)線，能夠?qū)崿F(xiàn)新版本更快更安全更兼容的交付客戶。

2.2 整體架構(gòu)設(shè)計(jì)

容器鏡像分層機(jī)制能夠使容器自動(dòng)化的將一個(gè)或多個(gè)應(yīng)用打包封裝為鏡像，一個(gè)鏡像可包含一個(gè)或多個(gè)應(yīng)用。多個(gè)鏡像可以共用一個(gè)父鏡像，鏡像和父鏡像呈現(xiàn)樹狀層疊關(guān)系。每層都是鏈條層里的一個(gè)鏡像，各個(gè)層疊到一起才形成一個(gè)完整的鏡像。一個(gè)層可以看成一個(gè)目錄，包含一部分差分?jǐn)?shù)據(jù)，鏡像部署為容器時(shí)，根據(jù)層疊關(guān)系下載依賴鏡像組合成一個(gè)容器的運(yùn)行時(shí)和根文件系統(tǒng)。利用容器鏡像分層機(jī)制，我們設(shè)想?yún)⑴c協(xié)同開發(fā)的各方應(yīng)用能夠以一個(gè)或多個(gè)鏡像層的方式共同組成一個(gè)最終完整的大鏡像。協(xié)同開發(fā)的各方首先基于共同的基礎(chǔ)鏡像以構(gòu)建鏡像文件的方式將自己的應(yīng)用容器化，其次將創(chuàng)建鏡像過程中撰寫的鏡像構(gòu)建文件(本文使用的是Dockerfile)和相關(guān)配置文件都上傳至第三方的可信平臺，由于鏡像構(gòu)建文件具有嚴(yán)格的書寫規(guī)范，因此能夠?qū)⒏鞣阶詣?dòng)化合并為大鏡像的鏡像構(gòu)建文件，合并工作不需要人工參與，避免了合并過程中各方知識產(chǎn)權(quán)的泄露。需要注意的是，第三方可信平臺需要具有加密功能，只能允許用戶上傳下載自己的相關(guān)文件，不能操作其他文件，避免泄露。此第三方可信平臺具體實(shí)現(xiàn)細(xì)節(jié)不在本文中過多描述。通過容器鏡像分層機(jī)制和自動(dòng)化的構(gòu)建功能，我們最終可以得到集成了各方應(yīng)用的大鏡像，其構(gòu)建過程中，參與協(xié)同開發(fā)的各方均無機(jī)會接觸到對方的相關(guān)文件，從技術(shù)上保證了協(xié)同過程中的版權(quán)保護(hù)，并且實(shí)現(xiàn)了基于對方應(yīng)用快速增量式開發(fā)的目的。

2.2.1 Dockerfile的合并規(guī)范

用戶A、B基于同一公共基礎(chǔ)鏡像(本文使用centos7.1511版本)，用戶A按照合并格式提供A服務(wù)的Dockerfile鏡像構(gòu)建文件，用戶B按照同樣的格式提供B服務(wù)的Dockerfile鏡像構(gòu)建文件。由于A、B用戶的Dockerfile具有同樣格式的書寫規(guī)范，兩份Dockerfile可通過解析代碼的方法將其重新組合為一份Dockerfile文件。合并各式如圖2。

圖2 Dockerfile合并各式

1)基礎(chǔ)鏡像部分:

一個(gè)有效的Dockerfile必須以FROM作為第一條命令，所用公共基礎(chǔ)鏡像需是經(jīng)過驗(yàn)證的健壯鏡像，一般可以很方便的從DockerHub拉取，也可使用自定義的基礎(chǔ)鏡像。多用戶進(jìn)行協(xié)同開發(fā)時(shí)需使用同一基礎(chǔ)鏡像，多用戶之間使用共同的基礎(chǔ)鏡像是不同應(yīng)用間進(jìn)行合并集成的前提。

2)操作部分:

每個(gè)用戶將應(yīng)用編寫為Dockerfile的過程中，都要以公共基礎(chǔ)鏡像為開始進(jìn)行操作，常見的操作有：下載安裝應(yīng)用所需依賴安裝包、拷貝相關(guān)文件進(jìn)入容器、安裝過程運(yùn)行命令、設(shè)置環(huán)境變量等。每一部分的操作都要盡可能的不對其他用戶產(chǎn)生影響，例如：在設(shè)置環(huán)境變量進(jìn)行操作完成后，要將環(huán)境變量的值設(shè)置為原來的初始值，使得其他用戶在編寫Dockerfile時(shí)所獲得的環(huán)境變量即為初始值，避免混亂。操作要盡量減少該應(yīng)用部分的體積，例如：下載安裝完成相關(guān)依賴包后要立即刪除安裝包，否則合并后的鏡像構(gòu)建為容器時(shí)會使體積過于龐大，不利于容器快速重建，也會影響鏡像從鏡像庫拉取至本地的時(shí)間。

3)映射部分:

此部分主要是將各應(yīng)用的端口暴露以供外部訪問、數(shù)據(jù)卷映射至宿主機(jī)進(jìn)行存儲。需要注意的是各應(yīng)用間需要映射的端口、目錄需事先雙方商定，避免使用常用端口發(fā)生沖突的情況。容器內(nèi)的相互調(diào)用不需要將端口對外映射。

4)啟動(dòng)部分:

此部分命令不需用戶撰寫，由自動(dòng)合并程序在Dockerfile文件最后添加即可。命令相對較為固定，即容器啟動(dòng)后自動(dòng)運(yùn)行supervisor進(jìn)程控制系統(tǒng)，隨后由supervisor啟動(dòng)容器內(nèi)各應(yīng)用。

2.2.2 合并環(huán)境下的文件構(gòu)成

表1 合并環(huán)境下的文件構(gòu)成

在云端自動(dòng)化集成各方應(yīng)用的環(huán)境下存在有以下三種文件(表1)：1)用于讀取各協(xié)同方指令并自動(dòng)化構(gòu)建鏡像的Dockerfile文件。2)進(jìn)程控制程序配置文件；由于各方應(yīng)用存在著進(jìn)程啟動(dòng)上的先后順序，某些應(yīng)用依賴于其他應(yīng)用所提供的數(shù)據(jù)、運(yùn)行環(huán)境等，在此文件內(nèi)設(shè)置各應(yīng)用的啟動(dòng)、就緒、阻塞、銷毀以及相關(guān)持續(xù)時(shí)間等。3)各方應(yīng)用所需要用到的相關(guān)文件。

2.2.3 協(xié)同開發(fā)過程概述

在確定完成需求和集成的目標(biāo)后，參與協(xié)同開發(fā)的用戶互相商定各自的應(yīng)用所需要暴露的端口，以及數(shù)據(jù)卷映射在宿主機(jī)的目錄，保證后續(xù)的集成不會造成端口、目錄的沖突。隨后，按照合并規(guī)范，通過自動(dòng)化的合并程序生成集合了多應(yīng)用的鏡像構(gòu)建文件，產(chǎn)生容器鏡像。將鏡像文件運(yùn)行可得到運(yùn)行態(tài)的Docker容器，其中包括了進(jìn)程控制程序、各協(xié)作用戶應(yīng)用程序。容器在啟動(dòng)時(shí)首先啟動(dòng)進(jìn)程控制程序，隨后各應(yīng)用程序的啟動(dòng)交由進(jìn)程控制系統(tǒng)接管。這里需要注意的是，由于各應(yīng)用的啟動(dòng)具有先后性(例如：應(yīng)首先啟動(dòng)數(shù)據(jù)庫應(yīng)用，再啟動(dòng)上層應(yīng)用)，各應(yīng)用的啟動(dòng)腳本應(yīng)注意通過休眠等方式實(shí)現(xiàn)按序啟動(dòng)。當(dāng)容器啟動(dòng)后可通過Cadvisor工具監(jiān)控容器流量以及性能，實(shí)時(shí)掌握容器狀態(tài)，計(jì)算流量，合理分配容器內(nèi)各應(yīng)用收益。當(dāng)確認(rèn)合并后的容器能夠正常運(yùn)行后，可將鏡像上傳至私有鏡像庫，實(shí)現(xiàn)一次構(gòu)建，分布式多次復(fù)用。協(xié)同增量式開發(fā)流程如圖3。

圖3 協(xié)同增量式開發(fā)架構(gòu)圖

3 增量式協(xié)同開發(fā)Demo系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

3.1 系統(tǒng)組成

本Demo系統(tǒng)共有三部分構(gòu)成：1)Web應(yīng)用服務(wù)程序Tomcat，2)門戶網(wǎng)站應(yīng)用程序app.war，3)存在于mysql數(shù)據(jù)庫中的第三方數(shù)據(jù)。

3.2 協(xié)同開發(fā)場景

用戶A持有web應(yīng)用服務(wù)程序Tomcat，用戶B持有第三方數(shù)據(jù)，可以提供使用但需要客戶按使用量付費(fèi)，并且不希望客戶一次付費(fèi)之后永久獲得所有數(shù)據(jù)。用戶C持有門戶網(wǎng)站應(yīng)用程序，在有數(shù)據(jù)的情況下可直接運(yùn)行起來即可對外提供服務(wù)。用戶A、B、C各自擁有一部分功能，本實(shí)驗(yàn)設(shè)計(jì)目的是將隸屬三個(gè)不同用戶的功能型應(yīng)用快速協(xié)同開發(fā)成為一個(gè)新的應(yīng)用，并且協(xié)作過程中以容器的方法保證各方技術(shù)、數(shù)據(jù)等核心知識不會泄露，在完成增量式開發(fā)的過程中提供版權(quán)保護(hù)功能。

3.3 相關(guān)配置商定

用戶A、B、C經(jīng)過商定后可確定tomcat應(yīng)用程序所在目錄，mysql數(shù)據(jù)庫和數(shù)據(jù)存放目錄，門戶網(wǎng)站應(yīng)用程序所在目錄，tomcat映射端口，mysql數(shù)據(jù)庫映射端口。

3.4 Demo系統(tǒng)協(xié)同開發(fā)流程

用戶A、B、C將相關(guān)配置、文件、數(shù)據(jù)上傳至第三方可信平臺，分別按照圖？Dockerfile合并各式撰寫各自應(yīng)用的DockerFile，經(jīng)由自動(dòng)合并程序合并成為集成了三方應(yīng)用的Dockerfile，本次Demo系統(tǒng)應(yīng)用集成后的Dockerfile如圖4所示。

圖4 Demo系統(tǒng)Dockerfile

圖4中共有7部分組成，各部分解釋如下。

1)基礎(chǔ)鏡像部分。

centos：centos7.1.1503為此次集成三方應(yīng)用所基于的基礎(chǔ)鏡像，MAINTAINER代表此DockerFile的維護(hù)者信息。

2)用戶A持有的Mysql數(shù)據(jù)對應(yīng)Dockerfile的代碼信息。

其過程依次為設(shè)置環(huán)境變量，基于公共原始鏡像安裝mariadb數(shù)據(jù)庫，拷貝相關(guān)配置文件以及數(shù)據(jù)至鏡像內(nèi)，為相關(guān)腳本添加執(zhí)行權(quán)限。

3)用戶B持有的Tomcat應(yīng)用服務(wù)程序?qū)?yīng)的Dockerfile的代碼信息。

其過程依次為：拷貝相關(guān)應(yīng)用文件、配置文件至鏡像，賦予應(yīng)用啟動(dòng)腳本執(zhí)行權(quán)限。

4)用戶C持有的門戶網(wǎng)站應(yīng)用對應(yīng)的Dockerfile的代碼信息。

其內(nèi)容為將Java應(yīng)用的War包拷貝至鏡像中。

5)安裝supervisor進(jìn)程管理程序。

此步驟可固化在基礎(chǔ)鏡像中默認(rèn)使用supervisor作為進(jìn)程管理工具，若要選擇其他進(jìn)程管理程序控制各有應(yīng)用的啟動(dòng)，則替換此部分的代碼。

6)映射部分。

對外暴露數(shù)據(jù)庫接口(可不暴露，則只能容器內(nèi)應(yīng)用訪問數(shù)據(jù))，對外暴露映射目錄。

7)啟動(dòng)部分。

不需用戶撰寫，由自動(dòng)合并程序在Dockerfile文件最后添加。命令相對較為固定，容器啟動(dòng)后自動(dòng)運(yùn)行supervisor進(jìn)程控制系統(tǒng)，隨后由supervisor啟動(dòng)容器內(nèi)各應(yīng)用。

使用合并后的Dockerfile執(zhí)行構(gòu)建鏡像的命令，產(chǎn)生容器鏡像，容器內(nèi)由supervisor啟動(dòng)三方應(yīng)用，各應(yīng)用之間互相調(diào)用實(shí)現(xiàn)協(xié)同。同時(shí)啟動(dòng)Cadvisor容器，能夠監(jiān)視應(yīng)用的資源情況、應(yīng)用的流量情況。具體流程如圖5所示。

圖5 Demo系統(tǒng)增量式協(xié)同開發(fā)流程圖

實(shí)際構(gòu)建出來的容器啟動(dòng)后，訪問所在服務(wù)器地址：8081，即可訪問門戶網(wǎng)站。服務(wù)器性能越高，從啟動(dòng)到訪問所等待時(shí)間越短。

4 結(jié)論

本文提出一種基于海云分型架構(gòu)，并具有版權(quán)保護(hù)特性的自動(dòng)化協(xié)同開發(fā)方法。在海端開發(fā)者遵照Dockefile格式將應(yīng)用容器化，在云端，各方Dockerfile自動(dòng)化集成為同一文件并構(gòu)建成為第三方可信云平臺內(nèi)的容器。海端各應(yīng)用程序的開發(fā)者只關(guān)注于自身應(yīng)用的容器化方法，無法獲得云端其他應(yīng)用的代碼以及算法等關(guān)鍵涉密信息，從而在根本上解決了不同領(lǐng)域、不同部門的海端用戶進(jìn)行協(xié)作過程中知識產(chǎn)權(quán)成果的安全問題。而第三方可信云平臺由政府、科研機(jī)構(gòu)或第三方相關(guān)專業(yè)機(jī)構(gòu)等具有社會公信力的實(shí)體機(jī)構(gòu)進(jìn)行運(yùn)營，從而保證云端數(shù)據(jù)的安全。通過海端、云端間的協(xié)同，實(shí)現(xiàn)基于容器的具有版權(quán)保護(hù)特性的協(xié)同開發(fā)架構(gòu)。并且，通過cadvisor等流量監(jiān)控工具，可以獲得容器內(nèi)實(shí)際通過流量，調(diào)用次數(shù)，使用時(shí)間等參數(shù)，計(jì)算各應(yīng)用處理流量比例，實(shí)現(xiàn)多種計(jì)費(fèi)方式，保證各方知識成果得到合理利益分配。

未來，海云分型架構(gòu)可根據(jù)用戶需求演化為多種協(xié)同方式，如：1)云端?；旱谌娇尚旁破脚_可集成海端容器化工作場景為SaaS服務(wù)供開發(fā)者使用，使容器化本地應(yīng)用的工作在云端完成，本地不再需要容器開發(fā)環(huán)境，降低海端開發(fā)成本，同時(shí)避免了本地知識泄露以及數(shù)據(jù)丟失等不安全情況的發(fā)生。形成的知識成果可直接以資源的方式供他人調(diào)用，獲得收益。2)海端云化：針對機(jī)構(gòu)內(nèi)部協(xié)作率高，對外協(xié)作需認(rèn)可的需求場景，可部署私有可信云平臺，供內(nèi)部知識成果的交流創(chuàng)新，滿足內(nèi)部頻繁的協(xié)作開發(fā)，所有數(shù)據(jù)、流量完全在私網(wǎng)中通信，海端云化后的工作場景能夠進(jìn)一步提高協(xié)作中的速度以及安全性。在與外部單位進(jìn)行協(xié)作中，本地云平臺以海端的身份與第三方可信云平臺進(jìn)行通信，經(jīng)過本地認(rèn)證機(jī)構(gòu)為相關(guān)技術(shù)成果賦予對外訪問權(quán)限，實(shí)現(xiàn)海云協(xié)同開發(fā)。

參考文獻(xiàn)：

[1] 寧德軍, 封松林, 蕭海東,等. 下一代智能應(yīng)用開發(fā)模式研究[J]. 網(wǎng)絡(luò)新媒體技術(shù), 2016, 5(1):1-10.

[2] 汪 愷, 張功萱, 周秀敏. 基于容器虛擬化技術(shù)研究[J]. 計(jì)算機(jī)技術(shù)與發(fā)展, 2015(8):138-141.

[3] Guan X, Wan X, Choi B Y, et al. Application Oriented Dynamic Resource Allocation for Data Centers Using Docker Containers[J]. IEEE Communications Letters, 2017, 21(3):504-507.

[4] Azab A. Enabling Docker Containers for High-Performance and Many-Task Computing[A]. IEEE International Conference on Cloud Engineering[C]. IEEE, 2017:279-285.

[5] Nathan S, Ghosh R, Mukherjee T, et al. CoMICon: A Co-Operative Management System for Docker Container Images[A]. IEEE International Conference on Cloud Engineering[C]. IEEE, 2017.

[6] Moltó G, Caballer M, Pérez A, et al. Coherent Application Delivery on Hybrid Distributed Computing Infrastructures of Virtual Machines and Docker Containers[A]. Euromicro International Conference on Parallel, Distributed and Network-Based Processing[C]. IEEE, 2017:486-490.

[7] Nardelli M. Elastic Allocation of Docker Containers in Cloud Environments[C]. Zeus Workshop. 2017.

[8] Stubbs J, Moreira W, Dooley R. Distributed Systems of Microservices Using Docker and Serfnode[A]. International Workshop on Science Gateways[C]. IEEE, 2015:34-39.

[9] Cito J, Gall H C. Using docker containers to improve reproducibility in software engineering research[M]. Web Engineering. Springer International Publishing, 2016.

[10] Paraiso F, Challita S, Al-Dhuraibi Y, et al. Model-Driven Management of Docker Containers[A]. IEEE, International Conference on Cloud Computing[C]. IEEE, 2017:718-725.

[11] Abdelbaky M, Diazmontes J, Parashar M, et al. Docker Containers across Multiple Clouds and Data Centers[A]. Ieee/acm, International Conference on Utility and Cloud Computing[C]. IEEE, 2016.