基于云平臺的新一代智慧型 AFC系統方案應用研究

呂 歡，吳 松，郭 戈，盧肖靜

（中鐵電氣化局集團有限公司，北京 100166）

1 引言

隨著云技術的發展以及自動售檢票（AFC）系統用戶需求的提升，傳統AFC系統工程建設中線路中心、車站服務器所采用的物理機模式因其資源利用率低、物理位置分散不便于維護和管理等缺點已不適用當前的系統需求。基于云計算的分布式處理系統，采用PC集群及開源的分布式數據庫，可使硬件投資大幅下降。用戶可根據業務負載情況動態調整虛擬機資源的使用情況，通過在線升級服務器配置，解決因客流增長引起的中央計算機/交易服務器和部分車站的計算機系統資源超載的現象，避免因大客流換乘站系統CPU長時間滿負荷運轉影響交易上傳。

根據不同的需求建立數學模型，分析挖掘AFC系統有價值的信息，實現運維智能化、乘客服務便捷化是智慧型AFC系統的需求。AFC系統運行需要對大量的實時數據（客流數據、票卡及票庫數據、設備狀態數據、運營模式數據以及聯機數據）進行計算分析。由于依托云技術的大數據平臺可實現AFC系統的業務數據分析，因此基于云平臺的新一代智慧型AFC系統的研究應用也是目前城市軌道交通建設關注的重點。

2 云平臺結構概述

城軌云平臺由中心級云平臺和站段級云節點構成。中心級云平臺按不同業務應用、大數據平臺劃分虛擬數據中心（VDC），通過邏輯隔離技術為各業務系統靈活計算、分配存儲和網絡資源。站段級云節點同樣按相關業務應用劃分VDC，為各業務系統提供資源。中心級云平臺、站段級云節點統一規劃、部署基礎設施即服務（IaaS），根據應用需求適時部署平臺即服務（PaaS）、軟件即服務（SaaS）。

3 新一代智慧型 AFC 系統方案

3.1 新一代智慧型 AFC 系統需求分析

智慧型AFC系統除支持發售實體票卡外，也支持多種類的互聯網票卡，如二維碼票、人臉票、掌靜脈票等。不同票種子系統的服務器虛擬機可以集成鋪設，也可以單獨鋪設，但用戶需要根據業務負載情況動態調整虛擬機數量。同時AFC系統需要根據客流情況調整虛擬機資源的使用，包括離線/在線調整虛擬CPU（vCPU）數量，離線/在線調整內存，離線添加/刪除網卡，離線/在線掛載虛擬磁盤等。如某工程實例，在工程建設前期中央計算機/交易服務器虛擬機CPU及內存資源規劃為8C/16G，大客流換乘站車站計算機系統服務器資源規劃為4C/8G。新線開通后，由于客流量大，中央計算機/交易服務器和部分車站的計算機系統均發生資源超載現象，其中大客流換乘站的計算機系統CPU長時間滿負荷運轉，嚴重影響交易上傳。因此運營結束后在線將中央計算機/交易服務器從8C/16G升級到16C/32G，將大客流換乘站計算機系統服務器從4C/8G升級到8C/16G，解決資源超載問題。

3.2 基于云平臺的新一代智慧型 AFC 系統架構

基于云平臺建設的智慧型AFC系統主要由云、管、端3部分組成。云是城軌云平臺，管是云網絡，端是用戶APP、自動售票機、自動檢票機等車站終端設備。云平臺對AFC業務應用系統所涉及的計算、存儲、網絡及安全等資源進行統一規劃、部署和管理。基于云平臺建設的智慧型AFC系統將線網級的清分中心、互聯網票務平臺、多線路中心以及各車站計算機系統應用軟件均部署于中心級云平臺。不同于傳統模式AFC系統與傳輸系統進行接口，智慧型AFC需與云平臺網絡進行接口，而專用的控制器、接入設備、終端設備等由AFC業務應用系統統一部署和管理。基于云平臺的新一代智慧型AFC系統結構分為5層，架構圖如圖1所示。

圖1 AFC系統云部署架構

3.3 基于云平臺的新一代智慧型 AFC 系統方案

3.3.1 清分中心以及互聯網票務平臺上云方案

一個城市中的軌道交通一般包含多條線路，通常情況下分別由多個運營單位運營管理，而各線路之間又相互連接貫通，因此城市軌道交通清分中心及互聯網票務平臺部署于城軌云上則非常必要。在清分中心以及互聯網票務平臺上云方案中，清分中心以及互聯網票務平臺對云平臺的資源需求如表1所示。

表1 清分中心以及互聯網票務平臺對云平臺的資源需求

3.3.2 線路中心 AFC 系統業務上云方案

在線路中心AFC系統上云方案中，線路中央計算機系統（LC）虛擬機對云平臺的資源需求如表2所示。線路中心AFC系統中的非云化設備（加密機、編碼分揀機、打印機等）部署可采用獨立組網方式，與中心級云平臺的物理接口界面宜位于中心級云平臺外部接入區交換機外側。

表2 單線路LC系統虛擬機的資源需求

3.3.3 車站級 AFC 系統業務上云方案

（1）車站級AFC系統業務上云方案。站段云節點主要有4種實施方案：方案一，僅AFC中央業務系統部署于中央級云平臺，車站業務按傳統方案設置；方案二，AFC車站業務系統部署于中央級云平臺，站段云節點設置降級服務器，車站與中心網絡斷開的情況下，由站段云節點降級服務器支持AFC系統降級運營；方案三，AFC車站級業務部署于站段云節點，站段云節點設置邊緣計算服務器；方案四，AFC車站業務系統部署于中央級云平臺，站段云節點不設置服務器。

（2）方案比選。方案一，AFC中心系統由云平臺安全生產網承載，規模較小，車站相關業務系統未上云，技術方案較成熟，但未完全達到資源整合的目的；方案二，站段云節點僅在降級的情況下使用，雖然可靠性較高，但造成一定的資源浪費；方案三，站段云節點設置云節點服務器，承載AFC業務車站級系統，不改變原AFC系統架構，基于云-管-端的架構，實現邊緣計算，數據上傳的功能；方案四，相對方案三總體節約計算資源，但車站缺少降級服務，對傳輸網絡的可靠性要求極高。經過以上比選可知，目前AFC業務上云采用方案三最為安全可靠、經濟合理。

（3）車站計算機系統（SC）虛擬機對云平臺的資源需求如表3所示。

表3 SC虛擬機對云平臺的資源需求

（4）車站AFC系統的非云化設備部署方案。車站AFC系統的非云化部署設備宜采用獨立組網方式，與車站級云平臺的物理接口界面宜位于車站級云節點匯聚交換機外側。車站服務器云化以后，緊急控制器通過串口連接服務器的傳統方式就不適用當前的接入模式，需進行改進。改進方案有以下2種：方案一，通過串口延長線連接車控室AFC監控工作站進行緊急模式反饋；方案二，定制開發帶網口的緊急控制器連接AFC三層交換機，通過網絡進行緊急模式反饋。從上述方案描述中可見，方案一會增加潛在故障點，可靠性較差，因此在工程實踐中推薦采用方案二。

3.3.4 云桌面系統方案

云桌面系統按照AFC系統業務應用需求為AFC系統提供控制中心以及車站的云桌面服務。云桌面以服務器虛擬化為基礎，允許多個用戶桌面以虛擬機的形式獨立運行。AFC系統云桌面工作站與其他業務系統同時共享CPU、內存、網絡連接和存儲器等底層物理硬件資源，并可避免受到由其他業務系統用戶活動所造成的應用程序崩潰和操作系統故障的影響。在云桌面系統方案中AFC云桌面工作站虛擬機的資源需求如表4所示。

表4 AFC云桌面工作站虛擬機的資源需求

3.3.5 網絡安全等級保護方案

云平臺按照安全等級保護三級（簡稱“等保三級”）建設，并統一提供底層病毒防護。中心級云平臺在各業務系統之間部署云內防火墻，其中安全策略由AFC根據開放的端口類型決定。在安全生產網內部部署入侵檢測設備，用于云平臺的統一入侵檢測，并具備檢測到惡意代碼可報警功能；最外層部署流量探針，用于探測業務系統的異常流量。同時配備網絡審計設備，統一對云平臺各業務系統流量做網絡審計。

基于云平臺部署的AFC系統要滿足網絡安全等保三級的要求，需從以下幾個方面進行安全防護。

在通信網絡安全防護方面，由于云平臺統一對各業務系統流量做網絡審計，AFC系統側則不再單獨配置針對通信網絡安全的防護設備。同時需保證AFC系統網絡與其他專業網絡之間的相互隔離。

在區域邊界安全防護方面，AFC系統須設置運維審計（堡壘機）、日志審計設備。AFC系統控制中心具備網絡安全控制、審計等功能，與云網絡通過物理防火墻進行隔離。AFC系統車站設備同樣通過物理防火墻與云網絡進行隔離。車站物理防火墻需具備入侵防御功能，一旦檢測到惡意代碼，會自動進行丟棄。

AFC系統網絡設備等保方案是在車站及車輛段、控制中心（2臺主備）部署防火墻，在控制中心設置安全服務器，部署安全管理平臺、運維審計、日志審計、漏洞掃描、數據庫審計、防病毒軟件。同時需對車站終端設備進行必要的安全加固。其中控制中心網絡安全設備配置有3種方案：方案一，采用服務器+軟件的模式，該模式可移植性好，可擴展性強，軟件靈活度強；方案二，采用一體機模式，該模式方便，但可擴展性差；方案三，采用分體設備，該模式投資較大。基于以上比選，推薦選擇服務器+軟件方案部署控制中心網絡安全設備。

管理中心安全防護主要通過網絡管理系統、綜合安全管理平臺等機制實現安全防護。AFC系統網絡等保方案設置安全管理平臺，通過平臺對安全設備進行統一管理。AFC系統網絡安全防護系統構成如圖2所示。

圖2 AFC系統網絡安全系統構成圖

4 基于云平臺的新一代智慧型 AFC 系統驗證

4.1 AFC系統軟件部署方案

AFC系統中的線路中央計算機系統部署2臺應用 /交易服務器、2臺數據庫服務器、2臺通信服務器、1 臺存儲設備，并全部部署于中央級云平臺上。每個車站設置1臺車站計算機系統服務器，部署于站段級云平臺上。

基于云平臺的AFC軟件部署步驟為：第一步，開通操作員賬號、部署系統、部署應用服務；第二步，部署中央計算機、車站計算機軟件。

云平臺中央計算機系統及車站計算機系統部署步驟包括虛擬機創建、操作系統部署、基礎軟件部署、中央計算機軟件部署、系統應用軟件（操作系統、軟件工具開發包、消息隊列、數據庫、網絡時間協議（NTP）、AFC應用程序等）部署。其中線路中央計算機系統/車站計算機系統（LCSC）服務器虛擬機部署操作系統（centos7.7、JDK1.8 、mysql5.7.29、rabbitmq3.8.2），云桌面工作站部署操作系統（windows10、chrome、navicat）。實際工程中整個部署周期大概需要10天。

4.2 AFC 系統軟件測試方案

軟件測試通常在軟件部署完成后10天內完成在線測試，測試內容包括中央計算機系統、車站計算機系統的業務測試、功能測試和性能測試。一般情況下，先采用1個中央計算機系統，2個樣板站的模式進行初步部署測試，其后隨著其余各車站的陸續開通，跟隨建設進度逐步進行測試。

4.2.1 中央計算機系統測試內容及目的

中央計算機系統的測試內容主要包括業務測試、功能測試及性能測試，具體測試內容及目的如下所述。

（1）中央計算機數據庫服務器高可用集群測試為驗證中央計算機數據庫高可用集群是否可以正常安裝并正常切換。

（2）外部FTP服務器上傳、下載功能測試旨在驗證中央計算機服務器是否能夠從外部FTP服務器上傳、下載文件。

（3）數據庫備份、恢復測試的目的是為驗證數據庫是否能夠正常備份和恢復。

（4）中央計算機系統與外部系統接口測試中，首先中央計算機系統開啟對外部系統的接口，其次在外部接口模擬機上利用Modbus TCP Client軟件讀取中央計算機系統提供的數據，從而驗證中央計算機系統與對外部系統的接口性能。

（5）時鐘同步測試通過開啟各服務器云桌面的時間同步客戶端，測試客戶端與外部時間源的同步功能。

（6）云平臺虛擬機管理測試通過云管理平臺查看虛擬機狀態，并實現快照及快照恢復。

（7）云平臺桌面終端系統安裝測試，該測試旨在驗證在云平臺桌面終端上能夠正確部署windows10 操作系統及相關軟件。

（8）中央計算機系統軟件功能測試通過部署并啟動中央計算機系統軟件，利用客戶端驗證中央計算機系統軟件是否正常運行。

（9）中央計算機系統性能測試通過模擬全線車站計算機系統同時訪問中央計算機系統的場景，查看中央計算機系統相關服務器的性能。

4.2.2 車站計算機服務器操作系統及相關服務部署測試

（1）SC系統軟件功能測試旨在驗證在車站計算機服務器上是否能夠正確部署操作系統及相關服務。

（2）車站計算機系統性能測試。以車站終端設備（SLE）最多、客流量最大的換乘站為例，測試該站全部SLE設備發起向車站計算機系統的訪問請求，驗證車站計算機系統服務器性能。

（3）云平臺的網絡性能測試。利用網絡測試軟件測試云平臺主機間的網絡性能。

5 結束語

基于云平臺部署的智慧型AFC系統可根據業務需求在線調整服務器虛擬機數量，根據客流狀態調整虛擬機資源配置，相較傳統AFC可減少服務器投資及運維費用，有利于新增票種子系統的部署。本文通過探討清分中心、互聯網票務平臺、線路中心、車站計算機系統基于云平臺的部署方案，并經過多方案比選，推薦清分中心、互聯網票務平臺、線路中心部署于中央級云平臺，車站計算機系統部署于車站接點云的方案為基于云平臺智慧型AFC系統部署的最佳方案。該方案既可滿足智慧型AFC系統用戶的需求，又能滿足在中心與車站網絡斷開的情況下，實現車站降級服務。除此以外本文還探討智慧型AFC系統中非云設備上云以后的改進方案、網絡安全等級保護方案及系統驗證方案，為后期基于云平臺智慧型AFC系統部署提供一些工程經驗。