城市軌道交通系統(tǒng)遷移至云平臺方案研究

林小杰，何躍齊

（1. 天津軌道交通運營集團(tuán)有限公司，天津 300392；2. 北京城建設(shè)計發(fā)展集團(tuán)股份有限公司，北京 100045）

當(dāng)前，中國城市軌道交通（簡稱：城軌）的運營規(guī)模逐漸擴(kuò)大，根據(jù)軌道交通網(wǎng)最新統(tǒng)計，截至2019 年底，我國共開通城軌運營線路208 余條，線路規(guī)模達(dá)6 882.13 km[1]。在城軌網(wǎng)絡(luò)化運營環(huán)境下，需要實現(xiàn)各線路業(yè)務(wù)流程及操作規(guī)則的統(tǒng)一管理，實現(xiàn)業(yè)務(wù)管理的標(biāo)準(zhǔn)化管理，同時要求業(yè)務(wù)應(yīng)用統(tǒng)一部署、數(shù)據(jù)集中管理。近年來，城軌信息化提出了更高效、更節(jié)能的要求，因此，構(gòu)建信息交互更加頻繁、實時性更高、可共享的城軌云需求應(yīng)運而生。為應(yīng)對這種趨勢，《中國城市軌道交通智慧城軌發(fā)展綱要》（簡稱：《發(fā)展綱要》）于2020 年3月12 日正式發(fā)布實施[2]。

目前，國內(nèi)采用云計算技術(shù)的城軌線路基本都是以新建線路為主；而對既有城軌線路業(yè)務(wù)系統(tǒng)雖有更新改造移至城軌云的遷移計劃，但多未有具體實際方案付之實施。本文基于天津市中心城區(qū)華苑控制中心二期工程這一城軌系統(tǒng)云遷移實例，提出城軌業(yè)務(wù)系統(tǒng)統(tǒng)一逐步遷移至城軌云的漸進(jìn)式方案以供大家參考。

1 城軌云建設(shè)模式與云遷移背景

1.1 城軌云建設(shè)模式

城軌云平臺的建設(shè)主要呈現(xiàn)以下4 種建設(shè)的模式：

（1）專業(yè)云模式。以溫州S1 線和鄭州自動售檢票（AFC，Automatic Fare Collection）線網(wǎng)管理中心項目為代表的構(gòu)建單業(yè)務(wù)系統(tǒng)專業(yè)的云平臺。溫州S1 線搭建了城軌綜合監(jiān)控系統(tǒng)（ISCS，Integrated Supervision and Control System）云平臺，將其中的ISCS 與云平臺進(jìn)行結(jié)合，使原本分散孤立的自動化系統(tǒng)聯(lián)結(jié)為一個有機(jī)的整體，實現(xiàn)信息互通、資源共享、高效聯(lián)動[3]，也驗證云平臺的經(jīng)濟(jì)效益、方案、架構(gòu)、兼容性、可靠性等。鄭州地鐵于2019 年5 月20 日開通運營了城軌AFC 系統(tǒng)云平臺，將線網(wǎng)清分中心系統(tǒng)和AFC 系統(tǒng)的線路中心進(jìn)行深度融合[4]，集中部署在該云平臺上。

（2）線路云模式。以呼和浩特地鐵1 號線、2號線和昆明軌道交通4 號線為代表，構(gòu)建單線路多業(yè)務(wù)系統(tǒng)的融合云平臺。呼和浩特地鐵在1、2 號線構(gòu)建了城軌云平臺，為城軌AFC、乘客信息系統(tǒng)（PIS，Passenger Information System）、ISCS、列車自動監(jiān)控（ATS，Automatic Train Supervision）系統(tǒng)等多業(yè)務(wù)系統(tǒng)提供基礎(chǔ)設(shè)施即服務(wù)（IaaS，Infrastructure as a Service），滿足1、2 號線的建設(shè)要求，并預(yù)留將來3、4、5 號線的進(jìn)駐能力[5]；昆明軌道交通4號線云平臺深度集成了20 余個城軌業(yè)務(wù)系統(tǒng)，實現(xiàn)了信息網(wǎng)絡(luò)平臺互聯(lián)[6]。

（3）線網(wǎng)云模式。以天津地鐵、廣州地鐵線網(wǎng)管理或企業(yè)管理私有云逐步擴(kuò)充其它業(yè)務(wù)。天津地鐵在中心城區(qū)華苑控制中心二期工程中，規(guī)劃構(gòu)建城軌線網(wǎng)級云平臺，擬將線網(wǎng)級應(yīng)急指揮、運維管理、數(shù)據(jù)中心、乘客服務(wù)等各業(yè)務(wù)系統(tǒng)遷移至該云平臺，并預(yù)留將來線路云對接條件；廣州地鐵采用了VMware 技術(shù)構(gòu)建企業(yè)管理云，探索采用企業(yè)管理云去擴(kuò)充其他業(yè)務(wù)。

（4）融合云模式。構(gòu)建多線路多系統(tǒng)的融合云平臺，以深圳地鐵正在建設(shè)的網(wǎng)絡(luò)運營控制中心二期和武漢軌道交通網(wǎng)絡(luò)信息化建設(shè)示范工程項目為代表。深圳地鐵在網(wǎng)絡(luò)運營控制中心二期工程中，規(guī)劃構(gòu)建城軌云平臺，計劃將城軌管理、生產(chǎn)、對外服務(wù)等業(yè)務(wù)系統(tǒng)均部署其中[7]；武漢軌道交通網(wǎng)絡(luò)信息化建設(shè)示范工程項目采用基于云平臺、大數(shù)據(jù)的新信息系統(tǒng)架構(gòu)，構(gòu)建異地雙活的數(shù)據(jù)中心，實施新建線路和既有線的信息系統(tǒng)全部納入和遷移到云平臺的技術(shù)方案。

以上是城軌云呈現(xiàn)的4 種建設(shè)模式，其中，第4 種多線路多系統(tǒng)的融合云平臺符合《發(fā)展綱要》關(guān)于城軌云的建設(shè)要求，具有重要推廣意義。但該種模式對于云平臺承載能力、各業(yè)務(wù)系統(tǒng)并發(fā)能力提出了極大的挑戰(zhàn)。這需要從整體上對云平臺進(jìn)行規(guī)劃，同時需合理部署整個云平臺的資源，實現(xiàn)均衡配置。

1.2 城軌系統(tǒng)云遷移背景

國內(nèi)較多的城軌業(yè)務(wù)系統(tǒng)仍主要是以業(yè)務(wù)為中心獨立構(gòu)建煙囪式架構(gòu)系統(tǒng)，再通過多系統(tǒng)之間的對接實現(xiàn)業(yè)務(wù)系統(tǒng)之間的協(xié)調(diào)管理和數(shù)據(jù)管理。這種非云平臺架構(gòu)中，存在業(yè)務(wù)系統(tǒng)分散、網(wǎng)絡(luò)架構(gòu)復(fù)雜、基礎(chǔ)設(shè)施分散，多個系統(tǒng)對接消耗存儲及計算資源、無法實現(xiàn)數(shù)據(jù)共享、無法實現(xiàn)存儲共享等諸多問題；數(shù)據(jù)庫系統(tǒng)基于小型機(jī)、SAN 存儲以及多個節(jié)點的Oracle 集群對外提供服務(wù)[8]，會導(dǎo)致系統(tǒng)整體運行速度慢、單點故障導(dǎo)致數(shù)據(jù)庫不穩(wěn)定，進(jìn)而導(dǎo)致業(yè)務(wù)系統(tǒng)無法提供有效服務(wù)的嚴(yán)重問題[9]。

應(yīng)對以上現(xiàn)狀，文章提出將上述城軌業(yè)務(wù)系統(tǒng)統(tǒng)一逐步遷移至城軌云的漸進(jìn)式方案，使城軌云能夠承載ISCS、AFC、PIS、門禁系統(tǒng)、閉路電視監(jiān)視系統(tǒng)等多業(yè)務(wù)，完成業(yè)務(wù)與數(shù)據(jù)的平滑過度，實現(xiàn)資源共享，按需調(diào)配，彈性擴(kuò)展，為業(yè)務(wù)緊密聯(lián)動和大數(shù)據(jù)分析打下基礎(chǔ)。

2 城軌系統(tǒng)云遷移原則及評估流程

云計算技術(shù)的不斷發(fā)展及普及，從網(wǎng)絡(luò)建設(shè)、架構(gòu)設(shè)計、業(yè)務(wù)運營和系統(tǒng)運維等多個角度對煙囪式傳統(tǒng)架構(gòu)信息系統(tǒng)建設(shè)產(chǎn)生了深遠(yuǎn)影響[10]。傳統(tǒng)架構(gòu)注重硬件的高可用性及縱向擴(kuò)展能力，而云平臺通過分布式架構(gòu)實現(xiàn)橫向擴(kuò)展能力及高可用性，集成了備份、監(jiān)控、高可用性、審計等基礎(chǔ)運維服務(wù)。

2.1 系統(tǒng)云遷移原則

從傳統(tǒng)煙囪式信息系統(tǒng)IOE 架構(gòu)（指傳統(tǒng)計算機(jī)系統(tǒng)中類似基于IBM 公司小型機(jī)、Oracle 公司數(shù)據(jù)庫以及EMC 公司存儲的系統(tǒng)架構(gòu)）向云平臺架構(gòu)轉(zhuǎn)移的過程中需要考慮以下幾點問題：

（1）可用性。脫離小型機(jī)及高端存儲的高冗余機(jī)制，采用基于PC 服務(wù)器的分布式架構(gòu)云計算平臺能否做到高可用[11]。

（2）一致性。Oracle 基于實時應(yīng)用集群及共享存儲可實現(xiàn)物理級別一致性[12]，云數(shù)據(jù)庫可否達(dá)到同類效果。

（3）高性能。高端存儲的I/O 能力很強，基于PC 服務(wù)器的云數(shù)據(jù)庫可否提供同樣、甚至更高的并發(fā)能力[13]。

除此之外，針對業(yè)務(wù)系統(tǒng)是否適合遷移至云平臺，需要根據(jù)業(yè)務(wù)特性、特點、方位等多方面進(jìn)行評估，具體評估內(nèi)容，如表1 所示。

表1 業(yè)務(wù)系統(tǒng)評估

2.2 系統(tǒng)云遷移評估流程

從現(xiàn)有業(yè)務(wù)系統(tǒng)向云平臺遷移時需要根據(jù)系統(tǒng)類型及重要性選擇合適的遷移方式，城軌業(yè)務(wù)系統(tǒng)的云遷移過程應(yīng)根據(jù)實際情況及嚴(yán)格的評估流程進(jìn)行評估。評估流程，如圖1 所示。

3 城軌系統(tǒng)云遷移策略分析

目前，城軌業(yè)務(wù)系統(tǒng)的普遍現(xiàn)狀是業(yè)務(wù)邏輯與數(shù)據(jù)庫之前具有強耦合性，大量采用Oracle 的特有語法PL/SQL 實現(xiàn)，若全部對其改造，造成開發(fā)成本過高、周期過長，短期內(nèi)無法實現(xiàn)云遷移等諸多問題，因此為確保整個系統(tǒng)的平滑過渡，采用漸進(jìn)式云遷移策略來解決城軌業(yè)務(wù)系統(tǒng)的云平臺部署問題。具體的策略如下：

（1）結(jié)構(gòu)化數(shù)據(jù)云遷移，非結(jié)構(gòu)化數(shù)據(jù)、圖片等數(shù)據(jù)暫不遷移。

（2）部分統(tǒng)計分析業(yè)務(wù)云遷移，諸如安檢、票務(wù)等業(yè)務(wù)，將這類業(yè)務(wù)中的統(tǒng)計分析功能優(yōu)先實現(xiàn)云遷移。

（3）周邊非核心業(yè)務(wù)訪問業(yè)務(wù)云遷移，依賴系統(tǒng)數(shù)據(jù)（如線網(wǎng)監(jiān)控、指揮調(diào)度、生產(chǎn)管理）周邊業(yè)務(wù)系統(tǒng)訪問全部遷移至云平臺上實現(xiàn)數(shù)據(jù)庫訪問。

圖1 系統(tǒng)云遷移評估流程

4 城軌系統(tǒng)云遷移方案及架構(gòu)實施

以天津中心城區(qū)華苑控制中心二期工程為例，結(jié)合線網(wǎng)中心系統(tǒng)各系統(tǒng)的現(xiàn)狀，采用部分云遷移的方案，以下分為3 步對系統(tǒng)進(jìn)行漸進(jìn)云遷移。

4.1 結(jié)構(gòu)化數(shù)據(jù)云遷移

將結(jié)構(gòu)化數(shù)據(jù)在云平臺上存儲3 份，分別存儲在關(guān)系型數(shù)據(jù)庫、分析型數(shù)據(jù)庫及大數(shù)據(jù)計算服務(wù)。

（1）關(guān)系型數(shù)據(jù)庫存儲在線業(yè)務(wù)庫結(jié)構(gòu)增量數(shù)據(jù)，對外提供高并發(fā)量、簡單查詢服務(wù)。

（2）分析型數(shù)據(jù)庫通過實時同步服務(wù)從關(guān)系型數(shù)據(jù)庫接收實時增量數(shù)據(jù)，對外提供并發(fā)量較小的實時統(tǒng)計分析查詢。

（3）大數(shù)據(jù)計算服務(wù)主要對外提供離散數(shù)據(jù)分析處理，大數(shù)據(jù)計算服務(wù)中的數(shù)據(jù)增量可通過定期抽取或?qū)崟r同步的方式從關(guān)系型數(shù)據(jù)中完成數(shù)據(jù)同步。具體實施的架構(gòu)，如圖2 所示，圖2 中所指核心業(yè)務(wù)及周邊業(yè)務(wù)是根據(jù)具體、符合此種業(yè)務(wù)與邏輯關(guān)系的情況而定的，云上業(yè)務(wù)系統(tǒng)和云下業(yè)務(wù)系統(tǒng)在線業(yè)務(wù)庫沒有任何數(shù)據(jù)或接口間的調(diào)用關(guān)系，云上業(yè)務(wù)的訪問均由關(guān)系型數(shù)據(jù)庫支撐。

圖2 結(jié)構(gòu)化數(shù)據(jù)云遷移方案示意

4.2 異構(gòu)數(shù)據(jù)庫改造云遷移

異構(gòu)數(shù)據(jù)庫改造云遷移主要包含2 部分。

（1）依賴于原有系統(tǒng)提供數(shù)據(jù)支持的周邊業(yè)務(wù)改造云遷移。

（2）原有的系統(tǒng)部分統(tǒng)計分析功能改造業(yè)務(wù)云遷移。

異構(gòu)數(shù)據(jù)云遷移的前提條件是充分調(diào)研平臺系統(tǒng)各個業(yè)務(wù)模塊之間的調(diào)用關(guān)系，優(yōu)先遷移沒有業(yè)務(wù)調(diào)用關(guān)系或業(yè)務(wù)調(diào)用關(guān)系較少的業(yè)務(wù)模塊，并且需要根據(jù)業(yè)務(wù)訪問的特點合理選擇關(guān)系型數(shù)據(jù)庫、分析型數(shù)據(jù)庫、大數(shù)據(jù)計算服務(wù)，依照從簡單到復(fù)雜的原則逐步完成整個在線業(yè)務(wù)系統(tǒng)的異構(gòu)改造云遷移。實現(xiàn)云遷移的業(yè)務(wù)處理邏輯和數(shù)據(jù)訪問功能全部在云平臺完成。具體實施的策略，如圖3 所示。

圖3 異構(gòu)數(shù)據(jù)庫云遷移方案示意

4.3 數(shù)據(jù)同步云遷移

完成前兩步的云遷移改造后，利用分布式數(shù)據(jù)庫服務(wù)繼續(xù)對業(yè)務(wù)系統(tǒng)進(jìn)行優(yōu)化。主要涉及2 個方面的內(nèi)容。

（1）使用分布式關(guān)系數(shù)據(jù)庫實現(xiàn)關(guān)系型數(shù)據(jù)庫節(jié)點的動態(tài)可擴(kuò)展性。

（2）基于企業(yè)級分布式應(yīng)用服務(wù)進(jìn)行微服務(wù)化改造。

最終實現(xiàn)業(yè)務(wù)系統(tǒng)在云端的部署狀態(tài)。云上的最終實施架構(gòu)以及遷移后城軌云平臺最終架構(gòu)如圖4、圖5 所示。

圖4 云遷移后業(yè)務(wù)邏輯

圖5 云平臺遷移前后架構(gòu)對比

天津中心城區(qū)華苑控制中心二期工程項目正處在實施階段，從云平臺遷移前后架構(gòu)對比來看，項目擬通過城軌業(yè)務(wù)系統(tǒng)及數(shù)據(jù)的云平臺遷移。

（1）提高資源利用率，降低建設(shè)運營成本。

（2）實現(xiàn)對各條線路的統(tǒng)籌協(xié)調(diào)、統(tǒng)一運維，并借助云平臺的高可靠、可擴(kuò)展性、資源復(fù)用、數(shù)據(jù)共享等優(yōu)勢，不斷提升天津城市軌道交通的運營信息化管理水平，提高運能、降低成本。

5 結(jié)束語

城軌云平臺是信息化時代城軌運營管理的重要手段，建設(shè)城軌云平臺可以顯著提高資源的利用率及控制中心的運營效率。但云遷移并非易事，除了本文所提出的方面之外，還需要考慮的因素很多，比如成本優(yōu)化、額外的安全隱患以及遷移后的業(yè)務(wù)資源消耗等，這些都需要具體問題具體探討[14]。切忌為了遷移而遷移，應(yīng)遵循與其他復(fù)雜項目一樣的原則，要有系統(tǒng)的規(guī)劃和適當(dāng)?shù)臏?zhǔn)備。本文提出的城軌業(yè)務(wù)系統(tǒng)統(tǒng)一逐步遷移至城軌云漸進(jìn)式方案，不僅可以降低云遷移過程的風(fēng)險，還可以幫助問題追蹤，為目前國內(nèi)廣大城軌業(yè)務(wù)系統(tǒng)遷移云需求提供具體的借鑒與參考。