呂廣杰，劉慶良，吳 超，范義波

（浪潮電子信息產(chǎn)業(yè)股份有限公司，濟(jì)南 250101）

1 研究背景

1.1 城軌云的發(fā)展歷程

中國城市軌道交通云平臺(tái)(以下簡稱“城軌云”)項(xiàng)目的建設(shè)主要經(jīng)歷了以下幾個(gè)階段：

1) 單業(yè)務(wù)探索階段。該階段主要是單業(yè)務(wù)系統(tǒng)上云嘗試，圍繞單個(gè)業(yè)務(wù)系統(tǒng)建設(shè)云計(jì)算平臺(tái)，提升資源利用率和運(yùn)營運(yùn)維效率，典型項(xiàng)目包括溫州軌道交通S1 線的綜合監(jiān)控、沈陽地鐵iAFC 云和昆明地鐵1、2 號(hào)線綜合監(jiān)控云化改造項(xiàng)目等[1]。

2) 線路融合階段。該階段以單條線路為上云單位，將線路內(nèi)的多套系統(tǒng)統(tǒng)一上云，依托虛擬化技術(shù)，實(shí)現(xiàn)線路內(nèi)多個(gè)專業(yè)間的資源共享和數(shù)據(jù)交互，典型項(xiàng)目包括金義東城際和深圳軌道交通6、10 號(hào)線中的線路云平臺(tái)等[2]。

3) 線網(wǎng)融合階段。該階段將多條線路的安全生產(chǎn)業(yè)務(wù)系統(tǒng)進(jìn)行融合，實(shí)現(xiàn)多條線路、多個(gè)專業(yè)間的資源與數(shù)據(jù)共享，統(tǒng)一地鐵信息化系統(tǒng)[3]。

4) 體系規(guī)范化階段。由中國城市軌道交通協(xié)會(huì)牽頭組織，陸續(xù)發(fā)布了包括《市域快軌技術(shù)規(guī)范》[4]和《智慧城市軌道交通信息技術(shù)架構(gòu)及網(wǎng)絡(luò)安全規(guī)范》[5]等一系列城軌云相關(guān)技術(shù)規(guī)范，將城軌云建設(shè)上升到體系建設(shè)層面，典型項(xiàng)目有呼和浩特城軌云、太原城軌云等。

1.2 城軌云架構(gòu)及特點(diǎn)

《中國城市軌道交通智慧城軌發(fā)展綱要》定義了“1 3 5 3 1”的城軌信息化總體架構(gòu)，即打造一個(gè)門戶，構(gòu)建三個(gè)中心，拓展五大領(lǐng)域，依托三張網(wǎng)絡(luò)，搭建一個(gè)平臺(tái)[6]。該架構(gòu)具有如下特點(diǎn)：

1) 在進(jìn)行云化和數(shù)據(jù)化改造過程中，安全生產(chǎn)、內(nèi)部管理和外部服務(wù)三個(gè)業(yè)務(wù)域既要充分考慮安全隔離，也要最大限度地實(shí)現(xiàn)數(shù)據(jù)的共享。

2) 穩(wěn)定性、安全性和易用性是城軌云最重要的訴求，保障乘客的生命財(cái)產(chǎn)安全是首要的原則。

3) 城軌業(yè)務(wù)場景根據(jù)實(shí)際需求可由云、邊、端構(gòu)成，要滿足云邊協(xié)同場景訴求。

城軌云通過融合底層資源，打破信息孤島，實(shí)現(xiàn)跨線路、跨專業(yè)、跨系統(tǒng)、跨功能的整合聯(lián)動(dòng)，提高地鐵業(yè)務(wù)系統(tǒng)的資源利用率和可靠性?；谠萍軜?gòu)底層，與人工智能、大數(shù)據(jù)、5G、物聯(lián)網(wǎng)、區(qū)塊鏈等新興信息技術(shù)結(jié)合，可有效促進(jìn)智慧城軌創(chuàng)新應(yīng)用的誕生，如智慧車站、智慧運(yùn)維、智慧乘客服務(wù)等[7]，使城軌業(yè)務(wù)更加靈活，服務(wù)更加智能。

1.3 城軌云面臨的問題

當(dāng)前，城軌云相關(guān)技術(shù)規(guī)范已相對(duì)成熟，但基礎(chǔ)設(shè)施和應(yīng)用系統(tǒng)缺乏核心技術(shù)，業(yè)務(wù)系統(tǒng)多采用Oracle或DB2 作為核心數(shù)據(jù)庫，服務(wù)器采用POWER 小型機(jī)或X86服務(wù)器，操作系統(tǒng)采用AIX、RedHat或Windows等系統(tǒng)，對(duì)國外產(chǎn)品依存度高，關(guān)鍵環(huán)節(jié)存在“卡脖子”風(fēng)險(xiǎn)[8]。

為此，筆者提出面向城市軌道交通的自主可控云平臺(tái)遷移方案，將城軌云基礎(chǔ)設(shè)施逐步遷移到可掌控、可研究、可發(fā)展、可生產(chǎn)的信創(chuàng)平臺(tái)，從根本上解決城軌業(yè)務(wù)系統(tǒng)的自主可控、安全可信問題。

2 平臺(tái)遷移

2.1 平臺(tái)構(gòu)成

如圖1 所示，城軌自主可控云平臺(tái)，即依托信創(chuàng)軟硬件體系搭建的云計(jì)算平臺(tái)。按照業(yè)務(wù)性質(zhì)和網(wǎng)絡(luò)安全等級(jí)保護(hù)要求，劃分為安全生產(chǎn)、內(nèi)部管理、外部服務(wù)三大業(yè)務(wù)域，分別構(gòu)建基礎(chǔ)設(shè)施、IaaS、PaaS、SaaS 層。其中，基礎(chǔ)設(shè)施層采用基于ARM、MIPS、Alpha、X86 等信創(chuàng)架構(gòu)的設(shè)備組成；IaaS 層基于虛擬化能力，將基礎(chǔ)設(shè)施層的設(shè)備進(jìn)行統(tǒng)一抽象池化，提供虛擬機(jī)、裸機(jī)、容器、VPC、塊存儲(chǔ)等IaaS 服務(wù)；PaaS 層提供信創(chuàng)版本數(shù)據(jù)庫、中間件、大數(shù)據(jù)、適配驗(yàn)證、開發(fā)測(cè)試等平臺(tái)服務(wù)；SaaS 層承載具體的軟件 業(yè)務(wù)系統(tǒng)，如安全生產(chǎn)域的ACC、ISCS，內(nèi)部管理域的運(yùn)營管理、企業(yè)管理，外部服務(wù)域的視頻監(jiān)控、公務(wù)電話等；建設(shè)標(biāo)準(zhǔn)規(guī)范體系和安全防護(hù)體系，保障城軌云的合規(guī)性。

圖1 城軌自主可控云平臺(tái)的邏輯架構(gòu) Figure 1 Logical architecture of independent controllable cloud platform of urban rail transit

將城軌業(yè)務(wù)系統(tǒng)遷移到自主可控云平臺(tái)上，涵蓋基礎(chǔ)設(shè)施(如服務(wù)器、存儲(chǔ)、網(wǎng)絡(luò)、安全設(shè)備)、操作系統(tǒng)、軟件(數(shù)據(jù)庫、中間件等)的遷移，具體如表1 所示。

表1 自主可控云平臺(tái)系統(tǒng)的運(yùn)行環(huán)境對(duì)比 Table 1 Comparison of operating environment of independent controllable cloud platform

2.2 遷移原則

城軌業(yè)務(wù)系統(tǒng)遷移，應(yīng)遵循“試點(diǎn)先行，先低后高，先前再后，關(guān)聯(lián)同批”的原則。

1) 試點(diǎn)先行。選擇典型業(yè)務(wù)系統(tǒng)進(jìn)行小規(guī)模試點(diǎn)，運(yùn)行穩(wěn)定后逐步切換。

2) 先低后高。按照業(yè)務(wù)重要性的低高逐步遷移。3 個(gè)業(yè)務(wù)域中，建議先進(jìn)行外部服務(wù)業(yè)務(wù)(如郵箱、公務(wù)電話)的遷移，再進(jìn)行內(nèi)部管理業(yè)務(wù)(如企業(yè)管理、運(yùn)營管理)的遷移，最后進(jìn)行安全生產(chǎn)業(yè)務(wù)(如ACC、PIS)的遷移。在一個(gè)業(yè)務(wù)域內(nèi)部，也要按照業(yè)務(wù)的重要性由低向高的方向遷移。

3) 先前再后。對(duì)于前后端分離的業(yè)務(wù)系統(tǒng)，先遷移前端中間件，再遷移數(shù)據(jù)庫，最后遷移后端應(yīng)用。

4) 關(guān)聯(lián)同批，制定具體的遷移計(jì)劃時(shí)，要考慮各業(yè)務(wù)系統(tǒng)間的關(guān)聯(lián)性，盡量把具有強(qiáng)關(guān)聯(lián)性的系統(tǒng)放在同一批次里[9]。

2.3 遷移流程

業(yè)務(wù)系統(tǒng)遷移是一個(gè)復(fù)雜的系統(tǒng)工程，整個(gè)流程至少包括遷移評(píng)估與準(zhǔn)備、資源規(guī)劃、中間件遷移、數(shù)據(jù)庫遷移、應(yīng)用遷移、測(cè)試驗(yàn)證、應(yīng)用上線等幾個(gè)階段，如圖2 所示。

2.4 遷移準(zhǔn)備

基于信息化建設(shè)項(xiàng)目的實(shí)踐經(jīng)驗(yàn)，針對(duì)業(yè)務(wù)系統(tǒng)的業(yè)務(wù)屬性、訪問量、開發(fā)語言、依賴組件等指標(biāo)，設(shè)計(jì)業(yè)務(wù)系統(tǒng)遷移難度評(píng)分表(見表2)和業(yè)務(wù)系統(tǒng)遷移難易度說明表(見表3)。

圖2 遷移流程 Figure 2 Migration flowchart

表2 業(yè)務(wù)系統(tǒng)遷移難度評(píng)分 Table 2 Scoring of difficulty for business system migration

表3 業(yè)務(wù)系統(tǒng)遷移難易度說明 Table 3 Difficulties for business system migration

以某乘客信息系統(tǒng)為例，該系統(tǒng)為重要類業(yè)務(wù)(3分)，并發(fā)訪問量較小(1 分)，開發(fā)語言Java(1 分)，中間件WebLogic(3 分)，數(shù)據(jù)庫MySql(1 分)，操作系統(tǒng)CentOS(1 分)，得分為3+1+1+3+1+1=10 分。依照遷移難易度說明，該系統(tǒng)易于遷移。

根據(jù)城軌各業(yè)務(wù)系統(tǒng)的特點(diǎn)和發(fā)展現(xiàn)狀，分析其遷移難易度，綜合評(píng)估確定遷移業(yè)務(wù)系統(tǒng)的業(yè)務(wù)范圍、遷移難易度，制定遷移整體計(jì)劃，并將整體計(jì)劃細(xì)化拆分，梳理出每個(gè)應(yīng)用系統(tǒng)的詳細(xì)遷移計(jì)劃。注意事項(xiàng)如下：

1) 由于大部分應(yīng)用系統(tǒng)遷移時(shí)需要中斷正常業(yè)務(wù)，因此遷移時(shí)間最好在業(yè)務(wù)壓力較小的晚間或周末進(jìn)行，并確保業(yè)務(wù)應(yīng)用原廠工程師、遷移實(shí)施人員以及業(yè)務(wù)系統(tǒng)用戶三方均到場。

2) 由于遷移并不能保證一次性成功，所以在開始遷移之前，應(yīng)對(duì)待遷移的業(yè)務(wù)數(shù)據(jù)進(jìn)行完全備份，以保證遷移過程中意外情況的數(shù)據(jù)完整性恢復(fù)。

3) 在新遷移的業(yè)務(wù)系統(tǒng)正式上線之前，原有業(yè)務(wù)系統(tǒng)的中間件、數(shù)據(jù)庫、應(yīng)用系統(tǒng)等組件務(wù)必完全保留，不要隨意刪除。

3 實(shí)施路徑

城軌云平臺(tái)承載的3 個(gè)業(yè)務(wù)域是根據(jù)等保要求進(jìn)行安全隔離的，雖然承載不同的業(yè)務(wù)系統(tǒng)，但其在IT層面依賴的基礎(chǔ)軟硬件大同小異，通用的遷移實(shí)施路徑如下。

3.1 資源規(guī)劃

收集待遷移業(yè)務(wù)系統(tǒng)信息，如表4 所示。

表4 業(yè)務(wù)系統(tǒng)信息 Table 4 Business system information

1) 遷移業(yè)務(wù)資源需求總量的計(jì)算方法：CPU/內(nèi)存/存儲(chǔ)需求總量 = 每個(gè)業(yè)務(wù)系統(tǒng)所需的CPU/內(nèi)存/存儲(chǔ)×平均利用率總和，單臺(tái)服務(wù)器CPU 總量 = CPU 個(gè)數(shù)×CPU 核心數(shù)×單核CPU(GHz)[10]。

2) 根據(jù)計(jì)算推導(dǎo)集群配置：需求的服務(wù)器數(shù)量 = (CPU 需求總量/單臺(tái)服務(wù)器CPU 總量)×1.25(預(yù)留25%資源)+1(集群冗余)，每臺(tái)服務(wù)器內(nèi)存配置 = 內(nèi)存需求總量/需求的服務(wù)器數(shù)量。

3) 每個(gè)業(yè)務(wù)系統(tǒng)所需虛擬機(jī)的規(guī)格：單個(gè)業(yè)務(wù)系統(tǒng)所需的vCPU = 單個(gè)業(yè)務(wù)所需CPU(GHz)×CPU 平均利用率/單核CPU(GHz)，單個(gè)業(yè)務(wù)系統(tǒng)所需的內(nèi)存/存儲(chǔ) = 單個(gè)業(yè)務(wù)所需內(nèi)存/存儲(chǔ)×平均利用率。

根據(jù)以上公式，可推算出遷移業(yè)務(wù)系統(tǒng)所需的集群規(guī)模(集群節(jié)點(diǎn)數(shù)、服務(wù)器配置和存儲(chǔ)配置)，以及單個(gè)業(yè)務(wù)所需的虛擬機(jī)配置。

在遷移業(yè)務(wù)系統(tǒng)時(shí)，根據(jù)源端系統(tǒng)配置情況，規(guī)劃目的端資源配置(CPU、內(nèi)存、磁盤以及網(wǎng)絡(luò)IP 等)，默認(rèn)和源端保持一致。當(dāng)后續(xù)業(yè)務(wù)負(fù)載變化需要擴(kuò)/縮資源時(shí)，可在云環(huán)境修改相應(yīng)的虛擬機(jī)配置。某項(xiàng)目中典型業(yè)務(wù)系統(tǒng)的配置信息如表5 所示。

3.2 中間件遷移

城軌業(yè)務(wù)用得比較多的中間件是Web 中間件和消息中間件。中間件的遷移，主要是將應(yīng)用系統(tǒng)與信創(chuàng)CPU 環(huán)境下的目的中間件(如中創(chuàng)、金蝶、東方通等)進(jìn)行對(duì)接，將原有業(yè)務(wù)系統(tǒng)的中間件配置參數(shù)在目的中間件重新設(shè)定。以從 Weblogic 遷移到中創(chuàng)InforSuite AS 為例，相應(yīng)的配置信息對(duì)應(yīng)如表6 所示。

表5 業(yè)務(wù)系統(tǒng)配置信息 Table 5 Configuration information for business system

表6 Weblogic 與InforSuite AS 配置信息對(duì)應(yīng) Table 6 Configuration information correspondence between Oracle Weblogic Server and InforSuite Application Server

配置信息遷移完成后，由中間件廠商技術(shù)人員與應(yīng)用系統(tǒng)供應(yīng)商技術(shù)人員共同進(jìn)行中間件功能驗(yàn)證、測(cè)試及性能調(diào)優(yōu)。

3.3 數(shù)據(jù)庫遷移

城軌業(yè)務(wù)系統(tǒng)使用的數(shù)據(jù)庫主要是Oracle 和DB2，數(shù)據(jù)庫廠商技術(shù)人員利用數(shù)據(jù)遷移工具，可完成源數(shù)據(jù)庫到達(dá)夢(mèng)、人大金倉、南大通用等數(shù)據(jù)庫的數(shù)據(jù)結(jié)構(gòu)遷移工作，包括表、索引、視圖、序列等對(duì)象，并手工完成觸發(fā)器、函數(shù)、存儲(chǔ)過程的遷移。將應(yīng)用系統(tǒng)與目的數(shù)據(jù)庫進(jìn)行對(duì)接，修改應(yīng)用系統(tǒng)中的數(shù)據(jù)庫操作部分源碼，以滿足目的數(shù)據(jù)庫的方言要求。

完成遷移后，數(shù)據(jù)庫廠商技術(shù)人員配合應(yīng)用廠商負(fù)責(zé)人進(jìn)行數(shù)據(jù)完整性校驗(yàn)。

3.4 應(yīng)用遷移

需要根據(jù)不同的業(yè)務(wù)系統(tǒng)開發(fā)語言，制定適配遷移的具體方案。目前，大部分開發(fā)語言能夠支持遷移，但遷移復(fù)雜度不同，具體可應(yīng)用遷移適配策略表，如表7 所示。

表7 應(yīng)用遷移適配策略 Table 7 Strategy of application migration adaptation

3.4.1 解釋型語言應(yīng)用遷移

對(duì)于Java、PHP、Python 等解釋型語言，僅需在新的CPU 架構(gòu)環(huán)境下重新編譯即可使用。以Java 為例，其遷移過程如下：

1) 獲取源碼：獲取應(yīng)用系統(tǒng)的Java 源碼；

2) 準(zhǔn)備編譯環(huán)境：選擇目的CPU 架構(gòu)(如FT、龍芯等)的編譯環(huán)境，建議選擇jdk1.8 及以上版本； 3) 重新編譯：將Java 源碼編譯成類文件； 4) JVM 運(yùn)行：啟動(dòng)應(yīng)用程序進(jìn)行功能調(diào)試。

3.4.2 編譯型語言應(yīng)用遷移

對(duì)于C、C++、Go 等編譯型語言，需要對(duì)依賴庫、操作系統(tǒng)、平臺(tái)、數(shù)據(jù)庫相關(guān)的兼容適配進(jìn)行改造，并進(jìn)行重新編譯，才能完成遷移。以C 語言為例，其遷移過程如下：

1) 獲取源碼：獲取應(yīng)用系統(tǒng)的C 源碼；

2) 準(zhǔn)備編譯環(huán)境：選擇目的CPU 架構(gòu)(如FT、龍芯等)的編譯環(huán)境，建議選擇gcc7.3 以上的版本；

3) 編譯腳本修改：使用開源軟件源碼中的cmake 或autoconfig 腳本生產(chǎn)makefile，需要修改適配至目標(biāo)架構(gòu)；

4) 編譯：執(zhí)行makefile 進(jìn)行編譯；

5) 替換依賴庫：通過開源軟件的readme 文件、自身軟件產(chǎn)品的依賴庫、編譯時(shí)的so 庫缺失或鏈接錯(cuò)誤，重新編譯或替換依賴庫；

6) 編譯優(yōu)化：對(duì)于不同的架構(gòu)，相同的編譯參數(shù)可能帶來性能的差異，需要根據(jù)不同架構(gòu)平臺(tái)，增加或修改編譯選項(xiàng)；

7) 發(fā)布應(yīng)用：生成應(yīng)用的安裝包或鏡像。

完成應(yīng)用程序的遷移后，可以采用原有的中間件、數(shù)據(jù)庫等其他組件，進(jìn)行初步的測(cè)試，以保證應(yīng)用系統(tǒng)可以正常使用。

3.5 測(cè)試驗(yàn)證

遷移過程結(jié)束后，打開相應(yīng)的云環(huán)境資源(如虛擬機(jī)、裸機(jī)等)，以檢驗(yàn)遷移完整性以及業(yè)務(wù)能否正常運(yùn)行。

在業(yè)務(wù)系統(tǒng)正式上線前，需檢測(cè)其功能需求、設(shè)計(jì)方案、性能指標(biāo)等是否可以達(dá)到正常的運(yùn)行要求。在獨(dú)立的測(cè)試驗(yàn)證區(qū)域，對(duì)業(yè)務(wù)系統(tǒng)進(jìn)行完整充分的測(cè)試，包括但不限于單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、壓力測(cè)試、穩(wěn)定性測(cè)試、安全性測(cè)試以及云資源的擴(kuò)/縮測(cè)試等[11]，在確保業(yè)務(wù)軟件運(yùn)行正常的前提下，對(duì)遷移后的業(yè)務(wù)進(jìn)行問題修復(fù)及性能調(diào)優(yōu)。

3.6 應(yīng)用上線

在業(yè)務(wù)系統(tǒng)遷移完成后，需要進(jìn)行至少3～6 個(gè)月的試運(yùn)行。通過試運(yùn)行，發(fā)現(xiàn)應(yīng)用系統(tǒng)存在的問題，以便進(jìn)一步完善和修復(fù)。

在業(yè)務(wù)系統(tǒng)試運(yùn)行期間，將原有環(huán)境保留一段時(shí)間，待試運(yùn)行通過后，新環(huán)境正式啟用上線。原環(huán)境根據(jù)實(shí)際情況，保留一段時(shí)間之后再清理回收。

4 應(yīng)用案例

4.1 項(xiàng)目簡介

在某信創(chuàng)云項(xiàng)目中，筆者采用云平臺(tái)統(tǒng)一管理飛騰、鯤鵬、龍芯等國產(chǎn)CPU 設(shè)備，協(xié)助業(yè)主完成100+套應(yīng)用系統(tǒng)的技術(shù)分析、編譯移植、應(yīng)用上云、性能調(diào)優(yōu)，實(shí)現(xiàn)了操作系統(tǒng)由RedHat 遷移到UOS、麒麟操作系統(tǒng)，應(yīng)用中間件由Weblogic 遷移到中創(chuàng)InforSuite AS 企業(yè)版，數(shù)據(jù)庫由Oracle 遷移到達(dá)夢(mèng)數(shù)據(jù)庫，提供了從IaaS 到SaaS 的全面自主可控云數(shù)據(jù)中心的管理和服務(wù)功能。

通過自主可控的云平臺(tái)，提供穩(wěn)定、可靠、彈性、敏捷的云服務(wù)，統(tǒng)一提供計(jì)算資源、存儲(chǔ)資源、網(wǎng)絡(luò)資源、安全資源、業(yè)務(wù)應(yīng)用、運(yùn)行維護(hù)等云服務(wù)，提高了資源利用效率，降低了總體使用成本。

4.2 經(jīng)驗(yàn)總結(jié)

總結(jié)項(xiàng)目遷移過程中的典型問題及解決方案，如表8 所示。

表8 典型問題及解決方案 Table 8 Solutions to typical problems

5 結(jié)語

城軌云作為新基建的重要組成部分，在當(dāng)前的國際形勢(shì)下，信創(chuàng)遷移適配的需求逐漸迫切。除本研究提到的方案外，自主可控云平臺(tái)的業(yè)務(wù)系統(tǒng)遷移還需考慮系統(tǒng)的性能、穩(wěn)定性、復(fù)雜度、應(yīng)用拆分、程序改造等多項(xiàng)因素，是一個(gè)循序漸進(jìn)的系統(tǒng)性工程。因此，建議在既有城軌云的基礎(chǔ)上，構(gòu)建小規(guī)模的自主可控云環(huán)境進(jìn)行試點(diǎn)，待解決方案和遷移技術(shù)成熟后，再分階段有序地進(jìn)行規(guī)?；w移。