基于云計算框架的OLTP類業(yè)務(wù)安全可控模型的一般性探究

李 萌

(國家藥品監(jiān)督管理局信息中心 北京 100044)

0 引 言

當(dāng)前，新一輪信息革命正引領(lǐng)人類從工業(yè)文明加速向信息文明轉(zhuǎn)型，全面影響和重塑經(jīng)濟運行、社會發(fā)展、國家治理、人民生活等各個領(lǐng)域，政務(wù)信息化已成為通往現(xiàn)代治理之路必不可少的重要依托。全面加快政務(wù)信息化創(chuàng)新發(fā)展，已成為推進國家治理體系和治理能力現(xiàn)代化建設(shè)的重要手段，對于深化行政體制改革，建設(shè)法治政府、創(chuàng)新政府、廉潔政府和服務(wù)型政府具有重要意義。伴隨著信息技術(shù)和互聯(lián)網(wǎng)的飛速發(fā)展，政府采用信息技術(shù)調(diào)整行政管理的形態(tài)和方式，為社會和公眾提供便捷有效和高質(zhì)量的服務(wù)是世界趨勢，政務(wù)信息化已成為時代潮流。國家也已經(jīng)把信息化上升為國家戰(zhàn)略[1]。

2020年3月，中共中央政治局常務(wù)委員會召開會議提出，加快5G網(wǎng)絡(luò)、數(shù)據(jù)中心等新型基礎(chǔ)設(shè)施建設(shè)進度?！靶禄ā眲荼貙⑼七M5G、AI、大數(shù)據(jù)、云計算等業(yè)務(wù)飛速發(fā)展,未來數(shù)據(jù)中心網(wǎng)絡(luò)需要在無損、智慧、開源等方面全面提升能力,為新一代業(yè)務(wù)應(yīng)用保駕護航[2]。在當(dāng)前的國際競爭格局下，知識產(chǎn)權(quán)自主可控十分重要，做不到這一點就一定會受制于人。習(xí)總書記在關(guān)于網(wǎng)信工作的系列講話之中，強調(diào)了不止一次“加快推進國產(chǎn)自主可控替代計劃，構(gòu)建安全可控的信息技術(shù)體系”。關(guān)于網(wǎng)絡(luò)安全信息化的一個重要指示，其中提到了要加快推進國產(chǎn)自主可控的替代計劃，就是國產(chǎn)的產(chǎn)品進入市場要有替代能力，要有個計劃去替代它，替代壟斷的外國產(chǎn)品。政務(wù)信息化系統(tǒng)有著數(shù)據(jù)敏感、關(guān)乎國計民生等重大事項，不管在硬件還是軟件部分都應(yīng)當(dāng)做好國產(chǎn)自主可控的替代[3]。

云計算不管是公有云還是私有云作為全新的資源服務(wù)模式起到舉足輕重的作用。在藥品監(jiān)管領(lǐng)域，由于種種原因，部分物理環(huán)境下部署的OLTP應(yīng)用系統(tǒng)，云化遷移的工作正在開展，但是遇到了許多問題[4]，物理環(huán)境和虛擬化環(huán)境的指標(biāo)評估不對稱導(dǎo)致P2V的業(yè)務(wù)架構(gòu)不合理、資源申請不合理、網(wǎng)絡(luò)設(shè)計不合理等系列問題，對整體工作量影響比較大。同時，在虛擬化環(huán)境下業(yè)務(wù)安全問題也是一個大的挑戰(zhàn)。在這個過程中，業(yè)內(nèi)其實并沒有一個成熟的參考模式和考量指標(biāo)[5]。尤其目前在我國加快推進國產(chǎn)自主可控替代的大環(huán)境下，這項工作的難度和復(fù)雜度又有提高。

1 OLTP業(yè)務(wù)系統(tǒng)分析

1.1 背景分析

對于OLTP業(yè)務(wù)系統(tǒng)，概念已經(jīng)非常清晰，即聯(lián)機事務(wù)處理系統(tǒng)(On-Line Transaction Processing)是一種以事務(wù)元作為數(shù)據(jù)處理的單位、人機交互的計算機應(yīng)用系統(tǒng)[6]。

在政府領(lǐng)域，存在大量的此類系統(tǒng)，比如國家藥品監(jiān)督管理局網(wǎng)站管理系統(tǒng)、總局統(tǒng)一行政準(zhǔn)入管理系統(tǒng)(互聯(lián)網(wǎng))、執(zhí)業(yè)藥師管理信息系統(tǒng)等，其最大的特點是由前臺、應(yīng)用、數(shù)據(jù)庫共同完成，其處理快慢以及處理程度取決于數(shù)據(jù)庫引擎、服務(wù)器、應(yīng)用引擎。

國家藥品監(jiān)督管理局信息中心承擔(dān)著云平臺建設(shè)的相關(guān)任務(wù)和職責(zé)，云平臺構(gòu)建完成后，各部門只需通過在虛擬的平臺上部署自己的應(yīng)用，而后端的平臺交給云計算中心處理，那將可以大大簡化用戶部署的煩瑣性和維護的復(fù)雜性，也提高資源的利用率，各部門無須獨立購買硬件和基礎(chǔ)軟件來部署獨立的應(yīng)用。各部門在部署應(yīng)用系統(tǒng)的云化架構(gòu)，需要平臺側(cè)配合來完成設(shè)計和部署?；诖耍疚脑O(shè)計相關(guān)云化模型的評估和探究。

1.2 維度分析

OLTP的云化一般考慮以下幾個維度。

維度1基礎(chǔ)信息分析。主要考慮因素如表1所示。

表1 基礎(chǔ)信息分析表

維度2業(yè)務(wù)負載分析。主要考慮因素如表2所示。

表2 業(yè)務(wù)負載分析表

維度3技術(shù)分析。主要考慮因素如表3所示。

表3 技術(shù)分析表

維度4風(fēng)險分析。主要考慮因素如表4所示。

表4 風(fēng)險分析表

維度5遷移價值分析。主要考慮因素如表5所示。

表5 價值分析表

經(jīng)驗總結(jié)看來，對以上5個維度指標(biāo)和因素的OLTP類業(yè)務(wù)適合云化，對于有特殊條件的業(yè)務(wù)系統(tǒng)應(yīng)該遵循以下原則。

1.3 特殊條件評估原則

有以下特殊條件的業(yè)務(wù)系統(tǒng)不建議云化處理，本文所描述云化的概念是指基礎(chǔ)硬件經(jīng)過hypervisor層資源管理調(diào)度的虛擬機或者提供的裸金屬物理機服務(wù)(Bare Metal Server，BMS)。

條件1：特殊硬件依賴，比如非云化的硬件密碼機、硬件網(wǎng)關(guān)類設(shè)備。

條件2：實時性要求特別高，比如實時數(shù)據(jù)采集類、直播視頻中流媒體轉(zhuǎn)發(fā)類服務(wù)。

條件3：大型數(shù)據(jù)庫，比如數(shù)據(jù)庫表數(shù)高于200、分布式數(shù)據(jù)庫、交易量高于1 000筆每秒、有復(fù)雜的數(shù)據(jù)庫邏輯、有存儲過程、有較強的約束條件。

條件4：部分一體機應(yīng)用。

2 云化評估核心模型的設(shè)計

2.1 云化構(gòu)造的一般描述

云化構(gòu)造的過程不是簡單地把物理環(huán)境的應(yīng)用系統(tǒng)按照資源1 ∶1搬遷到云平臺上，而是充分考慮到業(yè)務(wù)系統(tǒng)的訪問壓力、網(wǎng)絡(luò)帶寬、資源利用情況、運維管理、應(yīng)用開發(fā)語言、應(yīng)用所依賴的操作系統(tǒng)、中間件、數(shù)據(jù)庫等因素，重新設(shè)計云環(huán)境下的軟件和應(yīng)用架構(gòu)及網(wǎng)絡(luò)模型，重新考慮各類安全防護手段和策略，以滿足應(yīng)用系統(tǒng)的正常訪問和資源利用的最大化，降低固定資產(chǎn)和人力資源的投資。

2.2 核心模型的設(shè)計

根據(jù)經(jīng)驗，業(yè)務(wù)應(yīng)用在云計算環(huán)境下設(shè)計以下幾類模型。

Type 1：簡單模式。

本模式為簡單模式，總體特點是簡單業(yè)務(wù)架構(gòu)，單VPC，應(yīng)用架構(gòu)為三層架構(gòu)，分為Web層、應(yīng)用層和DB層。

每層中單獨劃分子網(wǎng)和子網(wǎng)掩碼，在不同的子網(wǎng)進行訪問時，考慮用VFW和安全組等方式進行南北向和東西向流量的防護。架構(gòu)如圖1所示。

圖1 Type 1模型

Type 2：中等模式1。

本模式為通用型應(yīng)用業(yè)務(wù)類，總體特點是業(yè)務(wù)架構(gòu)每層都采用VPC單獨劃分和隔離，應(yīng)用架構(gòu)為三層架構(gòu)，分為Web層、應(yīng)用層和DB層三大類VPC，每個VPC內(nèi)部根據(jù)不同的業(yè)務(wù)邏輯可以劃分多個子網(wǎng)網(wǎng)段。通常來講，在復(fù)雜的應(yīng)用系統(tǒng)中，應(yīng)用邏輯是由多個子系統(tǒng)或者子模塊來完成，相互之間有較強的交互關(guān)系和數(shù)據(jù)同步。不同的子系統(tǒng)或者子模塊用不同的子網(wǎng)網(wǎng)絡(luò)來承載，保證安全性，在后續(xù)彈性擴容的時候，也容易根據(jù)DHCP來合理規(guī)劃私網(wǎng)地址，確保子網(wǎng)空間的可用性和可規(guī)劃性。

VPC之間訪問和交互考慮用VFW來隔離，VFW和安全組方式進行南北向和東西向流量的防護。架構(gòu)如圖2所示。

圖2 Type 2模型

Type 3：中等模式2。

本模式為重載應(yīng)用業(yè)務(wù)類，總體特點是業(yè)務(wù)架構(gòu)每層都采用VPC單獨劃分和隔離，應(yīng)用架構(gòu)同樣為三層架構(gòu)，分為Web層、應(yīng)用層和DB層三大類VPC，每個VPC內(nèi)部根據(jù)不同的業(yè)務(wù)邏輯可以劃分多個子網(wǎng)網(wǎng)段。

與Type 2相類似的是，不同的子系統(tǒng)或者子模塊用不同的子網(wǎng)網(wǎng)絡(luò)來承載，保證安全性，在后續(xù)彈性擴容的時候，也容易根據(jù)DHCP來合理規(guī)劃私網(wǎng)地址，確保子網(wǎng)空間的可用性和可規(guī)劃性。

與Type 2不同的是，有些重載型業(yè)務(wù)應(yīng)用不適合用虛擬機來承載，因此考慮用裸金屬物理機，物理機和虛擬機的差別這里不再贅述。同時，隨著重載業(yè)務(wù)上云，這些業(yè)務(wù)系統(tǒng)的重要性也不言而喻，對虛擬機的高可靠要求也越來越高，對于一些核心應(yīng)用來說，采用HA的技術(shù)來保證虛擬機的高可靠，從而來保證業(yè)務(wù)系統(tǒng)的高可靠用性，滿足一定的SLA約束。

同樣地，VPC之間訪問和交互考慮用VFW來隔離，VFW和安全組方式進行南北向和東西向流量的防護，BMS作為一種資源的服務(wù)統(tǒng)一納管到云平臺，按照DCHP的模式來分配所需的子網(wǎng)空間和具體的IP地址。具體架構(gòu)如圖3所示。

圖3 type 3模型

Type 4：復(fù)雜模式。

本模式為非單DC復(fù)雜業(yè)務(wù)類，總體特點是業(yè)務(wù)通過不同的數(shù)據(jù)中心(DC)來保證業(yè)務(wù)的連續(xù)性。在某單個數(shù)據(jù)中心內(nèi)部，應(yīng)用架構(gòu)同樣為三層架構(gòu)，分為Web層、應(yīng)用層和DB層三大類VPC組，每個VPC內(nèi)部根據(jù)不同的業(yè)務(wù)邏輯可以劃分多個子網(wǎng)網(wǎng)段。

具體架構(gòu)如圖4所示。

圖4 type 4模型

在跨數(shù)據(jù)中心的鏈路中考慮3個層次的問題：(1) Web層，通過負載均衡設(shè)備來完成對于解析后的目的地址的分配，保證按照不同的區(qū)域來就近解析相關(guān)目的地址；(2) 應(yīng)用層，通過自身做應(yīng)用的集群，可以把應(yīng)用的狀態(tài)數(shù)據(jù)實時或者非實時地同步到對端數(shù)據(jù)中心，對端數(shù)據(jù)可以提供近實時的數(shù)據(jù)服務(wù)；(3) DB層，通過數(shù)據(jù)庫軟件的集群的復(fù)制功能，把數(shù)據(jù)庫數(shù)據(jù)同步到對端數(shù)據(jù)中心數(shù)據(jù)庫軟件中，這個過程需要底層網(wǎng)絡(luò)時延的保障，具體的時延要求要根據(jù)應(yīng)用系統(tǒng)的重要性和核心性進行設(shè)計。

3 基于國產(chǎn)CPU安全可控的軟件適配移植構(gòu)建過程

3.1 安全可控的認知

數(shù)字化進程的飛速發(fā)展和近十年互聯(lián)網(wǎng)產(chǎn)業(yè)的發(fā)展都清晰地驗證了一個事實，不同的產(chǎn)業(yè)階段對IT基礎(chǔ)架構(gòu)和計算能力提出不同的挑戰(zhàn)和要求。新應(yīng)用、新技術(shù)、新架構(gòu)是未來數(shù)字化轉(zhuǎn)型的關(guān)鍵，計算平臺的創(chuàng)新是數(shù)字化轉(zhuǎn)型的基石。

當(dāng)前，信息安全、自主可控也已上升為國家戰(zhàn)略，自主可控計算機是構(gòu)建自主可控信息系統(tǒng)的基礎(chǔ)。而芯片產(chǎn)業(yè)是計算機系統(tǒng)和整個信息產(chǎn)業(yè)的核心部件和基石，也是國家信息安全的最后一道屏障，芯片高度依賴進口使得整個國家安全受到嚴重威脅。

芯片的自主可控是整個信息產(chǎn)業(yè)自主可控的基礎(chǔ)，自主可控芯片將重塑ICT產(chǎn)業(yè)新格局，構(gòu)建平行計算平面[7]。目前，我國服務(wù)器芯片自主研發(fā)有以下幾個方向[8]：

Alpha架構(gòu):代表有申威。

ARM(Advanced RISC Machine)架構(gòu)：代表有華為、飛騰等。

MIPS架構(gòu)：代表有龍芯。

X86架構(gòu)：代表有海光、兆芯等。

Power架構(gòu)：代表有中晟宏芯。

3.2 業(yè)務(wù)安全可控的適配流程

本文以華為ARM架構(gòu)芯片鯤鵬920[9]為例來闡述特定的業(yè)務(wù)系統(tǒng)在進行安全可控的適配一般流程。流程如下：

Step1分析業(yè)務(wù)系統(tǒng)的軟件技術(shù)棧。

Step2確定如下指標(biāo)信息：

1) x86架構(gòu)的芯片/服務(wù)器；

2) 操作系統(tǒng)；

3) 操作系統(tǒng)相關(guān)驅(qū)動；

4) 編譯器；

5) JDK；

6) 軟件依賴組件；

7) 開源軟件；

8) 商用軟件；

9) 自研軟件。

Step3對于指標(biāo)的前8項，獲取到支持ARM架構(gòu)的軟件、硬件、相應(yīng)的版本號，若沒有對應(yīng)ARM版本，則考慮更換為相同功能的ARM對應(yīng)版本軟件；對于指標(biāo)9，執(zhí)行以下代碼修改適配流程。

Step4判斷自研軟件的計算機編程語言類型，如果是編譯型語言(如C、C++等)，轉(zhuǎn)向Step 6；如果是解釋型語言(如Java和Python等)，則繼續(xù)下一步動作。

Step5判斷是否存在編譯型類庫的情況，如果不存在相關(guān)類庫，則可以直接使用；否則做類庫的移植后，重新打包，轉(zhuǎn)向Step 9。

Step6判斷是否為Linux軟件，如果不是Linux軟件，則可能面臨極大的代碼改動量，并且有移植不成功的風(fēng)險；如果是Linux軟件，則繼續(xù)下一步動作。

Step7判斷是否存在x86的匯編代碼，如有，則統(tǒng)一替換成基于ARM的匯編代碼，繼續(xù)下一步動作。

Step8檢查是否存在代碼修改點，如有，則修改成基于ARM的版本；如沒有，則繼續(xù)下一步。

Step9重新編譯。

應(yīng)用業(yè)務(wù)系統(tǒng)基于國產(chǎn)化CPU指令集的適配性遷移是一項比較復(fù)雜的工程[10]，以上是遷移適配的一般性流程，同時要考慮到遷移工作量和所用人時等因素開展此項工作。

4 核心模型的網(wǎng)絡(luò)規(guī)劃構(gòu)建

云內(nèi)部網(wǎng)絡(luò)訪問是一個比較復(fù)雜的過程，涉及到安全防護和業(yè)務(wù)流量的設(shè)計，因此需要一個通用的網(wǎng)絡(luò)模型來規(guī)劃，防止出現(xiàn)業(yè)務(wù)網(wǎng)絡(luò)的規(guī)劃導(dǎo)致內(nèi)部網(wǎng)絡(luò)安全防護性較差。根據(jù)本文引出的云化業(yè)務(wù)模型，構(gòu)建的統(tǒng)一網(wǎng)絡(luò)模型如圖5所示。

圖5 統(tǒng)一網(wǎng)絡(luò)模型

其中，主要網(wǎng)絡(luò)流向有以下幾個方向，在設(shè)計網(wǎng)絡(luò)中，需要重點考慮：

網(wǎng)絡(luò)流向1：VPC內(nèi)部相同子網(wǎng)之間的二層訪問。通過安全組訪問，典型代表場景有Web集群服務(wù)之間的通信。

網(wǎng)絡(luò)流向2：VPC內(nèi)部不同子網(wǎng)之間的三層訪問。典型代表場景有Web集群服務(wù)與應(yīng)用各類邏輯之間的通信。

網(wǎng)絡(luò)流向3：不同VPC之間的三層訪問，通過VFW虛擬防火墻訪問，典型代表場景有Web集群服務(wù)或者應(yīng)用各類邏輯與DB集群服務(wù)之間的通信。

網(wǎng)絡(luò)流向4：虛擬機與物理設(shè)備之間的三層訪問。也屬于跨VPC之間的通信，通過VFW虛擬防火墻訪問，典型代表場景有Web集群服務(wù)或者應(yīng)用各類邏輯與第三方硬件或者軟件集群服務(wù)如認證網(wǎng)關(guān)等之間的通信。

網(wǎng)絡(luò)流向5：VPC虛擬機與第三方資源池之間的三層或者二層跨DC訪問。在三層場景下，通過接入路由器接入到云資源池，對于有Vlan網(wǎng)絡(luò)，配置明細路由；對于VXlan網(wǎng)絡(luò)，通過VPN的方式進入云網(wǎng)絡(luò)隧道，完成網(wǎng)絡(luò)路由的互通；在二層場景下，通過接入或者核心交換機，配置VXlan隧道，實現(xiàn)與VPC的二層互通通信。

網(wǎng)絡(luò)流向6：外部網(wǎng)絡(luò)的訪問。外部的訪問一般在業(yè)務(wù)平面較多，出口與云最外側(cè)防火墻互聯(lián)，實現(xiàn)外部網(wǎng)絡(luò)與云的業(yè)務(wù)VPC之間的訪問。

網(wǎng)絡(luò)流向7：專網(wǎng)網(wǎng)絡(luò)的訪問。專網(wǎng)部分一般分為業(yè)務(wù)流量和管理流量，在網(wǎng)絡(luò)對接上與云的專網(wǎng)網(wǎng)絡(luò)接入交換機對接，實現(xiàn)專網(wǎng)網(wǎng)絡(luò)流量的互通，管理流量經(jīng)由管理交換機實現(xiàn)對接。

5 云化實例分析

5.1 現(xiàn)狀描述和分析

某業(yè)務(wù)系統(tǒng)15臺x86架構(gòu)的物理機部署(Web和應(yīng)用層、DB層3層架構(gòu))，CPU使用率長期持續(xù)在5%以下，內(nèi)存使用率長期持續(xù)在10%以下，服務(wù)器操作系統(tǒng)為Linux Enterprise 6.4 64 bit，中間件為weblogic，開發(fā)語言為Java、Python，數(shù)據(jù)庫是MySQL。在業(yè)務(wù)訪問方面：每年特定時間段會出現(xiàn)業(yè)務(wù)訪問的高峰，并發(fā)峰值每秒約在4 000新建連接，業(yè)務(wù)訪問中有附件(標(biāo)準(zhǔn)圖片)的上傳和下載。

在業(yè)務(wù)出現(xiàn)訪問高峰時，系統(tǒng)經(jīng)常性出現(xiàn)癱瘓等，頁面響應(yīng)非常緩慢，響應(yīng)時間在8～10 s左右。通過持續(xù)觀察可以發(fā)現(xiàn)，某幾臺服務(wù)器CPU和內(nèi)存使用率在98%以上，歷史上多次臨時擴容服務(wù)器，但是未能解決該業(yè)務(wù)訪問問題。

故障出現(xiàn)時，某幾臺服務(wù)器的資源使用率出現(xiàn)較高情況，其他的大部分服務(wù)器使用率在較低水平，未出現(xiàn)其他異常情況。排除網(wǎng)絡(luò)攻擊后，可以初步得出結(jié)論：此系統(tǒng)整體架構(gòu)設(shè)計不合理，使得某個或者某幾個流程成為整個業(yè)務(wù)系統(tǒng)的瓶頸，可以調(diào)整軟件部署架構(gòu)來消除瓶頸。同時考慮國產(chǎn)化相關(guān)技術(shù)要求，重新設(shè)計云化軟件部署架構(gòu)。

5.2 技術(shù)評估和云化架構(gòu)設(shè)計

根據(jù)對業(yè)務(wù)系統(tǒng)的分析，本實例業(yè)務(wù)具備以下特點：

(1) 標(biāo)準(zhǔn)x86架構(gòu)。

(2) 無特殊綁定硬件。

(3) 實時性要求不是特別高。

(4) 業(yè)務(wù)不同時段負載波動特別大。

(5) 業(yè)務(wù)增長不確定較高。

(6) 沒有大型分布式數(shù)據(jù)庫。

(7) 沒有小型機應(yīng)用。

(8) 開發(fā)語言、中間件、數(shù)據(jù)庫、操作系統(tǒng)評估可以遷移。

根據(jù)本文前幾部分的評估論述，本業(yè)務(wù)系統(tǒng)適合部分云化，具備國產(chǎn)化適配的條件。

設(shè)計整體架構(gòu)如圖6所示。

圖6 業(yè)務(wù)總體架構(gòu)

架構(gòu)具體描述：

注：整體流量防護請參考2.2節(jié)核心模型的設(shè)計Type3網(wǎng)絡(luò)模型。以下僅描述本實例相關(guān)部分。

Web層：采用全虛擬化部署方案，設(shè)立VPC1，在內(nèi)部劃分兩個獨立子網(wǎng)，完成兩個前臺無狀態(tài)業(yè)務(wù)界面的資源承載，前端掛載軟件負載均衡服務(wù)，實現(xiàn)對訪問2個邏輯的七層負載分擔(dān)。同時設(shè)計自動彈性擴展服務(wù)，當(dāng)節(jié)點出現(xiàn)CPU高于60%或者內(nèi)存高于60%的時候會通過虛擬機鏡像自動拉起一定數(shù)量的虛擬機提供服務(wù)。

應(yīng)用層：采用全虛擬化部署方案，設(shè)立VPC2，在內(nèi)部劃分三個獨立子網(wǎng)，分別完成身份認證、接口和交換三個業(yè)務(wù)的資源承載，前端掛載軟件負載均衡服務(wù)，實現(xiàn)對訪問3個邏輯的七層負載分擔(dān)。同時設(shè)計自動彈性擴展服務(wù)，當(dāng)節(jié)點出現(xiàn)CPU高于60%或者內(nèi)存高于60%的時候會通過虛擬機鏡像自動拉起一定數(shù)量的虛擬機提供服務(wù)。

DB層：采用物理機部署方案，考慮到統(tǒng)一管理和運營資源，物理機采用BMS服務(wù)的資源納管方式。同時設(shè)立VPC3，在內(nèi)部劃分獨立子網(wǎng)。數(shù)據(jù)庫物理機采用軟件集群的方式部署，對外提供virtual-ip負載分擔(dān)和保證讀、寫一致性。也可以采用獨立物理機部署方案，以專線VPN的方式接入到與云平臺Vxlan網(wǎng)絡(luò)，實現(xiàn)與云的overlay3層路由網(wǎng)絡(luò)通信。

5.3 國產(chǎn)化適配設(shè)計

根據(jù)國產(chǎn)化適配流程和原則，進行以下適配和遷移：

開發(fā)語言：Java和Python類應(yīng)用系統(tǒng)參考本文論述的兩種語言的移植方法和流程。

中間件：由Weblogic適配為東方通中間件。

數(shù)據(jù)庫：由MySQL替換成Huawei GaussDB。

操作系統(tǒng)：由Linux Enterprise 6.4 64 bit適配為中標(biāo)麒麟操作系統(tǒng)。

云平臺：適配國產(chǎn)云平臺。

服務(wù)器：由x86架構(gòu)服務(wù)器適配成Huawei Taishan系列服務(wù)器。

5.4 改造效果

通過云化模型的技術(shù)評估和改造，確定物理服務(wù)器數(shù)量為3臺，進行虛擬化部署，考慮到20%的冗余資源量。云化后服務(wù)器減少比為80%。云化前服務(wù)器利用率5%，改造后資源利用率在60%左右，資源利用率提升55百分點。同時，投入成本降低80%以上。

國產(chǎn)化部分的性能對比有相關(guān)硬件廠商進行單點測試，本文只對資源層面進行對比測試。對所部署的環(huán)境進行整體壓力測試，按照經(jīng)驗，壓力測試采用逐步提升到并發(fā)峰值為4 000每秒，觀測相關(guān)對應(yīng)變化。

在具體的壓力測試實驗下，CPU資源均化使用率、彈性擴展與壓力測試數(shù)值的對應(yīng)曲線如圖7所示。

圖7 資源均化使用率、彈性擴展與壓力測試數(shù)值對應(yīng)曲線

5.5 效果分析和比對

目前業(yè)內(nèi)OLTP業(yè)務(wù)在進行云化遷移的時候并沒有統(tǒng)一的方法和流程。大都是各個項目或者云平臺運營方根據(jù)關(guān)注點進行設(shè)計，關(guān)注點主要集中在遷移成本、資源使用量、業(yè)務(wù)的連續(xù)性，沒有對整體的架構(gòu)和流程及SLA進行有效設(shè)計。

這種情況存在以下很多問題：(1) 業(yè)務(wù)和數(shù)據(jù)遷移過程不清晰，情況嚴重直接導(dǎo)致業(yè)務(wù)訪問中斷。(2) 資源評估不準(zhǔn)確，過大導(dǎo)致成本上升，過小導(dǎo)致業(yè)務(wù)無法正常運行。(3) 云環(huán)境下業(yè)務(wù)架構(gòu)沒有優(yōu)化，只是物理環(huán)境的簡單復(fù)制，失去了使用云的很多優(yōu)勢，也不能消除掉物理環(huán)境下的業(yè)務(wù)瓶頸。(4) 業(yè)務(wù)的架構(gòu)沒有得到優(yōu)化，導(dǎo)致云環(huán)境下業(yè)務(wù)細粒度的安全防護無法有效實施，出現(xiàn)安全緊急事件后無法快速有效地定位和阻斷。(5) 國產(chǎn)化的要求更是加大了業(yè)務(wù)遷移的時間復(fù)雜度和空間復(fù)雜度。

本文基于云計算框架提出的遷移評估模型和流程，以及針對國產(chǎn)化的適配作為一個整體體系是對OLTP業(yè)務(wù)云化遷移的技術(shù)性參考和流程的梳理，從改造效果看，能夠有效地解決暴露的問題。

6 結(jié) 語

當(dāng)前政務(wù)OLTP業(yè)務(wù)系統(tǒng)在云化遷移過程中存在一系列問題，尤其是要滿足國家國產(chǎn)自主安全可控的安全要求。本文基于云計算框架對此類業(yè)務(wù)的云化遷移進行了模型分析和評估，得出了一般性指標(biāo)的考量，提出了4種核心業(yè)務(wù)模型，并在此基礎(chǔ)上重點基于國產(chǎn)CPU核心指令集構(gòu)建了安全可控的業(yè)務(wù)適配和遷移過程，形成了一套體系化云化遷移安全可控的評估模型。

經(jīng)過實際業(yè)務(wù)的驗證與分析，4種核心模型、網(wǎng)絡(luò)流量模型及國產(chǎn)化適配流程有較高的應(yīng)用性和有效性，在業(yè)務(wù)遷移過程中有較強的指導(dǎo)和借鑒意義。