丁強(qiáng)龍,葉惠珠

1(昆明市公安局五華分局 指揮中心,昆明 650000)

2(云南師范大學(xué)文理學(xué)院 城市學(xué)院,昆明 650000)

1 引言

將應(yīng)用系統(tǒng)部署于云平臺(tái)在建設(shè)成本、管理成本、資源共享等方面較傳統(tǒng)的物理服務(wù)器方式部署優(yōu)勢(shì)明顯,越來(lái)越多的部門、地方建立了云平臺(tái),越來(lái)越多的應(yīng)用已經(jīng)或正在向云平臺(tái)遷移.現(xiàn)在,國(guó)內(nèi)外也有大量關(guān)于應(yīng)用系統(tǒng)向云平臺(tái)遷移的研究.例如文獻(xiàn)[1]對(duì)多組件應(yīng)用系統(tǒng)遷移到云平臺(tái)的方法進(jìn)行了形式化的研究,建議多組件應(yīng)用系統(tǒng)盡量部署在云平臺(tái)的同一臺(tái)物理服務(wù)器、同一個(gè)網(wǎng)段下.文獻(xiàn)[2]重點(diǎn)研究分析了中、小型企業(yè)的應(yīng)用系統(tǒng)向商業(yè)云平臺(tái)遷移的成本、技術(shù)等問(wèn)題,其分析結(jié)論體現(xiàn)了在云平臺(tái)部署應(yīng)用的成本優(yōu)勢(shì).文獻(xiàn)[3]針對(duì) Amazon EC2 提出一種自動(dòng)搜索策略,解決云服務(wù)器在位置、存儲(chǔ)等方面的優(yōu)化問(wèn)題,給出遷移企業(yè)最優(yōu)配置建議.文獻(xiàn)[4]對(duì)企業(yè)應(yīng)用向云平臺(tái)遷移的性能、安全、管理,以及所面臨的調(diào)整挑戰(zhàn)等方面的問(wèn)題進(jìn)行了概述,并指出遷移過(guò)程中的應(yīng)用優(yōu)化問(wèn)題.文獻(xiàn)[5,6]重點(diǎn)分析了應(yīng)用遷移面臨的挑戰(zhàn),例如安全、成本、服務(wù)協(xié)議、云的互操作性等方面的問(wèn)題.文獻(xiàn)[7]介紹了一種垂直java EE多層應(yīng)用到彈性云應(yīng)用,指導(dǎo)軟件開(kāi)發(fā)人員采用最優(yōu)彈性策略改造其應(yīng)用.

文獻(xiàn)[8]總結(jié)了當(dāng)前云平臺(tái)遷移的研究?jī)?nèi)容,并提取了核心遷移過(guò)程,簡(jiǎn)稱Cloud-RMM,包括規(guī)劃、執(zhí)行、評(píng)估、橫切關(guān)注點(diǎn)等4個(gè)方面.

1) 規(guī)劃: 包括可行性研究,需求分析,供應(yīng)商和服務(wù)的決策,遷移策略等.

2) 執(zhí)行: 代碼修改,體系結(jié)構(gòu)提取,數(shù)據(jù)提取、轉(zhuǎn)換、同步問(wèn)題等.

3) 評(píng)估: 系統(tǒng)在云平臺(tái)的部署,測(cè)試,驗(yàn)證等.

4) 橫切關(guān)注點(diǎn): 包括管理、安全、培訓(xùn),評(píng)估,組織變革,多租戶[8]等6個(gè)層面的內(nèi)容.

文獻(xiàn)[9] 整合現(xiàn)有文獻(xiàn)的過(guò)程模型,提出了一個(gè)通用的參考方法,同時(shí)指出,一個(gè)固定遷移方法不適用于所有給定的遷移場(chǎng)景.

文獻(xiàn)[10]指出當(dāng)前應(yīng)用基礎(chǔ)設(shè)施的異構(gòu)性、復(fù)雜,使其遷移過(guò)程具有挑戰(zhàn)性.基于IBM業(yè)務(wù)流程管理(BPM)的遷移技術(shù)與預(yù)遷移分析,其提出大型應(yīng)用的云遷移云自動(dòng)化與協(xié)調(diào)框架.

綜上,云平臺(tái)同傳統(tǒng)系統(tǒng)結(jié)構(gòu)差異較大,云平臺(tái)的安全策略也與傳統(tǒng)平臺(tái)不同,盡管目前國(guó)內(nèi)外已經(jīng)有了大量的已有應(yīng)用向云平臺(tái)遷移的研究,但這些研究大多是純理論層面的,具體遷移過(guò)程中,由于各應(yīng)用程序差異較大,需要根據(jù)其系統(tǒng)自身特點(diǎn)進(jìn)行相應(yīng)的調(diào)整.文獻(xiàn)[11]指出國(guó)土資源網(wǎng)上交易系統(tǒng)的實(shí)時(shí)性、穩(wěn)定性和安全性要求極高,給出了國(guó)土資源網(wǎng)上交易系統(tǒng)的內(nèi)核基本框架,提出了一種國(guó)土資源網(wǎng)上交易系統(tǒng)內(nèi)核優(yōu)化方法,然而這種優(yōu)化方法在系統(tǒng)向云平臺(tái)遷移過(guò)程中又將面臨新的問(wèn)題,即云平臺(tái)適應(yīng)性問(wèn)題.

針對(duì)上述存在的問(wèn)題,本例中的系統(tǒng)遷移,參照?qǐng)D1所示的核心過(guò)程并結(jié)合國(guó)土資源網(wǎng)上交易系統(tǒng)特點(diǎn),對(duì)其系統(tǒng)內(nèi)核等進(jìn)行了云平臺(tái)適應(yīng)性調(diào)整,制定了一套遷移方法保證現(xiàn)有系統(tǒng)的穩(wěn)定性、實(shí)時(shí)性、高并發(fā)性不受影響的解決方案.遷移過(guò)程中設(shè)計(jì)新的數(shù)據(jù)分流方法,前后臺(tái)數(shù)據(jù)的交換模塊,使遷移后的系統(tǒng)安全性有了較大提高,并解決了云服務(wù)器故障轉(zhuǎn)移后的交易接管問(wèn)題.

圖1 Cloud-RMM

系統(tǒng)在重慶、江西等地進(jìn)行了測(cè)試和實(shí)際運(yùn)行,其結(jié)果表明,以上設(shè)計(jì)具有可行性,調(diào)整后的系統(tǒng)能較好的適應(yīng)云平臺(tái)環(huán)境,而且更加安全、穩(wěn)定.這種方法可以為公安,國(guó)土、城市規(guī)劃等部門的現(xiàn)有應(yīng)用系統(tǒng)云遷移提供參考.

2 結(jié)構(gòu)設(shè)計(jì)

本節(jié)介紹基于云平臺(tái)的國(guó)土資源網(wǎng)上交易系統(tǒng)結(jié)構(gòu)設(shè)計(jì).

為了解決云平臺(tái)的數(shù)據(jù)安全問(wèn)題,將云平臺(tái)劃分為兩個(gè)大的區(qū)域,一個(gè)是互聯(lián)網(wǎng)區(qū)域,另外一個(gè)是內(nèi)網(wǎng)區(qū)域,內(nèi)網(wǎng)和互聯(lián)網(wǎng)區(qū)域通過(guò)“安全隔離網(wǎng)閘”進(jìn)行物理隔離,見(jiàn)圖2.相比起內(nèi)外網(wǎng)人工數(shù)據(jù)擺渡方式,這種設(shè)計(jì)方法,在保證安全性的前提下,為內(nèi)外網(wǎng)的數(shù)據(jù)交換提供了自動(dòng)完成的可能.

圖2 交易系統(tǒng)云平臺(tái)部署示意

為了盡可能的保證數(shù)據(jù)的安全性,將后臺(tái)管理與前臺(tái)交易分別部署在內(nèi)網(wǎng)區(qū)(SA)和互聯(lián)網(wǎng)區(qū)(IA).互聯(lián)網(wǎng)區(qū)域主要提供交易服務(wù),交易實(shí)時(shí)數(shù)據(jù)存放在互聯(lián)網(wǎng)區(qū)的交易數(shù)據(jù)庫(kù); 內(nèi)網(wǎng)區(qū)主要提供后臺(tái)管理及控制服務(wù),管理數(shù)據(jù)存放到后臺(tái)管理數(shù)據(jù)庫(kù).

在向云平臺(tái)遷移之前,SA和IA區(qū)是通過(guò)防火墻實(shí)現(xiàn)邏輯隔離,前后臺(tái)可以通過(guò)映射方式訪問(wèn).云平臺(tái)使用“安全隔離網(wǎng)閘”進(jìn)行隔離,前后臺(tái)區(qū)域的數(shù)據(jù)鏈路不是實(shí)時(shí)連通的,SA-IA數(shù)據(jù)交換模式上采用半連接式的文件交換形式,這種方式同一時(shí)刻只允許一個(gè)方向的訪問(wèn).這種數(shù)據(jù)交換方式,在性能方面顯然是存在短板的,因?yàn)樾枰獱奚鼘?shí)時(shí)性,而交易過(guò)程中的一些管理控制信息,是需要實(shí)時(shí)傳送到交易服務(wù)器上的.

為在保證安全的前提下實(shí)現(xiàn)數(shù)據(jù)的高速交換,本文把交易系統(tǒng)的數(shù)據(jù)流進(jìn)行了進(jìn)一步的拆分,劃分交易數(shù)據(jù)、控制數(shù)據(jù)、管理數(shù)據(jù)3部分.交易數(shù)據(jù)的內(nèi)容和遷移前相似; 而遷移前的后臺(tái)管理數(shù)據(jù)拆分為控制數(shù)據(jù)和管理數(shù)據(jù).管理數(shù)據(jù)直接進(jìn)入管理后臺(tái),而控制數(shù)據(jù)通過(guò)開(kāi)發(fā)新的控制程序直接進(jìn)入到交易前端.SA-IA的數(shù)據(jù)交換依托于文件交換結(jié)合SA-IA數(shù)據(jù)交換模塊進(jìn)行,云平臺(tái)環(huán)境下本系統(tǒng)結(jié)構(gòu)見(jiàn)圖3.

圖3 數(shù)據(jù)分流設(shè)計(jì)

傳統(tǒng)交易系統(tǒng)由資源監(jiān)控程序、資源池、線程監(jiān)控程序、線程池、同步監(jiān)控程序、同步程序、消息池等7部分組成[11],見(jiàn)圖4.

圖4 傳統(tǒng)交易系統(tǒng)內(nèi)核結(jié)構(gòu)

云服務(wù)器依托云平臺(tái)的虛擬化技術(shù),對(duì)外表現(xiàn)出很高的穩(wěn)定性,其通過(guò)虛擬化管理策略能輕松的實(shí)現(xiàn)故障轉(zhuǎn)移,然而正式這種自動(dòng)化的故障轉(zhuǎn)移機(jī)制,讓交易系統(tǒng)顯得有些水土不服.主要是因?yàn)榻灰紫到y(tǒng)有自身的交易引擎,這個(gè)交易引擎是基于數(shù)據(jù)的池化技術(shù)實(shí)現(xiàn)的.云服務(wù)器自動(dòng)故障轉(zhuǎn)移后,交易系統(tǒng)引擎中的實(shí)時(shí)數(shù)據(jù)并不能實(shí)時(shí)轉(zhuǎn)移到新的云服務(wù)器中.因此在交易系統(tǒng)中增加交易接管機(jī)制來(lái)適應(yīng)云平臺(tái)的這種故障轉(zhuǎn)移,一方面當(dāng)云服務(wù)器進(jìn)行自動(dòng)故障轉(zhuǎn)移時(shí),將交易引擎的數(shù)據(jù)進(jìn)行同步轉(zhuǎn)移,另一方面在引擎運(yùn)行期間對(duì)交易系統(tǒng)中的狀態(tài)進(jìn)行監(jiān)控,對(duì)各資源池、消息池、線程池等進(jìn)行清理凈化,見(jiàn)圖5.

圖5 云平臺(tái)下的交易系統(tǒng)內(nèi)核引擎結(jié)構(gòu)

同時(shí)為提高系統(tǒng)性能和穩(wěn)定性,引入資源歸檔程序、同步控制等模塊,這些模塊設(shè)計(jì)和算法相對(duì)簡(jiǎn)單,文中就不在贅述.

3 主要算法

本節(jié)分別介紹處理流程中一些重要過(guò)程的主要內(nèi)容,并給出具體算法的主要步驟.

3.1 SA-IA數(shù)據(jù)交換算法

SA-IA數(shù)據(jù)交換采用數(shù)據(jù)“不落地”方式進(jìn)行,即將需要交換的數(shù)據(jù)以哈希表的方式放入交換子系統(tǒng)緩存,需要交換時(shí)直接從緩存讀取并進(jìn)行交換,交換模塊簡(jiǎn)稱DESS.

DESS模塊分為: 前臺(tái)交換接口DE_SI、 前臺(tái)交換模塊DE_SM、 內(nèi)網(wǎng)交換接口DE_II、內(nèi)網(wǎng)交換模塊DE_IM四部分.

DE_SM模塊主要功能包括: 1) 接收前臺(tái)交易系統(tǒng)發(fā)來(lái)需要交換的數(shù)據(jù)DE,并放入哈希表HT_0101,供DE_IM讀取; 2) 將內(nèi)網(wǎng)區(qū)發(fā)來(lái)的需要交換的數(shù)據(jù)接收到HT0102,并進(jìn)行業(yè)務(wù)加工處理.過(guò)程見(jiàn)算法1.

DE_IM模塊主要功能: 一是接收后臺(tái)管理系統(tǒng)發(fā)來(lái)的數(shù)據(jù)并放入哈希表HT_0201,供DE_SM讀取; 將后臺(tái)發(fā)來(lái)的需要交換的數(shù)據(jù)接收到HT0202并進(jìn)行業(yè)務(wù)加工處理.

為保證數(shù)據(jù)交換的同步性和性能,每條交換數(shù)據(jù)DE 設(shè)置一個(gè)狀態(tài)字 S 和一個(gè)唯一值 K,DE={K,S,D},狀態(tài)S記錄數(shù)據(jù)交換結(jié)果,D是需要交換的數(shù)據(jù).

DE_IM模塊的過(guò)程同DE_SM類似,文中就不再贅述.

算法1.DE_SM數(shù)據(jù)交換算法Input: DE Output: HT0101,HT0102 While DE in SA BUFFER add DE to HT0101 End while HT0102 ← HT0201//accept HT0201 from Intranet to HT0102 Foreach DE in HT0102 Dealing DE End foreach Return TH_0101 HT_0102

3.2 交易接管和引擎凈化

云平臺(tái)的故障轉(zhuǎn)移、接管,為系統(tǒng)提供了更高的可用性.交易系統(tǒng)采用負(fù)載均衡集群模式部署,交易業(yè)務(wù)被按一定算法部署在不同的服務(wù)器上,而相同業(yè)務(wù)的交易由至少2臺(tái)服務(wù)器以互為負(fù)載均衡的方式承擔(dān),如圖6所示.在圖中,A為B的負(fù)載服務(wù)器,B為A的負(fù)載服務(wù)器,并提供一定數(shù)量的備用機(jī).以兩臺(tái)服務(wù)器為例,兩臺(tái)服務(wù)器的HTTP請(qǐng)求的會(huì)話,交易內(nèi)核數(shù)據(jù)是實(shí)時(shí)同步的,只要有其中一臺(tái)正常運(yùn)行,系統(tǒng)就能正常使用.但是,當(dāng)負(fù)載中的一臺(tái)服務(wù)器出現(xiàn)故障后,采用一臺(tái)服務(wù)器提供交易只能作為過(guò)渡策略,必須研究可行的交易接管方法,保證系統(tǒng)的穩(wěn)定性和及時(shí)響應(yīng).主要過(guò)程包括: 實(shí)時(shí)負(fù)載檢測(cè)、交易同步、自動(dòng)交易接管、交易引擎自動(dòng)凈化等.通過(guò)增加這些處理過(guò)程,實(shí)現(xiàn)故障交易主機(jī)自動(dòng)接管,并提高了交易引擎的性能和穩(wěn)定性.

負(fù)載檢測(cè)模塊: 查詢交易主機(jī)配置信息表BASIT,獲取與之對(duì)應(yīng)的負(fù)載主機(jī)信息.主服務(wù)器發(fā)送同步檢查消息,查看負(fù)載主機(jī)是否正常運(yùn)行,如果正常運(yùn)行,標(biāo)記為可用狀態(tài),如果未正常運(yùn)行,標(biāo)記為不可用狀態(tài).

圖6 負(fù)載交易模式

優(yōu)化后的同步模塊: 進(jìn)行同步時(shí),先檢測(cè)負(fù)載主機(jī)狀態(tài),如果可用,則進(jìn)行信息同步,否則終止同步,并監(jiān)聽(tīng)負(fù)載主機(jī)可用狀態(tài),如果連續(xù)多次檢測(cè)負(fù)載機(jī)不可用的,向備用機(jī)發(fā)起接管指令.當(dāng)新的負(fù)載主機(jī)被啟用或原負(fù)載主機(jī)恢復(fù)正常,則重新發(fā)起同步,見(jiàn)算法2.

算法2.交易同步算法While (true)Foreach res in synQueue Foreach server in servers Send res to server and return synresult If(!synresult)Add res to synQueue End If End Foreach End foreach End while Returns

交易接管模塊: 當(dāng)負(fù)載主機(jī)發(fā)生異常且在設(shè)定的時(shí)間內(nèi)沒(méi)有正?；謴?fù)時(shí),新的主機(jī)被啟用并接管故障主機(jī)的交易.當(dāng)主機(jī)向負(fù)載機(jī)同步失敗后,向負(fù)載機(jī)發(fā)起檢測(cè)信息,如果收到的信息異常,重復(fù)發(fā)生檢測(cè)信息,當(dāng)進(jìn)行過(guò)N次檢測(cè)后異常的,由負(fù)載主機(jī)向備用機(jī)發(fā)起交易接管指令.備用機(jī)接受到接管指令后,進(jìn)行交易引擎初始化,并向當(dāng)前的交易主機(jī)發(fā)起會(huì)話同步,內(nèi)核同步請(qǐng)求,最后對(duì)請(qǐng)求結(jié)果進(jìn)行校驗(yàn)和處理,同步成功后,將接管結(jié)果信息通知交易主機(jī),雙方確認(rèn)后,新的負(fù)載機(jī)和交易主機(jī)又互為負(fù)載交易主機(jī),接管示意見(jiàn)圖7.圖中發(fā)生故障的交易服務(wù)器是B服務(wù)器,為方便描述,將A服務(wù)器稱為交易主機(jī),簡(jiǎn)稱MS,B服務(wù)器成為負(fù)載機(jī),簡(jiǎn)稱BS,C備用機(jī)稱為接管服務(wù)器,簡(jiǎn)稱SPS.接管過(guò)程主要包括兩部分: 1) 算法 3 所示的異常檢測(cè)及備用機(jī)啟動(dòng); 2) 算法4所示的備用機(jī)進(jìn)行交易接管.

圖7 交易接管示意

交易引擎自動(dòng)凈化模塊: 該模塊的功能是檢測(cè)交易系統(tǒng)內(nèi)核狀態(tài),釋放交易資源,重置異常線程.設(shè)計(jì)目的是為交易系統(tǒng)提供一種自動(dòng)凈化機(jī)制,保證交易系統(tǒng)資源的高可用性,部分過(guò)程見(jiàn)算法5.

?

?

算法 5.交易引擎自動(dòng)凈化算法While (true)Foreach thread in thread pool If(thread status is exception)add new_thread to pool add task to new_thread release thread End if End Foreach Foreach resource pool If resource has terminate Remove resource from pool Else if resource status exception Get new_resource from database Add new_resource to pool End Foreach End While…Returns

3.3 B/S數(shù)據(jù)交互優(yōu)化

B/S數(shù)據(jù)交互采用成熟的AJAX請(qǐng)求方式,以降低每次請(qǐng)求及應(yīng)答的數(shù)據(jù)量,并根據(jù)具體的業(yè)務(wù)特點(diǎn)進(jìn)行了進(jìn)一步的優(yōu)化.以交易時(shí)間為例,在交易過(guò)程中,為了保證競(jìng)買人實(shí)時(shí)看到服務(wù)器時(shí)間且競(jìng)買人看到的服務(wù)器時(shí)間不至于“跳秒”,客戶端一般會(huì)在每隔不到1 s(本例500 ms)的時(shí)間就向服務(wù)器端發(fā)送1次獲取服務(wù)器時(shí)間的請(qǐng)求.當(dāng)參與的競(jìng)買人較多時(shí),系統(tǒng)需要接收大量的類似請(qǐng)求并做出應(yīng)答,給服務(wù)器帶來(lái)很大的負(fù)載壓力.為解決這一問(wèn)題,本文提出“一次獲取,多次使用”的方式進(jìn)行優(yōu)化.

具體操作是,以向服務(wù)器請(qǐng)求獲取時(shí)間結(jié)合瀏覽器計(jì)算的方法,來(lái)降低向服務(wù)器請(qǐng)求時(shí)間的頻次,例如每隔5分鐘向服務(wù)器請(qǐng)求一次時(shí)間服務(wù),請(qǐng)求成功后5分鐘內(nèi)便不再向服務(wù)器發(fā)起服務(wù)器時(shí)間獲取請(qǐng)求,而是在瀏覽器端用計(jì)時(shí)器替代.5分鐘后再次向服務(wù)器端獲取服務(wù)器時(shí)間,如此反復(fù)進(jìn)行,見(jiàn)算法6.

?

Else New Time += 1 End If End While returns New Time

4 實(shí)驗(yàn)及效果

按照本文的設(shè)計(jì)方法對(duì)系統(tǒng)進(jìn)行優(yōu)化后分別在江西、重慶等地將系統(tǒng)遷移至云平臺(tái),并進(jìn)行了測(cè)試和生產(chǎn)運(yùn)行.測(cè)試及運(yùn)行過(guò)程中重點(diǎn)對(duì)SA-IA數(shù)據(jù)交換可靠性,交易接管,交易引擎自動(dòng)凈化,B/S 數(shù)據(jù)交換優(yōu)化等幾個(gè)方面進(jìn)行了測(cè)試和對(duì)比統(tǒng)計(jì)分析.實(shí)驗(yàn)數(shù)據(jù)和實(shí)際運(yùn)行效果表明,優(yōu)化的系統(tǒng)在性能,安全性等方面都有不同程度的提高,采用新架構(gòu)的系統(tǒng)能夠方便的向云平臺(tái)進(jìn)行移植.

4.1 實(shí)驗(yàn)設(shè)計(jì)

系統(tǒng)采用Java語(yǔ)言開(kāi)發(fā),中間件采用Weblogic,數(shù)據(jù)庫(kù)采用Oracle.單元測(cè)試工具為JUnit,壓力測(cè)試工具使用 Load Runner,見(jiàn)表1.

4.2 結(jié)果分析

交易接管方面: 對(duì)交易自動(dòng)接管進(jìn)行5個(gè)批次,每個(gè)批次共進(jìn)行100次接管實(shí)驗(yàn)的測(cè)試,測(cè)試的主要指標(biāo)是接管的成功率,接管耗時(shí).通過(guò)測(cè)試,系統(tǒng)的自動(dòng)接管成功率是100%,接管耗時(shí)平均約為22 s,見(jiàn)表2.

表1 系統(tǒng)測(cè)試及運(yùn)行工具

表2 自動(dòng)接管測(cè)試情況統(tǒng)計(jì)表

交易引擎自動(dòng)凈化機(jī)制方面: 隨著交易時(shí)間的推移,引入交易引擎自動(dòng)凈化機(jī)制前的交易系統(tǒng)的連接數(shù)、JVM內(nèi)存、線程等資源的可用情況會(huì)出現(xiàn)連續(xù)下降.引入后系統(tǒng)把即將進(jìn)行的交易資源預(yù)裝入至交易引擎,交易結(jié)束后將其移除,并實(shí)時(shí)對(duì)交易引擎進(jìn)行監(jiān)控,自動(dòng)重置出現(xiàn)異常的線程、交易資源等.引入交易自動(dòng)凈化機(jī)制后,交易系統(tǒng)變得更加的穩(wěn)定了,也能獲得更高的性能.采用自動(dòng)凈化之前和之后生產(chǎn)環(huán)境各半年的隨機(jī)采樣數(shù)據(jù)進(jìn)行對(duì)比分析,見(jiàn)圖8和圖9.可以看出,引入自動(dòng)凈化機(jī)制后,系統(tǒng)可用資源并不會(huì)隨著交易的日積月累發(fā)生大幅減少.

圖8 無(wú)凈化機(jī)制系統(tǒng)的資源可用比變化情況

圖9 自動(dòng)凈化后系統(tǒng)的資源可用比變化情況

B/S數(shù)據(jù)交互優(yōu)化方面: 通過(guò)對(duì)服務(wù)器時(shí)間獲取、資源信息獲取等B/S數(shù)據(jù)交互優(yōu)化后,相同交易情況下,單臺(tái)服務(wù)器負(fù)載壓力有了明顯減輕.為驗(yàn)證優(yōu)化結(jié)果,采用 HP load runner對(duì)優(yōu)化前后的訪問(wèn)情況進(jìn)行4個(gè)批次的對(duì)比測(cè)試分析,V-User數(shù)量分別為50、500、1000、2000,思考時(shí)間為 30 s,每個(gè) V-User報(bào)價(jià)總數(shù)為100人次.

通過(guò)對(duì)服務(wù)器訪問(wèn)量進(jìn)行統(tǒng)計(jì),見(jiàn)表3.可以看出,在相同交易量情況下,優(yōu)化后服務(wù)的訪問(wèn)量較優(yōu)化前下降了約67.5%,主要是因?yàn)樵L問(wèn)方式優(yōu)化后,降低了向服務(wù)器的請(qǐng)求頻次,使得在服務(wù)器性能相當(dāng)?shù)那闆r下,單臺(tái)服務(wù)器能承擔(dān)更多的交易任務(wù).

表3 B/S 交互優(yōu)化前后服務(wù)器訪問(wèn)量對(duì)比

5 結(jié)束語(yǔ)

得益于云平臺(tái)的成本節(jié)約、資源共享便利性等方面的優(yōu)勢(shì),目前越來(lái)越多的傳統(tǒng)應(yīng)用正在或即將向云平臺(tái)遷移.而傳統(tǒng)的應(yīng)用系統(tǒng)由于其業(yè)務(wù)各自差異較大,部署方式、數(shù)據(jù)交換方式、訪問(wèn)方式等都各有其自身特點(diǎn).如何高效地進(jìn)行應(yīng)用遷移; 如何保證系統(tǒng)遷移后的例如性能、穩(wěn)定性、安全性不貶值,都需要在應(yīng)用遷移前進(jìn)行認(rèn)真的思考研究.本文采用以規(guī)劃、執(zhí)行、評(píng)估為核心遷移過(guò)程框架,結(jié)合系統(tǒng)自身特點(diǎn),制定出了合適了解決框架,并設(shè)計(jì)了主要的算法,并進(jìn)行了實(shí)現(xiàn).最后分別在江西、重慶等地進(jìn)行了實(shí)地測(cè)試和生產(chǎn)運(yùn)行,實(shí)踐表明,遷移后系統(tǒng)運(yùn)行穩(wěn)定,性能表現(xiàn)出色.這種遷移方法,可以為已有行業(yè)應(yīng)用系統(tǒng)向云平臺(tái)遷移提供參考,例如國(guó)土、公安、城市規(guī)劃等部門.

參考文獻(xiàn)

1張靚,范冰冰,鄭偉平.云平臺(tái)應(yīng)用系統(tǒng)遷移方法的研究.計(jì)算機(jī)科學(xué),2013,40(6A): 271–275.

2Andrade PRM,Araújo RG,Filho JC,et al.Improving business by migrating applications to the cloud using cloudstep.Proceedings of the 29th International Conference on Advanced Information Networking and Applications Workshops.Gwangiu,South Korea.2015.77–82.

3García-Galán J,Trinidad P,Rana OF,et al.Automated configuration support for infrastructure migration to the cloud.Future Generation Computer Systems,2016,(55):200–212.[doi: 10.1016/j.future.2015.03.006]

4Yousif M.Migrating applications to the cloud.IEEE Cloud Computing,2016,3(2): 4–5.[doi: 10.1109/MCC.2016.42]

5Dhuria S,Gupta A,Singla RK.Migrating applications to the cloud: Issues and challenges.International Journal of Advanced Research in Computer Science and Software Engineering,2015,5(6): 958–961.

6Scandurra P,Psaila G,Capilla R,et al.Challenges and assessment in migrating IT legacy applications to the cloud.Proceedings of the 9th Maintenance and Evolution of Service-Oriented and Cloud-Based Environments.Bremen,Germany.2015.7–14.

7Tankovic N,Grbac TG,Truong HL,et al.Transforming vertical Web applications into elastic cloud applications.Proceedings of 2015 IEEE International Conference on Cloud Engineering.Tempe,AZ,USA.2015.135–144.

8Jamshidi P,Ahmad A,Pahl C.Cloud migration research: A systematic review.IEEE Transactions on Cloud Computing,2014,1(2): 142–157.

9Gholami MF,Daneshgar F,Low G,et al.Cloud migration process-A survey,evaluation framework,and open challenges.Journal of Systems and Software,2016,(120):31–69.[doi: 10.1016/j.jss.2016.06.068]

10Hwang J,Bai K,Tacci M,et al.Automation and orchestration framework for large-scale enterprise cloud migration.IBM Journal of Research and Development,2016,60(2-3): 1:1–1:12.[doi: 10.1147/JRD.2015.2511810]

11趙俊三,丁強(qiáng)龍,陳國(guó)泉.國(guó)土資源網(wǎng)上交易系統(tǒng)內(nèi)核優(yōu)化設(shè)計(jì)研究.昆明理工大學(xué)學(xué)報(bào) (自然科學(xué)版),2015,40(1):29–34.