天天看點

城市軌道交通系統遷移至雲平台方案研究

作者:暢藩軟體

目前,中國城市軌道交通(簡稱:城軌)的營運規模逐漸擴大,根據軌道交通網最新統計,截至2019年底,大陸共開通城軌營運線路208餘條,線路規模達6 882.13 km[1]。在城軌網絡化營運環境下,需要實作各線路業務流程及操作規則的統一管理,實作業務管理的标準化管理,同時要求業務應用統一部署、資料集中管理。近年來,城軌資訊化提出了更高效、更節能的要求,是以,建構資訊互動更加頻繁、實時性更高、可共享的城軌雲需求應運而生。為應對這種趨勢,《中國城市軌道交通智慧城軌發展綱要》(簡稱:《發展綱要》)于2020年3月12日正式釋出實施[2]。

目前,國内采用雲計算技術的城軌線路基本都是以建立線路為主;而對既有城軌線路業務系統雖有更新改造移至城軌雲的遷移計劃,但多未有具體實際方案付之實施。本文基于天津市中心城區華苑控制中心二期工程這一城軌系統雲遷移執行個體,提出城軌業務系統統一逐漸遷移至城軌雲的漸進式方案以供大家參考。

1. 城軌雲建設模式與雲遷移背景

1.1 城軌雲建設模式

城軌雲平台的建設主要呈現以下4種建設的模式:

(1)專業雲模式。以溫州S1線和鄭州自動售檢票(AFC,Automatic Fare Collection)線網管理中心項目為代表的建構單業務系統專業的雲平台。溫州S1線搭建了城軌綜合監控系統(ISCS,Integrated Supervision and Control System)雲平台,将其中的ISCS與雲平台進行結合,使原本分散孤立的自動化系統聯結為一個有機的整體,實作資訊互通、資源共享、高效關聯[3],也驗證雲平台的經濟效益、方案、架構、相容性、可靠性等。鄭州地鐵于2019年5月20日開通營運了城軌AFC系統雲平台,将線網清分中心系統和AFC系統的線路中心進行深度融合[4],集中部署在該雲平台上。

(2)線路雲模式。以呼和浩特地鐵1号線、2号線和昆明軌道交通4号線為代表,建構單線路多業務系統的融合雲平台。呼和浩特地鐵在1、2号線建構了城軌雲平台,為城軌AFC、乘客資訊系統(PIS,Passenger Information System)、ISCS、列車自動監控(ATS,Automatic Train Supervision)系統等多業務系統提供基礎設施即服務(IaaS,Infrastructure as a Service),滿足1、2号線的建設要求,并預留将來3、4、5号線的進駐能力[5];昆明軌道交通4号線雲平台深度內建了20餘個城軌業務系統,實作了資訊網絡平台互聯[6]。

(3)線網雲模式。以天津地鐵、廣州地鐵線網管理或企業管理私有雲逐漸擴充其它業務。天津地鐵在中心城區華苑控制中心二期工程中,規劃建構城軌線網級雲平台,拟将線網級應急指揮、運維管理、資料中心、乘客服務等各業務系統遷移至該雲平台,并預留将來線路雲對接條件;廣州地鐵采用了VMware技術建構企業管理雲,探索采用企業管理雲去擴充其他業務。

(4)融合雲模式。建構多線路多系統的融合雲平台,以深圳地鐵正在建設的網絡營運控制中心二期和武漢軌道交通網絡資訊化建設示範工程項目為代表。深圳地鐵在網絡營運控制中心二期工程中,規劃建構城軌雲平台,計劃将城軌管理、生産、對外服務等業務系統均部署其中[7];武漢軌道交通網絡資訊化建設示範工程項目采用基于雲平台、大資料的新資訊系統架構,建構異地雙活的資料中心,實施建立線路和既有線的資訊系統全部納入和遷移到雲平台的技術方案。

以上是城軌雲呈現的4種建設模式,其中,第4種多線路多系統的融合雲平台符合《發展綱要》關于城軌雲的建設要求,具有重要推廣意義。但該種模式對于雲平台承載能力、各業務系統并發能力提出了極大的挑戰。這需要從整體上對雲平台進行規劃,同時需合理部署整個雲平台的資源,實作均衡配置。

1.2 城軌系統雲遷移背景

國内較多的城軌業務系統仍主要是以業務為中心獨立建構煙囪式架構系統,再通過多系統之間的對接實作業務系統之間的協調管理和資料管理。這種非雲平台架構中,存在業務系統分散、網絡架構複雜、基礎設施分散,多個系統對接消耗存儲及計算資源、無法實作資料共享、無法實作存儲共享等諸多問題;資料庫系統基于小型機、SAN存儲以及多個節點的Oracle叢集對外提供服務[8],會導緻系統整體運作速度慢、單點故障導緻資料庫不穩定,進而導緻業務系統無法提供有效服務的嚴重問題[9]。

應對以上現狀,文章提出将上述城軌業務系統統一逐漸遷移至城軌雲的漸進式方案,使城軌雲能夠承載ISCS、AFC、PIS、門禁系統、閉路電視監視系統等多業務,完成業務與資料的平滑過度,實作資源共享,按需調配,彈性擴充,為業務緊密關聯和大資料分析打下基礎。

2. 城軌系統雲遷移原則及評估流程

雲計算技術的不斷發展及普及,從網絡建設、架構設計、業務營運和系統運維等多個角度對煙囪式傳統架構資訊系統建設産生了深遠影響[10]。傳統架構注重硬體的高可用性及縱向擴充能力,而雲平台通過分布式架構實作橫向擴充能力及高可用性,內建了備份、監控、高可用性、審計等基礎運維服務。

2.1 系統雲遷移原則

從傳統煙囪式資訊系統IOE架構(指傳統計算機系統中類似基于IBM公司小型機、Oracle公司資料庫以及EMC公司存儲的系統架構)向雲平台架構轉移的過程中需要考慮以下幾點問題:

(1)可用性。脫離小型機及高端存儲的高備援機制,采用基于PC伺服器的分布式架構雲計算平台能否做到高可用[11]。

(2)一緻性。Oracle基于實時應用叢集及共享存儲可實作實體級别一緻性[12],雲資料庫可否達到同類效果。

(3)高性能。高端存儲的I/O能力很強,基于PC伺服器的雲資料庫可否提供同樣、甚至更高的并發能力[13]。

除此之外,針對業務系統是否适合遷移至雲平台,需要根據業務特性、特點、方位等多方面進行評估,具體評估内容,如表1所示。

表 1 業務系統評估

業務系統 主要内容
系統重要性

使用範圍、故障影響的範圍、

允許最大停機時間、重要等級

目前部署模式 集中部署、分級/分散部署、部署位置
是否具備遷移上雲條件

是否長期使用

是否存在嚴重故障隐患

系統資源使用率

是否支援系統優化改造

是否支援平滑雲遷移

城市軌道交通系統遷移至雲平台方案研究

下載下傳: 導出CSV | 顯示表格

2.2 系統雲遷移評估流程

從現有業務系統向雲平台遷移時需要根據系統類型及重要性選擇合适的遷移方式,城軌業務系統的雲遷移過程應根據實際情況及嚴格的評估流程進行評估。評估流程,如圖1所示。

城市軌道交通系統遷移至雲平台方案研究

圖 1 系統雲遷移評估流程

城市軌道交通系統遷移至雲平台方案研究

下載下傳: 全尺寸圖檔 幻燈片

3. 城軌系統雲遷移政策分析

目前,城軌業務系統的普遍現狀是業務邏輯與資料庫之前具有強耦合性,大量采用Oracle的特有文法PL/SQL實作,若全部對其改造,造成開發成本過高、周期過長,短期内無法實作雲遷移等諸多問題,是以為確定整個系統的平滑過渡,采用漸進式雲遷移政策來解決城軌業務系統的雲平台部署問題。具體的政策如下:

(1)結構化資料雲遷移,非結構化資料、圖檔等資料暫不遷移。

(2)部分統計分析業務雲遷移,諸如安檢、票務等業務,将這類業務中的統計分析功能優先實作雲遷移。

(3)周邊非核心業務通路業務雲遷移,依賴系統資料(如線網監控、指揮排程、生産管理)周邊業務系統通路全部遷移至雲平台上實作資料庫通路。

4. 城軌系統雲遷移方案及架構實施

以天津中心城區華苑控制中心二期工程為例,結合線網中心系統各系統的現狀,采用部分雲遷移的方案,以下分為3步對系統進行漸進雲遷移。

4.1 結構化資料雲遷移

将結構化資料在雲平台上存儲3份,分别存儲在關系型資料庫、分析型資料庫及大資料計算服務。

(1)關系型資料庫存儲線上業務庫結構增量資料,對外提供高并發量、簡單查詢服務。

(2)分析型資料庫通過實時同步服務從關系型資料庫接收實時增量資料,對外提供并發量較小的實時統計分析查詢。

(3)大資料計算服務主要對外提供離散資料分析處理,大資料計算服務中的資料增量可通過定期抽取或實時同步的方式從關系型資料中完成資料同步。具體實施的架構,如圖2所示,圖2中所指核心業務及周邊業務是根據具體、符合此種業務與邏輯關系的情況而定的,雲上業務系統和雲下業務系統線上業務庫沒有任何資料或接口間的調用關系,雲上業務的通路均由關系型資料庫支撐。

城市軌道交通系統遷移至雲平台方案研究

圖 2 結構化資料雲遷移方案示意

城市軌道交通系統遷移至雲平台方案研究

下載下傳: 全尺寸圖檔 幻燈片

4.2 異構資料庫改造雲遷移

異構資料庫改造雲遷移主要包含2部分。

(1)依賴于原有系統提供資料支援的周邊業務改造雲遷移。

(2)原有的系統部分統計分析功能改造業務雲遷移。

異構資料雲遷移的前提條件是充分調研平台系統各個業務子產品之間的調用關系,優先遷移沒有業務調用關系或業務調用關系較少的業務子產品,并且需要根據業務通路的特點合理選擇關系型資料庫、分析型資料庫、大資料計算服務,依照從簡單到複雜的原則逐漸完成整個線上業務系統的異構改造雲遷移。實作雲遷移的業務處理邏輯和資料通路功能全部在雲平台完成。具體實施的政策,如圖3所示。

城市軌道交通系統遷移至雲平台方案研究

圖 3 異構資料庫雲遷移方案示意

4.3 資料同步雲遷移

完成前兩步的雲遷移改造後,利用分布式資料庫服務繼續對業務系統進行優化。主要涉及2個方面的内容。

(1)使用分布式關系資料庫實作關系型資料庫節點的動态可擴充性。

(2)基于企業級分布式應用服務進行微服務化改造。

最終實作業務系統在雲端的部署狀态。雲上的最終實施架構以及遷移後城軌雲平台最終架構如圖4、圖5所示。

城市軌道交通系統遷移至雲平台方案研究

圖 4 雲遷移後業務邏輯

城市軌道交通系統遷移至雲平台方案研究

圖 5 雲平台遷移前後架構對比

天津中心城區華苑控制中心二期工程項目正處在實施階段,從雲平台遷移前後架構對比來看,項目拟通過城軌業務系統及資料的雲平台遷移。

(1)提高資源使用率,降低建設營運成本。

(2)實作對各條線路的統籌協調、統一運維,并借助雲平台的高可靠、可擴充性、資源複用、資料共享等優勢,不斷提升天津城市軌道交通的營運資訊化管理水準,提高運能、降低成本。

5. 結束語

城軌雲平台是資訊化時代城軌營運管理的重要手段,建設城軌雲平台可以顯著提高資源的使用率及控制中心的營運效率。但雲遷移并非易事,除了本文所提出的方面之外,還需要考慮的因素很多,比如成本優化、額外的安全隐患以及遷移後的業務資源消耗等,這些都需要具體問題具體探讨[14]。切忌為了遷移而遷移,應遵循與其他複雜項目一樣的原則,要有系統的規劃和适當的準備。本文提出的城軌業務系統統一逐漸遷移至城軌雲漸進式方案,不僅可以降低雲遷移過程的風險,還可以幫助問題追蹤,為目前國内廣大城軌業務系統遷移雲需求提供具體的借鑒與參考。

繼續閱讀