謝兆賢,曹香美,王 超

(曲阜師范大學(xué) 網(wǎng)絡(luò)空間安全學(xué)院,曲阜 273100)

B/S 模式是瀏覽器/服務(wù)器模式,用戶界面完全在瀏覽器中運(yùn)行.大多數(shù)通過(guò)瀏覽器和各種網(wǎng)絡(luò)辦公系統(tǒng)訪問(wèn)的網(wǎng)站都是采用B/S 模式開(kāi)發(fā)的.B/S 模式是“瘦客戶端”,核心功能都集中處理在服務(wù)器端,所以需要較低的硬件配置.但是幾乎所有客戶端的處理邏輯都運(yùn)行在服務(wù)器端,給服務(wù)器造成很大的壓力[1].

隨著云計(jì)算的快速發(fā)展,人們開(kāi)始使用容器在云與云之間快速構(gòu)建軟件的環(huán)境.由于容器具備可移植性的特性,所以容器的使用量有逐年上升的趨勢(shì).早在2015年的時(shí)候,僅有13%的使用者,2018年增加29%的使用者.從文獻(xiàn)[2]對(duì)997 名IT 專業(yè)人士的調(diào)查,有將近49% 的受訪者反饋曾經(jīng)使用過(guò)Docker 容器.以Docker容器的市場(chǎng)價(jià)值來(lái)看,2017年的時(shí)候僅為7.6億美元[3],目前也已經(jīng)增加到27 億美元.以此顯示,容器在云計(jì)算領(lǐng)域的重要性,逐年增加當(dāng)中.

Docker 是直接建立在操作系統(tǒng)上的虛擬化技術(shù),它可以直接使用本地的操作系統(tǒng).然而,Docker 容器不只提供輕量化的虛擬環(huán)境,與其它的虛擬化工具相比更具優(yōu)越性.所以,在容器的形式打包和部署應(yīng)用程序漸漸成為新趨勢(shì)的情況下,Docker 容器已經(jīng)可以在云基礎(chǔ)架構(gòu)中得到廣泛的部署,例如:Amazon EC2 Container Service,Google Container Engine,Rackspace和Docker Data Center[4].

根據(jù)云計(jì)算平臺(tái)的架構(gòu),圖1 實(shí)現(xiàn)HTML 的應(yīng)用,使用容器技術(shù)部署的Web 服務(wù)器,分成3 層結(jié)構(gòu).第1 層是基礎(chǔ)設(shè)施即是服務(wù)(Infrastructure-as-a-Service,IaaS),是云計(jì)算的最底層,主要用來(lái)提供基礎(chǔ)資源,IaaS 中間件的解決方案主要由Amazon,VMWare 和IBM[5]等大公司提供.第2 層是平臺(tái)即是服務(wù)(PaaS).顯示一臺(tái)物理機(jī)中,可以安裝多臺(tái)不同操作系統(tǒng)的虛擬機(jī),于每個(gè)虛擬機(jī)內(nèi)安裝Docker 容器引擎.在Docker 容器中下載特定容器鏡像,使用容器構(gòu)建網(wǎng)頁(yè)服務(wù)器以及進(jìn)行數(shù)據(jù)庫(kù)的管理.第3 層為軟件即是服務(wù)(Software-as-a-Service,SaaS).這是與客戶連接的一層,大多數(shù)通過(guò)網(wǎng)頁(yè)瀏覽器進(jìn)行接入.在云計(jì)算平臺(tái)上使用容器部署網(wǎng)頁(yè)應(yīng)用程序,使用HTML 等技術(shù)開(kāi)發(fā)網(wǎng)頁(yè)應(yīng)用程序,最后交付給客戶最直接的網(wǎng)頁(yè)瀏覽網(wǎng)址或者手機(jī)軟件APP.

圖1 容器于網(wǎng)頁(yè)應(yīng)用的云計(jì)算平臺(tái)

所以,文獻(xiàn)[6] 初步提出在Docker 環(huán)境下,Java Web 快速搭建平臺(tái)的設(shè)計(jì)理念,為開(kāi)發(fā)網(wǎng)頁(yè)服務(wù)器提供一個(gè)新的思路.然而,在網(wǎng)頁(yè)服務(wù)器的開(kāi)發(fā)過(guò)程,經(jīng)常遇見(jiàn)產(chǎn)品的開(kāi)發(fā)環(huán)境和客戶的使用環(huán)境不盡相同.所以,每次面對(duì)一個(gè)新硬件環(huán)境的時(shí)候,就需要重新安裝一次.這樣,容易發(fā)生人為操作的錯(cuò)誤,導(dǎo)致產(chǎn)品的開(kāi)發(fā)、測(cè)試、維護(hù)成本增加的問(wèn)題;此外,還會(huì)造成重復(fù)加載,造成整體開(kāi)發(fā)速度緩慢的問(wèn)題.為了有效地避免發(fā)生以上的問(wèn)題,Docker 容器做為一個(gè)輕量級(jí)的應(yīng)用容器引擎,不只可以解決環(huán)境不兼容的問(wèn)題,還可以保持操作環(huán)境的一致性,減少重復(fù)安裝環(huán)境的行為,提升開(kāi)發(fā)效率.即便目前使用Docker 容器技術(shù)應(yīng)用在網(wǎng)頁(yè)服務(wù)器的研究很多,例如:Docker 容器應(yīng)用于Web邊緣設(shè)備服務(wù)的部署[7]、Web 應(yīng)用自動(dòng)縮放的功能[8]和網(wǎng)頁(yè)服務(wù)器的負(fù)載均衡[9]等.但是,尚未有對(duì)于Docker容器于網(wǎng)頁(yè)服務(wù)器開(kāi)發(fā)模式的研究.所以,本文將以Docker 容器為基礎(chǔ),分別結(jié)合Nginx 技術(shù)和Flask 技術(shù),建立有效開(kāi)發(fā)網(wǎng)頁(yè)服務(wù)器的模式.

總之,本文針對(duì)傳統(tǒng)B/S 模式部署的網(wǎng)頁(yè)服務(wù)器進(jìn)行研究,主要的貢獻(xiàn)有以下3 點(diǎn).(1)提出DoNginx和DoFlask 兩種新的部署網(wǎng)頁(yè)服務(wù)器模式,以Docker容器為基礎(chǔ),應(yīng)用于云平臺(tái)開(kāi)發(fā)網(wǎng)頁(yè)服務(wù)器的方案.(2)分析這兩種模式與傳統(tǒng)的模式的區(qū)別,測(cè)試CPU占用率、產(chǎn)品交付完整性和數(shù)據(jù)吞吐量3 種性能.得出以Docker 容器開(kāi)發(fā)的網(wǎng)頁(yè)服務(wù)器,更具高效性和完整性.(3)實(shí)現(xiàn)網(wǎng)頁(yè)開(kāi)發(fā)的標(biāo)準(zhǔn)化和流程化,提升輕量級(jí)網(wǎng)頁(yè)服務(wù)器的開(kāi)發(fā)效率.

文章結(jié)構(gòu)上,引言說(shuō)明服務(wù)器的使用和背景,分析目前開(kāi)發(fā)網(wǎng)頁(yè)服務(wù)器存在的問(wèn)題,介紹虛擬化技術(shù),其余的說(shuō)明如下.在第1 節(jié),介紹網(wǎng)頁(yè)服務(wù)器相關(guān)的研究工作.第2 節(jié)講述B/S、DoNginx 和DoFlask 等3 種開(kāi)發(fā)網(wǎng)頁(yè)服務(wù)器的模式.第3 節(jié),對(duì)這3 種模式的性能進(jìn)行分析和比較.最后的結(jié)束語(yǔ),總結(jié)本文以及未來(lái)的研究方向.

1 相關(guān)工作

1.1 國(guó)內(nèi)外研究近況

文獻(xiàn)[7]提出一種基于Web 服務(wù)部署的方法,為了解決Docker API 使用困難的問(wèn)題,研究更加抽象的HTTP API,用于部署、更新、終止邊緣設(shè)備上的容器.

從文獻(xiàn)[8]可得,人們?yōu)榱藵M足Web 高效率的需求,會(huì)購(gòu)買大量服務(wù)器或是高階服務(wù)器進(jìn)行簡(jiǎn)單的工作,過(guò)度高效的硬件容易造成資源的浪費(fèi),低配置的硬件將無(wú)法滿足高度流量的環(huán)境.所以,提出混合云無(wú)限縮放Web 應(yīng)用的構(gòu)思,設(shè)計(jì)一個(gè)基于Docker容器的混合云平臺(tái),實(shí)現(xiàn)Web 應(yīng)用的自動(dòng)擴(kuò)展,進(jìn)行容器部署和具備自動(dòng)縮放特性的應(yīng)用程序.

文獻(xiàn)[10] 中提到,Nginx 是具備開(kāi)源、輕量級(jí)、和高性能特性的服務(wù)器,由于它的高性能和易于擴(kuò)展的優(yōu)點(diǎn),近年來(lái)受到開(kāi)發(fā)人員的歡迎,并且應(yīng)用廣泛.通過(guò)Nginx 和HTTP 的處理流程,得以動(dòng)態(tài)地調(diào)整服務(wù)器的權(quán)重,取得較佳的服務(wù)器性能.

文獻(xiàn)[11]對(duì)Nginx 的體系模塊、框架結(jié)構(gòu)的內(nèi)部架構(gòu)和實(shí)現(xiàn)的原理進(jìn)行研究.使用C++語(yǔ)言,對(duì)Nginx的源碼進(jìn)行封裝和擴(kuò)展.

文獻(xiàn)[12]驗(yàn)證Docker 鏡像在Python 語(yǔ)言環(huán)境下運(yùn)行的可行性,將一臺(tái)虛擬機(jī)上的Python 文件打包成鏡像,上傳到云平臺(tái).然后,在另一臺(tái)虛擬機(jī)中拉取鏡像,完成兩臺(tái)虛擬機(jī)之間軟件的交付.這種做法,為本文使用的Flask 技術(shù)奠定基礎(chǔ),因?yàn)镕lask 技術(shù)是基于Python 的Web 開(kāi)發(fā)技術(shù),可以快速建立可交付部署的網(wǎng)頁(yè)平臺(tái).

文獻(xiàn)[13]說(shuō)明FTP 服務(wù)器上傳和下載文件的功能,同時(shí)設(shè)計(jì)與實(shí)現(xiàn)FTP 的遠(yuǎn)程管理系統(tǒng).最終,通過(guò)FTP 遠(yuǎn)程管理系統(tǒng)實(shí)現(xiàn)FTP 服務(wù)器,縮短傳輸數(shù)據(jù)和提交數(shù)據(jù)的時(shí)間.它不僅使普通客戶和管理員不再記錄復(fù)雜的FTP 命令,而且大大減少管理員的工作量,提高工作效率.

1.2 符號(hào)定義

本文中涉及到的符號(hào)與意義,見(jiàn)表1.

表1 符號(hào)表

2 系統(tǒng)架構(gòu)和模式

首先介紹FTP 工具在物理機(jī)和虛擬機(jī)之間傳輸信息的流程,然后介紹Docker容器的框架.最后,分別提出3 種模式的設(shè)計(jì)與實(shí)現(xiàn).

2.1 系統(tǒng)架構(gòu)

2.1.1 FTP 傳輸原理

FTP 協(xié)議是一個(gè)在計(jì)算機(jī)網(wǎng)絡(luò)上,能夠?qū)τ脩舳撕头?wù)器之間進(jìn)行文件傳輸?shù)膽?yīng)用層協(xié)議.同時(shí),FTP 服務(wù)器進(jìn)程可以為多個(gè)用戶端的進(jìn)程提供服務(wù).當(dāng)FTP 用戶端連接FTP 服務(wù)器,遵循FTP 的協(xié)議與服務(wù)器傳送文件,完成上傳下載文件任務(wù)[14].

通過(guò)FTP 工具與虛擬平臺(tái)之間進(jìn)行通信.在虛擬的環(huán)境中,將文件復(fù)制到Docker 容器下,實(shí)現(xiàn)Nginx與HTML 和Flask 與HTML 的交互通訊,使Nginx 和Flask 可以執(zhí)行HTML、JavaScript 和CSS 文件.此時(shí),在虛擬機(jī)中的Docker,便可以拉取Nginx 鏡像與創(chuàng)建Flask 鏡像,分別將Nginx 和Flask 下的鏡像配置文件進(jìn)行部署與執(zhí)行.FTP 工具與Docker 的關(guān)系,如圖2所示.

圖2 FTP 傳輸文件關(guān)系

2.1.2 Docker 架構(gòu)

圖3 的Docker 網(wǎng)頁(yè)服務(wù)器架構(gòu),顯示Nginx 技術(shù)和Flask 技術(shù)的關(guān)系,組成說(shuō)明如下:

圖3 Docker 架構(gòu)圖

(1)Docker client:Docker 的用戶端,是操作命令的終端.可以在主機(jī)直接執(zhí)行Docker 命令,在用戶端同時(shí)與多個(gè)Docker 的守護(hù)程序通信.

(2)Docker daemon:守護(hù)Docker 的進(jìn)程,監(jiān)聽(tīng)Docker API 的請(qǐng)求與管理Docker 的對(duì)象,例如:鏡像、容器、網(wǎng)絡(luò)、和卷.守護(hù)程序還可以與其它的守護(hù)程序通信,進(jìn)行管理Docker 的服務(wù).

(3)Docker image:Docker 的鏡像,是一個(gè)只讀文件,用來(lái)創(chuàng)建運(yùn)行容器.一個(gè)鏡像可以創(chuàng)建很多個(gè)容器,以Dockerfile 文件指令集創(chuàng)建Docker 鏡像.鏡像包含Ubuntu、Nginx、MySQL 和PHP 等官方鏡像,也包括自創(chuàng)建鏡像文件.

(4)Docker container:Docker 容器,負(fù)責(zé)應(yīng)用程序的運(yùn)行.容器獨(dú)立運(yùn)行一個(gè)或一組應(yīng)用或服務(wù),每個(gè)容器之間各自獨(dú)立,容器的開(kāi)啟、停止、和刪除,與其它容器無(wú)關(guān).啟動(dòng)鏡像后生成的容器,會(huì)自動(dòng)生成容器ID 和名稱,也可以自行命名容器的名稱.

(5)Docker registry:Docker 的倉(cāng)庫(kù),集中存放鏡像文件的場(chǎng)所.倉(cāng)庫(kù)分為公開(kāi)倉(cāng)庫(kù)(public)和私有倉(cāng)庫(kù)(private)兩種形式,倉(cāng)庫(kù)內(nèi)存放的每個(gè)鏡像文件,都有不同的標(biāo)簽.在Docker Hub 官網(wǎng)上創(chuàng)建的Docker 賬戶,容許新創(chuàng)建的鏡像到官網(wǎng),實(shí)現(xiàn)鏡像再利用.

2.2 系統(tǒng)模式

本節(jié)對(duì)DoNginx 模式和DoFlask 模式分別設(shè)計(jì)運(yùn)行序列圖,以及運(yùn)行時(shí)間優(yōu)化算法,與傳統(tǒng)B/S 模式作對(duì)比,對(duì)網(wǎng)頁(yè)服務(wù)器進(jìn)行設(shè)計(jì)與實(shí)現(xiàn).

2.2.1 傳統(tǒng)B/S 模式

B/S 模式即瀏覽器(browser)和服務(wù)器(server)架構(gòu)模式,是對(duì)C/S 模式的改進(jìn)架構(gòu)模式.用戶端界面是通過(guò)瀏覽器來(lái)實(shí)現(xiàn),極少事務(wù)邏輯在前端實(shí)現(xiàn),主要事務(wù)邏輯在服務(wù)器端實(shí)現(xiàn).這種模式將實(shí)現(xiàn)系統(tǒng)功能的主要工作集中到服務(wù)器上,具有無(wú)需安裝用戶端、易于在Web 上發(fā)布信息和易于擴(kuò)展等優(yōu)點(diǎn)[15].同時(shí),簡(jiǎn)化了系統(tǒng)的開(kāi)發(fā)、維護(hù)和使用.

圖4 顯示B/S 模式構(gòu)建網(wǎng)頁(yè)服務(wù)器的運(yùn)行序列關(guān)系,包含用戶端界面、控制機(jī)制、服務(wù)器和數(shù)據(jù)庫(kù).用戶端界面即瀏覽器,負(fù)責(zé)顯示結(jié)果,是用戶操作系統(tǒng)的接口.控制機(jī)制即中間件,運(yùn)行在瀏覽器和服務(wù)器之間,負(fù)責(zé)傳遞信息.服務(wù)器負(fù)責(zé)與數(shù)據(jù)庫(kù)進(jìn)行連接,提供數(shù)據(jù)服務(wù),通過(guò)數(shù)據(jù)庫(kù)返回結(jié)果.

圖4 B/S 運(yùn)行序列圖

序列圖顯示開(kāi)發(fā)過(guò)程,有以下3 個(gè)步驟.

首先,開(kāi)發(fā)人員通過(guò)過(guò)程①創(chuàng)建命令,生成靜態(tài)網(wǎng)頁(yè),在用戶端界面顯示.用戶通過(guò)用戶端界面通過(guò)過(guò)程②向服務(wù)器端發(fā)出請(qǐng)求,由控制機(jī)制接收,再通過(guò)過(guò)程③傳送給服務(wù)器.

然后,服務(wù)器接收請(qǐng)求命令,通過(guò)過(guò)程④與數(shù)據(jù)庫(kù)進(jìn)行連接,對(duì)數(shù)據(jù)進(jìn)行存取等操作.數(shù)據(jù)庫(kù)使用過(guò)程⑤將結(jié)果反饋到控制機(jī)制,控制機(jī)制將通過(guò)過(guò)程⑥結(jié)果繼續(xù)反饋給用戶端界面.

最后,用戶端界面將返回來(lái)的結(jié)果進(jìn)行處理,可以將系統(tǒng)的邏輯功能更好地展示出來(lái),再通過(guò)過(guò)程⑦顯示界面.

通過(guò)式(1)計(jì)算編譯運(yùn)行代碼文件的時(shí)間,式(2)計(jì)算構(gòu)建網(wǎng)頁(yè)并運(yùn)行的全部時(shí)間.

B/S 模式構(gòu)建網(wǎng)頁(yè)服務(wù)器的時(shí)間函數(shù)BSOpTime(n,T),算法如算法1.

算法1.BSOpTime輸入: n.輸出:T.

Tbegin=cl ock();for i=1 to n Tfile+=Wi;Send Web to user;Treturn=clock();T=Treturn-Tbegin;return T;end

2.2.2 DoNginx 模式

Nginx 是一款高性能和輕量級(jí)的Web 服務(wù)器.它依據(jù)全新的服務(wù)器開(kāi)發(fā)模型,采用事件驅(qū)動(dòng)架構(gòu)處理請(qǐng)求,不只可以隱藏自己的IP 地址,性能優(yōu)異且占據(jù)內(nèi)存小,整體運(yùn)行效率遠(yuǎn)超過(guò)傳統(tǒng)的Apache 和Tomcat[10].在虛擬平臺(tái),使用Docker 和Nginx 技術(shù)開(kāi)發(fā)Web 服務(wù)器,稱之DoNginx 模式.

圖5 顯示DoNginx 的運(yùn)行序列關(guān)系,包含客戶所在的物理機(jī)、虛擬平臺(tái)、Docker Hub、Nginx 容器、FTP 工具和管理平臺(tái)等6 個(gè)會(huì)話.開(kāi)發(fā)人員需要先創(chuàng)建開(kāi)發(fā)項(xiàng)目代碼,FTP 工具負(fù)責(zé)將開(kāi)發(fā)過(guò)程中的代碼文件傳到虛擬平臺(tái),管理平臺(tái)負(fù)責(zé)執(zhí)行代碼文件.序列圖顯示的開(kāi)發(fā)過(guò)程,依序有以下3 個(gè)步驟.

圖5 DoNginx 運(yùn)行序列圖

首先,開(kāi)發(fā)人員通過(guò)過(guò)程①啟動(dòng)虛擬平臺(tái),然后通過(guò)流程②向Docker Hub 請(qǐng)求拉取Nginx 鏡像,使用⑧返回拉取結(jié)果,若拉取成功會(huì)返回成功結(jié)果,如果失敗返回失敗信息.接下來(lái)使用過(guò)程③啟動(dòng)鏡像生成容器并命名,若啟動(dòng)成功執(zhí)行過(guò)程⑦返回容器ID,若失敗返回錯(cuò)誤信息.

然后,使用IP 地址連接FTP 工具,進(jìn)行過(guò)程④,FTP 工具對(duì)密鑰進(jìn)行檢測(cè).連接成功后,選擇要執(zhí)行的代碼文件上傳到虛擬機(jī),記作VM.然后查看上傳的結(jié)果,若上傳成功,則在虛擬機(jī)中查看文件信息;若失敗,則返回錯(cuò)誤的信息.過(guò)程⑥會(huì)從虛擬機(jī)中復(fù)制開(kāi)發(fā)人員上傳的n個(gè)文件到Nginx 容器內(nèi)部指定的文件,形成代碼文件集F={F1,F2,…,Fn}.

最后,過(guò)程⑤使用管理平臺(tái)設(shè)置虛擬開(kāi)發(fā)環(huán)境,執(zhí)行代碼文件集F.打開(kāi)網(wǎng)頁(yè)瀏覽器訪問(wèn)Nginx 容器內(nèi)部網(wǎng)頁(yè)配置代碼文件F,成功出現(xiàn)需要開(kāi)發(fā)的網(wǎng)頁(yè).使用過(guò)程⑩返回給虛擬平臺(tái)反饋信息,然后物理機(jī)中通過(guò)過(guò)程⑨訪問(wèn)構(gòu)建的網(wǎng)頁(yè).

通過(guò)式(3)得到上傳文件到虛擬機(jī)的時(shí)間以及將所有文件復(fù)制到Nginx 鏡像的全部時(shí)間.同時(shí),式(4)可以得出Nginx 鏡像運(yùn)行的時(shí)間與構(gòu)建網(wǎng)頁(yè)時(shí)間的和.加入拉取鏡像的時(shí)間后,可以取得全部的計(jì)算時(shí)間,如式(5).

DoNginx 模式構(gòu)建網(wǎng)頁(yè)服務(wù)器的時(shí)間函數(shù)DoNginx-OpTime(n,T),算法如算法2.

算法2.DoNginxOpTime輸入:n.輸出:T.Tbegin = clock();Send file.html + file.css + file.js to VM;Tfile = Tupload;Send file.html + file.css + file.js to Docker.Nginx;for i = 1 to n Tfile += Fi;Trun = run Nginx.image + Web;Send Web to user;Treturn = clock();T1 = Treturn-Tbegin;if T1 == Tpull + Trun + Tfile;return T = T1;end

2.2.3 DoFlask 模式

此模式是結(jié)合Docker 和Flask 技術(shù),開(kāi)發(fā)網(wǎng)頁(yè)服務(wù)器.目前采用Python 開(kāi)發(fā)網(wǎng)頁(yè)項(xiàng)目的主流框架,包括Django 和Flask.Django 框架是廣泛而全面;Flask框架偏向輕量級(jí)、簡(jiǎn)潔和靈活,主要面向一些功能簡(jiǎn)單、需求簡(jiǎn)單和項(xiàng)目周期比較短的輕應(yīng)用.

開(kāi)發(fā)人員在Docker 內(nèi),創(chuàng)建Flask 鏡像,如圖6的DoFlask 運(yùn)行序列圖,呈現(xiàn)開(kāi)發(fā)網(wǎng)頁(yè)的序列流程關(guān)系.它包含服務(wù)器、用戶端、Docker Hub、虛擬平臺(tái)以及管理平臺(tái).在虛擬平臺(tái)中,開(kāi)發(fā)人員需要先創(chuàng)建開(kāi)發(fā)項(xiàng)目代碼,管理平臺(tái)負(fù)責(zé)執(zhí)行代碼文件.兩者不同的地方是,Nginx 需要虛擬平臺(tái)從Docker Hub 拉取鏡像,Flask 則需要服務(wù)器的虛擬平臺(tái)自行創(chuàng)建鏡像,然后上傳到Docker Hub,再使用用戶端虛擬平臺(tái)拉取鏡像.如圖6 的服務(wù)器做為開(kāi)發(fā)端服務(wù)器,負(fù)責(zé)創(chuàng)建鏡像,用戶端的虛擬平臺(tái)負(fù)責(zé)測(cè)試結(jié)果.

圖6 DoFlask 運(yùn)行序列圖

依照序列圖顯示,整體的開(kāi)發(fā)過(guò)程,有以下4 個(gè)步驟.

首先,開(kāi)發(fā)人員通過(guò)過(guò)程①創(chuàng)建鏡像文件,創(chuàng)建Python 文件、requirements 文件和Dockerfile 文件.requirements 文件用于記錄所有依賴包及其精確的版本號(hào),以便新環(huán)境的部署.然后,導(dǎo)出打包項(xiàng)目,依賴不同環(huán)境的依賴包和環(huán)境包,以便后續(xù)遷移項(xiàng)目的使用.在通過(guò)Dockerfile 文件,便可以自動(dòng)創(chuàng)建鏡像或自行定義創(chuàng)建.然后,啟動(dòng)開(kāi)發(fā)端服務(wù)器,在虛擬平臺(tái)中通過(guò)②和⑦安裝Python 環(huán)境和Flask 軟件包.若是安裝成功,則返回成功信息;若失敗,則返回錯(cuò)誤信息.

其次,使用過(guò)程⑧創(chuàng)建Web 包鏡像,即把過(guò)程①創(chuàng)建的文件打包,使用如下命令.

$ sudo docker build ＜DockerfilePath＞ -t＜ImageName＞ [:TAG]

當(dāng)使用?檢查創(chuàng)建結(jié)果,若創(chuàng)建成功,則返回成功信息.使用過(guò)程③登錄Docker Hub 賬戶,輸入用戶名密碼,進(jìn)行檢測(cè).通過(guò)過(guò)程⑨將鏡像文件上傳到Docker Hub 中的倉(cāng)庫(kù),使用過(guò)程?返回上傳結(jié)果,若上傳成功,則在Docker Hub 倉(cāng)庫(kù)中可以找到此鏡像.

第三,在用戶端中使用過(guò)程④拉取上傳到Docker Hub 倉(cāng)庫(kù)的鏡像,并且使用過(guò)程⑩返回拉取結(jié)果.通過(guò)過(guò)程⑤,啟動(dòng)拉取成功的鏡像;使用過(guò)程⑥,返回啟動(dòng)的容器ID.

最后,在管理平臺(tái)中,通過(guò)過(guò)程?訪問(wèn)啟動(dòng)的Flask 容器,查看內(nèi)部的Web 配置文件.使用IP 地址訪問(wèn)瀏覽器,從過(guò)程?返回訪問(wèn)結(jié)果.

式(6)得出上傳鏡像和拉取鏡像的全部時(shí)間,從式(7)可以計(jì)算全部的時(shí)間.然而,式(8)是運(yùn)行Flask鏡像時(shí)間與構(gòu)建網(wǎng)頁(yè)時(shí)間的和.

DoFlask 模式構(gòu)建網(wǎng)頁(yè)服務(wù)器的時(shí)間函數(shù)DoFlask-OpTime(n,T),算法如算法3.

算法3.DoFlaskOpTime輸入:n.輸出:T.Tbegin = clock();Server:Build image in Docker.Flask;Tpush = send image to Docker Hub;User:Tpull = pull image in Docker Hub;Trun = run Flask.image + Flask.Web;Send Web to user;Treturn = clock();T1 = Treturn-Tbegin;if T1 == Tbuild + Trun + Tfile;return T = T1;end

2.3 數(shù)據(jù)庫(kù)管理

圖7 的數(shù)據(jù)庫(kù)管理運(yùn)行序列關(guān)系,包含虛擬平臺(tái)、管理平臺(tái)、Docker Hub 和Docker 容器.在虛擬平臺(tái)的階段,使用Docker 和phpmyadmin 技術(shù)管理數(shù)據(jù)庫(kù).開(kāi)發(fā)人員需要先拉取鏡像,FTP 工具負(fù)責(zé)將開(kāi)發(fā)過(guò)程中的代碼文件傳到虛擬平臺(tái),管理平臺(tái)則負(fù)責(zé)設(shè)置虛擬開(kāi)發(fā)環(huán)境.總之,圖7 的序列圖顯示開(kāi)發(fā)過(guò)程,總結(jié)以下3 個(gè)步驟.

圖7 數(shù)據(jù)庫(kù)管理運(yùn)行序列圖

首先,開(kāi)發(fā)人員通過(guò)過(guò)程①啟動(dòng)虛擬平臺(tái),然后通過(guò)流程②向Docker Hub 請(qǐng)求分別拉取MySQL、PHP、phpmyadmin 鏡像.使用過(guò)程⑥返回拉取的結(jié)果,若是拉取成功則會(huì)返回成功結(jié)果;反之,則返回失敗信息.接下來(lái)使用過(guò)程③run 命令啟動(dòng)3 種鏡像,分別生成各自的容器并命名.若是啟動(dòng)成功,則執(zhí)行過(guò)程⑤,返回容器ID;若失敗,則返回錯(cuò)誤信息.

然后,使用IP 地址訪問(wèn)phpmyadmin 瀏覽器網(wǎng)頁(yè).進(jìn)行過(guò)程④,管理平臺(tái)對(duì)輸入的用戶名密碼進(jìn)行檢測(cè).若是檢測(cè)成功,則登錄到數(shù)據(jù)庫(kù).使用網(wǎng)頁(yè)版數(shù)據(jù)庫(kù)管理工具對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作,并使用過(guò)程⑦,返回結(jié)果;若失敗,則返回錯(cuò)誤信息.

最后,通過(guò)SQL 語(yǔ)句對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作,使用過(guò)程⑧,反饋信息給虛擬平臺(tái),讓物理機(jī)可以直接訪問(wèn)數(shù)據(jù)庫(kù)網(wǎng)頁(yè).

式(9)計(jì)算拉取全部鏡像的時(shí)間,式(10)計(jì)算啟動(dòng)全部鏡像與構(gòu)建網(wǎng)頁(yè)時(shí)間的和.式(9)加式(10)加編譯SQL 語(yǔ)句時(shí)間為總時(shí)間,如式(11).

連接靜態(tài)網(wǎng)頁(yè)服務(wù)器和數(shù)據(jù)庫(kù)的時(shí)間函數(shù)DBMOp-Time(n,T),算法如算法4.

算法4.DBMOPTime輸入:n.輸出:T.Tbegin = clock();for i = 1 to n Tpull += Pi;

Trun += Pi;Trun = Trun + Tweb;Send Web to user;Treturn = clock();T1 = Treturn - Tbegin;if T1 == Tpull + Trun + Tsql return T = T1;end

3 實(shí)驗(yàn)結(jié)果與分析

本節(jié)通過(guò)搭建Windows 和虛擬機(jī)環(huán)境的實(shí)驗(yàn)場(chǎng)景,設(shè)計(jì)了測(cè)試CPU、完整性、吞吐量的實(shí)驗(yàn).實(shí)驗(yàn)的配置環(huán)境的物理機(jī)操作系統(tǒng)為Windows 10,64-bit X86 系統(tǒng).物理機(jī)的處理器為Intel(R)Core(TM)i5-8265U CPU 1.60 GHz,內(nèi)存為8 192 MB RAM,硬盤(pán)為高速固態(tài)硬盤(pán),512 GB.實(shí)驗(yàn)用的虛擬機(jī)操作系統(tǒng)為Ubuntu 16.04 LTS,包括1 個(gè)CPU 和20 GB 內(nèi)存.內(nèi)設(shè)的實(shí)驗(yàn)軟件環(huán)境,如表2.

表2 實(shí)驗(yàn)軟件及版本說(shuō)明

3.1 實(shí)驗(yàn)結(jié)果

通過(guò)傳統(tǒng)B/S、DoNginnx 和DoFlask 三種模式,對(duì)開(kāi)發(fā)Web 應(yīng)用程序的過(guò)程進(jìn)行實(shí)驗(yàn),以Google 的cadvisor 技術(shù)監(jiān)控容器.檢測(cè)的過(guò)程,針對(duì)CPU 的占用情況、產(chǎn)品交付的完整性和服務(wù)器的吞吐量,得到下面的結(jié)果.

3.1.1 CPU 測(cè)試

圖8 顯示CPU 測(cè)試的結(jié)果,觀察各種方法在CPU的占用率.依序圖8(a)為傳統(tǒng)B/S 模式的CPU 占用率,DoNginx 模式CPU 占用率為圖8(b),以及圖8(c)的DoFlask 模式CPU 占用率.圖上顯示,傳統(tǒng)方法的CPU 占用率逐漸上升后趨于平穩(wěn).其次,DoNginx 模式的CPU 雖然起伏不定,但是占用率為最低.最后,DoFlask 模式在實(shí)驗(yàn)初期消耗大量CPU,后期逐漸下降并趨于平穩(wěn).這幾個(gè)實(shí)驗(yàn)橫軸均為4T,每個(gè)T為30 s.依照式(12)得出圖8 的平均值,依序分別為56%,24%,和43%.由此可知,DoNginx 模式占用的CPU 最低,而B(niǎo)/S 模式的占用率最高,消耗的資源最多.

圖8 各種方法的CPU 占用率

3.1.2 吞吐量測(cè)試

圖9 為吞吐量的測(cè)試分析圖,顯示各種方法的數(shù)據(jù)吞吐量.依圖9(a)-圖9(c)的順序顯示,傳統(tǒng)B/S 模式、DoNginx 模式和DoFlask 模式的吞吐量.由此可知,傳統(tǒng)方法的吞吐量在2.5 Mb/s 與7.5 Mb/s 之間,其次,DoNginx 模式的吞吐量在中間部分逐漸上升后又稍微下降并趨于平穩(wěn).然而,DoFlask 模式的吞吐量起伏不定,卻始終高于5 Mb/s.依照式(12)可以得出平均值,依序?yàn)?.8 Mb/s、3.8 Mb/s 和4.2 Mb/s.故此,結(jié)論是B/S 模式數(shù)據(jù)吞吐量最大,傳輸數(shù)據(jù)效率最快,而DoNginx 模式數(shù)據(jù)吞吐量最少.

圖9 各種方法的吞吐量

3.1.3 產(chǎn)品交付完整性測(cè)試

測(cè)試的過(guò)程,主要經(jīng)過(guò)兩個(gè)步驟:(1)在服務(wù)器部署Web 應(yīng)用程序,完成后傳輸?shù)接脩舳?(2)在用戶端,對(duì)Web 應(yīng)用程序進(jìn)行檢測(cè).

在進(jìn)行30 個(gè)產(chǎn)品的傳輸后,發(fā)現(xiàn)環(huán)境不兼容導(dǎo)致的錯(cuò)誤有模塊錯(cuò)位、數(shù)據(jù)消失以及樣式出錯(cuò)等.圖10是測(cè)試后得出的結(jié)果,傳統(tǒng)B/S 模式開(kāi)發(fā)的產(chǎn)品,傳輸?shù)脚c開(kāi)發(fā)環(huán)境不同的用戶端后,70%會(huì)出現(xiàn)以上錯(cuò)誤,需要開(kāi)發(fā)人員繼續(xù)進(jìn)行維護(hù).而且出錯(cuò)率不穩(wěn)定,難以預(yù)測(cè)結(jié)果.以DoNginx 模式開(kāi)發(fā)的產(chǎn)品,傳輸?shù)讲煌h(huán)境用戶端后,20%會(huì)出現(xiàn)錯(cuò)誤.使用DoFlask 開(kāi)發(fā)的產(chǎn)品,出錯(cuò)率僅為5%,并且數(shù)據(jù)保持穩(wěn)定,可以對(duì)未來(lái)的實(shí)驗(yàn)結(jié)果進(jìn)行推測(cè).

圖10 各種方法的完整性測(cè)試

總結(jié)實(shí)驗(yàn)測(cè)試的結(jié)果.首先,使用DoNginx 技術(shù)的CPU 占用率最低、效率高、內(nèi)存占用較少和產(chǎn)品交付的出錯(cuò)率較低;其次,使用DoFlask 技術(shù)對(duì)CPU 的占用率較低、占用內(nèi)存最少,并且具有環(huán)境兼容性,大大提高產(chǎn)品交付的穩(wěn)定性;最后,傳統(tǒng)的B/S 模式對(duì)CPU 占用率最高、占用的內(nèi)存最多和產(chǎn)品交付的出錯(cuò)率最高.

3.2 實(shí)驗(yàn)分析

本節(jié)對(duì)3 種模式性能測(cè)試實(shí)驗(yàn)結(jié)果進(jìn)行分析.

(1)分析CPU 占用率.第一,使用DoNginx 設(shè)計(jì)方案得到的產(chǎn)品運(yùn)行速率快、數(shù)據(jù)傳輸效率高、在瀏覽器調(diào)試代碼方便、開(kāi)發(fā)效率高且CPU 占用率低.第二,使用DoFlask 的設(shè)計(jì)方案使產(chǎn)品可靠性與穩(wěn)定性,大幅提高;通過(guò)可以打包生成鏡像的技術(shù),提高產(chǎn)品重復(fù)利用率.第三,經(jīng)過(guò)大量驗(yàn)證性實(shí)驗(yàn)得到的數(shù)據(jù)知道,使用Docker 輕量級(jí)容器技術(shù),將會(huì)比使用傳統(tǒng)B/S 技術(shù)節(jié)約20%左右的CPU 利用率,平均減少50%的內(nèi)存使用量.

綜合以上分析,圖11 顯示系統(tǒng)每Ts(實(shí)驗(yàn)設(shè)置為30 s)收集CPU 的利用率,以及這3 種模式在不同階段的比較.

在圖11 的0-T時(shí)間段部分,可以看出此時(shí)DoFlask占用CPU 最多.然而,傳統(tǒng)B/S 模式占用的CPU 利用率比較少,這是因?yàn)榇藭r(shí)處于修改代碼的狀態(tài);2T-4T時(shí)間段是處于程序執(zhí)行的狀態(tài).在T-2T時(shí)間段的部分,可以發(fā)現(xiàn)DoNginx 和DoFlask 都達(dá)到最大值,因?yàn)檫@兩種方案都處于執(zhí)行的狀態(tài),消耗資源最大.然而,在2T-3T的時(shí)間段,DoFlask 處于創(chuàng)建鏡像的狀態(tài),無(wú)需消耗大量的資源.3T-4T的時(shí)間段內(nèi),在另一臺(tái)服務(wù)器的DoFlask,處于拉取鏡像和執(zhí)行程序的狀態(tài),此時(shí)消耗資源較多.所以,可以得知無(wú)論在哪一階段,DoNginx都是CPU 占用率最低的技術(shù),DoFlask 緊隨其后.

圖11 CPU 占用率比較圖

(2)分析數(shù)據(jù)吞吐量.經(jīng)由圖12 的吞吐量比較圖乃是以每一個(gè)Ts(30 s)為單位,收集數(shù)據(jù)傳輸吞吐量后分析,有以下兩點(diǎn).第一,傳統(tǒng)B/S 模式部署網(wǎng)頁(yè)的優(yōu)點(diǎn)是傳輸數(shù)據(jù)速度快,數(shù)據(jù)吞吐量大,并且較為平穩(wěn).第二,DoNginx 和DoFlask 技術(shù)在前期的數(shù)據(jù)傳輸量小,后期逐漸增加,這是因?yàn)門-3T時(shí)間段任務(wù)是拉取和生成鏡像;3T-4T時(shí)間段任務(wù)是執(zhí)行程序.

圖12 數(shù)據(jù)吞吐量比較圖

(3)分析交付完整性.使用DoFlask 模式創(chuàng)建網(wǎng)頁(yè),將開(kāi)發(fā)網(wǎng)頁(yè)服務(wù)器的文件打包生成鏡像,然后上傳到云空間,可以在其它服務(wù)器下載并啟動(dòng)此鏡像.這種方法完美的解決環(huán)境不兼容的問(wèn)題,保證交付產(chǎn)品的完整性.所以DoFlask 模式交付完整性最高.

根據(jù)以上的3 點(diǎn)分析,歸納內(nèi)容如表3.它顯示各個(gè)系統(tǒng)模式的性能測(cè)試結(jié)果.

表3 各模式的性能測(cè)試表

(4)分析變異數(shù)狀態(tài).根據(jù)收集的數(shù)據(jù),式(13)得出標(biāo)準(zhǔn)差,使用式(14)得出變異數(shù).從變異數(shù)變異的程度,可以看出3 種模式彼此之間的不同.

總結(jié)得出表4,發(fā)現(xiàn)CPU 的變異程度大于完整性測(cè)試,完整性測(cè)試大于數(shù)據(jù)吞吐量.B/S 模式的CPU 占用率和吞吐量的變異程度較高,完整性測(cè)試變異程度最高.DoNginx 模式的CPU 占用率變異程度最高,吞吐量和完整性測(cè)試變異程度較低.DoFlask 模式的CPU 占用率和完整性測(cè)試變異程度最低,吞吐量變異程度較高.所以,B/S 模式總體變異數(shù)最大也最不穩(wěn)定;DoNginx 模式變異數(shù)較低,較為穩(wěn)定;DoFlask 模式變異數(shù)最低,最為穩(wěn)定.

表4 CPU 和吞吐量的變異數(shù)狀態(tài)

綜合B/S 模式、DoNginx 和DoFlask 模式建構(gòu)的網(wǎng)頁(yè)服務(wù)器過(guò)程,分析測(cè)試的性能后得出結(jié)論:利用DoFlask 模式建構(gòu)網(wǎng)頁(yè)服務(wù)器比傳統(tǒng)B/S 模式和DoNginx 下的建構(gòu)交付完整性提高20%-65%個(gè)級(jí)別,CPU 占用率較低,并且縮小內(nèi)存占用量,明顯具備開(kāi)發(fā)上的優(yōu)勢(shì).

4 結(jié)論與展望

針對(duì)現(xiàn)有的B/S 模式開(kāi)發(fā)網(wǎng)頁(yè)服務(wù)器存在數(shù)據(jù)傳輸慢、資源占用大且不兼容的缺點(diǎn),提出了新型的Docker 技術(shù)分別結(jié)合Nginx 和Flask 的模型.對(duì)3 種開(kāi)發(fā)模型進(jìn)行研究和測(cè)試,根據(jù)3 種模式在開(kāi)發(fā)性能和兼容性的不同,推斷出最適合開(kāi)發(fā)網(wǎng)頁(yè)的模式為DoFlask 模式,為開(kāi)發(fā)人員和運(yùn)維人員節(jié)省大量開(kāi)發(fā)交付與等待的時(shí)間,降低產(chǎn)品環(huán)境更新過(guò)程中可能的出錯(cuò)率.此外,服務(wù)器虛擬化技術(shù)打破單應(yīng)用單服務(wù)器的傳統(tǒng)部署模式,提高硬件資源的利用率,簡(jiǎn)化服務(wù)器的運(yùn)維管理工作,從而降低管理費(fèi)用.

無(wú)論用DoNginx 或者DoFlask 結(jié)合數(shù)據(jù)庫(kù)技術(shù),都可以快速地搭建Web 系統(tǒng).對(duì)于一般的初學(xué)者而言,需要了解和掌握全部的技術(shù),還是需要一定的時(shí)間學(xué)習(xí)和探索.未來(lái)可以結(jié)合這兩種技術(shù),提供即便沒(méi)有開(kāi)發(fā)經(jīng)驗(yàn)的初學(xué)者,只要填入需求,依照發(fā)展的新算法,便能夠自動(dòng)推薦并且直接生成基本網(wǎng)頁(yè)的系統(tǒng).