國土資源網上交易系統云平臺遷移技術實踐①

丁強龍,葉惠珠

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

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

1 引言

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

文獻[8]總結了當前云平臺遷移的研究內容,并提取了核心遷移過程,簡稱Cloud-RMM,包括規劃、執行、評估、橫切關注點等4個方面.

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

2) 執行: 代碼修改,體系結構提取,數據提取、轉換、同步問題等.

3) 評估: 系統在云平臺的部署,測試,驗證等.

4) 橫切關注點: 包括管理、安全、培訓,評估,組織變革,多租戶[8]等6個層面的內容.

文獻[9] 整合現有文獻的過程模型,提出了一個通用的參考方法,同時指出,一個固定遷移方法不適用于所有給定的遷移場景.

文獻[10]指出當前應用基礎設施的異構性、復雜,使其遷移過程具有挑戰性.基于IBM業務流程管理(BPM)的遷移技術與預遷移分析,其提出大型應用的云遷移云自動化與協調框架.

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

針對上述存在的問題,本例中的系統遷移,參照圖1所示的核心過程并結合國土資源網上交易系統特點,對其系統內核等進行了云平臺適應性調整,制定了一套遷移方法保證現有系統的穩定性、實時性、高并發性不受影響的解決方案.遷移過程中設計新的數據分流方法,前后臺數據的交換模塊,使遷移后的系統安全性有了較大提高,并解決了云服務器故障轉移后的交易接管問題.

圖1 Cloud-RMM

系統在重慶、江西等地進行了測試和實際運行,其結果表明,以上設計具有可行性,調整后的系統能較好的適應云平臺環境,而且更加安全、穩定.這種方法可以為公安,國土、城市規劃等部門的現有應用系統云遷移提供參考.

2 結構設計

本節介紹基于云平臺的國土資源網上交易系統結構設計.

為了解決云平臺的數據安全問題,將云平臺劃分為兩個大的區域,一個是互聯網區域,另外一個是內網區域,內網和互聯網區域通過“安全隔離網閘”進行物理隔離,見圖2.相比起內外網人工數據擺渡方式,這種設計方法,在保證安全性的前提下,為內外網的數據交換提供了自動完成的可能.

圖2 交易系統云平臺部署示意

為了盡可能的保證數據的安全性,將后臺管理與前臺交易分別部署在內網區(SA)和互聯網區(IA).互聯網區域主要提供交易服務,交易實時數據存放在互聯網區的交易數據庫; 內網區主要提供后臺管理及控制服務,管理數據存放到后臺管理數據庫.

在向云平臺遷移之前,SA和IA區是通過防火墻實現邏輯隔離,前后臺可以通過映射方式訪問.云平臺使用“安全隔離網閘”進行隔離,前后臺區域的數據鏈路不是實時連通的,SA-IA數據交換模式上采用半連接式的文件交換形式,這種方式同一時刻只允許一個方向的訪問.這種數據交換方式,在性能方面顯然是存在短板的,因為需要犧牲實時性,而交易過程中的一些管理控制信息,是需要實時傳送到交易服務器上的.

為在保證安全的前提下實現數據的高速交換,本文把交易系統的數據流進行了進一步的拆分,劃分交易數據、控制數據、管理數據3部分.交易數據的內容和遷移前相似; 而遷移前的后臺管理數據拆分為控制數據和管理數據.管理數據直接進入管理后臺,而控制數據通過開發新的控制程序直接進入到交易前端.SA-IA的數據交換依托于文件交換結合SA-IA數據交換模塊進行,云平臺環境下本系統結構見圖3.

圖3 數據分流設計

傳統交易系統由資源監控程序、資源池、線程監控程序、線程池、同步監控程序、同步程序、消息池等7部分組成[11],見圖4.

圖4 傳統交易系統內核結構

云服務器依托云平臺的虛擬化技術,對外表現出很高的穩定性,其通過虛擬化管理策略能輕松的實現故障轉移,然而正式這種自動化的故障轉移機制,讓交易系統顯得有些水土不服.主要是因為交易系統有自身的交易引擎,這個交易引擎是基于數據的池化技術實現的.云服務器自動故障轉移后,交易系統引擎中的實時數據并不能實時轉移到新的云服務器中.因此在交易系統中增加交易接管機制來適應云平臺的這種故障轉移,一方面當云服務器進行自動故障轉移時,將交易引擎的數據進行同步轉移,另一方面在引擎運行期間對交易系統中的狀態進行監控,對各資源池、消息池、線程池等進行清理凈化,見圖5.

圖5 云平臺下的交易系統內核引擎結構

同時為提高系統性能和穩定性,引入資源歸檔程序、同步控制等模塊,這些模塊設計和算法相對簡單,文中就不在贅述.

3 主要算法

本節分別介紹處理流程中一些重要過程的主要內容,并給出具體算法的主要步驟.

3.1 SA-IA數據交換算法

SA-IA數據交換采用數據“不落地”方式進行,即將需要交換的數據以哈希表的方式放入交換子系統緩存,需要交換時直接從緩存讀取并進行交換,交換模塊簡稱DESS.

DESS模塊分為: 前臺交換接口DE_SI、 前臺交換模塊DE_SM、 內網交換接口DE_II、內網交換模塊DE_IM四部分.

DE_SM模塊主要功能包括: 1) 接收前臺交易系統發來需要交換的數據DE,并放入哈希表HT_0101,供DE_IM讀取; 2) 將內網區發來的需要交換的數據接收到HT0102,并進行業務加工處理.過程見算法1.

DE_IM模塊主要功能: 一是接收后臺管理系統發來的數據并放入哈希表HT_0201,供DE_SM讀取; 將后臺發來的需要交換的數據接收到HT0202并進行業務加工處理.

為保證數據交換的同步性和性能,每條交換數據DE 設置一個狀態字 S 和一個唯一值 K,DE={K,S,D},狀態S記錄數據交換結果,D是需要交換的數據.

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

算法1.DE_SM數據交換算法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 交易接管和引擎凈化

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

負載檢測模塊: 查詢交易主機配置信息表BASIT,獲取與之對應的負載主機信息.主服務器發送同步檢查消息,查看負載主機是否正常運行,如果正常運行,標記為可用狀態,如果未正常運行,標記為不可用狀態.

圖6 負載交易模式

優化后的同步模塊: 進行同步時,先檢測負載主機狀態,如果可用,則進行信息同步,否則終止同步,并監聽負載主機可用狀態,如果連續多次檢測負載機不可用的,向備用機發起接管指令.當新的負載主機被啟用或原負載主機恢復正常,則重新發起同步,見算法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

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

圖7 交易接管示意

交易引擎自動凈化模塊: 該模塊的功能是檢測交易系統內核狀態,釋放交易資源,重置異常線程.設計目的是為交易系統提供一種自動凈化機制,保證交易系統資源的高可用性,部分過程見算法5.

?

?

算法 5.交易引擎自動凈化算法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數據交互優化

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

具體操作是,以向服務器請求獲取時間結合瀏覽器計算的方法,來降低向服務器請求時間的頻次,例如每隔5分鐘向服務器請求一次時間服務,請求成功后5分鐘內便不再向服務器發起服務器時間獲取請求,而是在瀏覽器端用計時器替代.5分鐘后再次向服務器端獲取服務器時間,如此反復進行,見算法6.

?

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

4 實驗及效果

按照本文的設計方法對系統進行優化后分別在江西、重慶等地將系統遷移至云平臺,并進行了測試和生產運行.測試及運行過程中重點對SA-IA數據交換可靠性,交易接管,交易引擎自動凈化,B/S 數據交換優化等幾個方面進行了測試和對比統計分析.實驗數據和實際運行效果表明,優化的系統在性能,安全性等方面都有不同程度的提高,采用新架構的系統能夠方便的向云平臺進行移植.

4.1 實驗設計

系統采用Java語言開發,中間件采用Weblogic,數據庫采用Oracle.單元測試工具為JUnit,壓力測試工具使用 Load Runner,見表1.

4.2 結果分析

交易接管方面: 對交易自動接管進行5個批次,每個批次共進行100次接管實驗的測試,測試的主要指標是接管的成功率,接管耗時.通過測試,系統的自動接管成功率是100%,接管耗時平均約為22 s,見表2.

表1 系統測試及運行工具

表2 自動接管測試情況統計表

交易引擎自動凈化機制方面: 隨著交易時間的推移,引入交易引擎自動凈化機制前的交易系統的連接數、JVM內存、線程等資源的可用情況會出現連續下降.引入后系統把即將進行的交易資源預裝入至交易引擎,交易結束后將其移除,并實時對交易引擎進行監控,自動重置出現異常的線程、交易資源等.引入交易自動凈化機制后,交易系統變得更加的穩定了,也能獲得更高的性能.采用自動凈化之前和之后生產環境各半年的隨機采樣數據進行對比分析,見圖8和圖9.可以看出,引入自動凈化機制后,系統可用資源并不會隨著交易的日積月累發生大幅減少.

圖8 無凈化機制系統的資源可用比變化情況

圖9 自動凈化后系統的資源可用比變化情況

B/S數據交互優化方面: 通過對服務器時間獲取、資源信息獲取等B/S數據交互優化后,相同交易情況下,單臺服務器負載壓力有了明顯減輕.為驗證優化結果,采用 HP load runner對優化前后的訪問情況進行4個批次的對比測試分析,V-User數量分別為50、500、1000、2000,思考時間為 30 s,每個 V-User報價總數為100人次.

通過對服務器訪問量進行統計,見表3.可以看出,在相同交易量情況下,優化后服務的訪問量較優化前下降了約67.5%,主要是因為訪問方式優化后,降低了向服務器的請求頻次,使得在服務器性能相當的情況下,單臺服務器能承擔更多的交易任務.

表3 B/S 交互優化前后服務器訪問量對比

5 結束語

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

參考文獻

1張靚,范冰冰,鄭偉平.云平臺應用系統遷移方法的研究.計算機科學,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趙俊三,丁強龍,陳國泉.國土資源網上交易系統內核優化設計研究.昆明理工大學學報 (自然科學版),2015,40(1):29–34.