軌道交通自動售檢票系統三層云架構設計

王瑞宗 陸鑫 陳玉燕

（廈門軌道交通集團有限公司 福建省廈門市 361010）

軌道交通自動售檢票（AFC, Automatic Fare Collection system）系統多年來采用的是傳統的五層架構，從車票、終端設備（SLE, Station Level Equipment）、車站計算機系統（SC, Station Computer）、線路中央計算機系統（LCC, Line Central Computer）一直到頂層的軌道交通清分中心系統（ACC, AFC Clearing Computer）。這種架構很好的滿足了軌道交通自動售檢票系統的業務需求，通過層級的劃分來使得每個層級的功能相對獨立，便于系統維護和建設。

但是，隨著服務器算力的逐年提升，車站級和線路中心級服務器的運算能力就無法得到充分的發揮，不同客流的車站的服務器算力的分布也很不平衡，造成了服務器算力的浪費。如何充分的利用服務器的算力，對降低系統的建設成本以及能耗有非常重大的意義。

隨著云計算技術在軌道交通領域的廣泛應用，我們可以使用服務器集群組成資源池，并使用容器技術提高服務器機計算資源的利用率。這樣，在軌道交通自動售檢票系統中，就不需要再使用那么多的服務器，由云平臺來平衡算力。

本文將提出軌道交通自動售檢票系統新型三層云架構的設計方案，該方案在廈門市軌道交通2 號線自動售檢票系統中已經通過系統驗證。

1 傳統五層架構

軌道交通自動售檢票系統中一直使用的是傳統的五層架構，傳統五層架構包括車票、終端設備、車站計算機、線路中心計算機和清分中心這五個層級。架構圖如圖1所示。

圖1：傳統AFC 系統五層架構圖

終端設備：車站終端設備包括自動售票機（TVM, Ticket Vending Machine）、半自動售票機（BOM, Booking Office Machine）、自動檢票機（AGM, Automatic Gate Machine）及便攜式檢票機（PCA, Portable Card Analyzer）等設備組成。終端設備接收車站計算機系統下發的參數及命令，完成規定操作及信息提示；生成并上傳全部交易數據、審核數據及日志數據并按要求存儲；完成設備故障自診斷和故障提示；在發生通信故障時能獨立運行，并實現數據導出功能，通信故障恢復后數據自動上傳。

車站計算機：對本站終端設備上傳的數據進行統計和匯總，并將數據上傳給線路中心計算機。同時，車站計算機接收來自線路中心計算機的實時通信報文和參數文件，包括控制命令和模式等；

線路中心計算機：對本線路各車站上傳的數據進行統計和匯總，并將數據上傳到清分中心。同時，接收來自清分中心下發的參數、命令及時鐘同步信號并完成本線路的時鐘同步，負責將參數下發給車站計算機系統，能獨立實現所轄線路AFC 系統的運營管理等。

清分中心：制定AFC 系統運營的各項規則，包括車票、票價、清算、對帳業務規則、車票使用及調配管理、運營模式管理、運營參數管理、安全管理與授權、終端設備統一乘客服務界面、系統接口和編碼規則等；統一發行軌道交通車票及調配和跟蹤，實現軌道交通各線路統一的車票發行及車票管理；通過其全局票務與安全系統支撐各線路AFC 系統運行，負責收集、統計、分析、查詢運營數據，負責收益在軌道交通系統不同線路之間的清分，實現軌道交通系統與其他行業清算中心系統間的清算、對帳；下發各類參數和命令，確保整個AFC 系統正常、安全運營；統一管理AFC 系統密鑰。

在傳統五層架構中，各個車站設置一臺車站服務器，由車站服務器來負責車站計算機的應用和數據傳輸。但是，在實際使用中，服務器應用效率比較低，以廈門市軌道交通2 號線為例，車站服務器的平均CPU 使用率皆低于10%，平均最大CPU 使用率低于15%。車站服務器資源在大多數時間是閑置狀態。并且，平均CPU使用率在不同車站的分布也很不均衡，高客流車站的CPU 使用率一直處于相對較高的水平。

同時，當建設新線時，需要采購大量的中間層級（SC 和LCC層級）的服務器、網絡設備和安全設備，投資成本巨大。而且，中間層級的存在也增加了系統的故障點和維護成本。

為了減少投資和維護成本，并提高系統資源的利用率，對原有的五層架構進行改造勢在必行。

2 三層云架構可行性分析

當前，云計算技術的發展已經相當的成熟，在鄭州等城市也有云平臺的成功的應用案例，故在廈門市軌道交通系統架構的改造中，使用云平臺技術將不存在技術上的風險。

因此，在進行三層云架構設計時，考慮在頂層部署云平臺。

原有的五層架構將系統分為功能獨立的層級，當層級之間通信斷開時，各個層級可離線運行一段時間。系統改成三層云架構以后，車站終端設備對系統網絡的依賴程度增加了，這時，我們可以對車站和線路的網絡通信設備使用冗余配置，以增加系統網絡的穩定性。

3 三層云架構設計方案

基于以上現實情況，我們在廈門市軌道交通2 號線進行了系統架構的升級改造，將原有的五層架構中的車站計算機、線路中心計算機和清分中心這三個層級進行了合并。對車站服務器和線路中心的服務器進行利舊處理，將服務器全部搬遷到清分中心。

為了充分發揮這些服務器的算力，提高系統的穩定性和擴展性，我們將搬遷來的服務器和清分中心的服務器改造成云平臺。

主流的云平臺技術分為虛擬機和容器云兩種，針對廈門市軌道交通的特點，以及原有系統中車站服務器配置較低的現實情況，我們使用了比虛擬機資源利用率更高的容器云技術。

原有的清分中心整和了生產系統的所有業務功能，升級為數據管理中心，改造后的系統架構圖如圖2所示。

圖2：AFC 系統三層云架構圖

AFC 系統三層云架構將從多層級到扁平化的轉變，在保留系統的功能性、降級保障、可用性前提下，盡量簡化系統架構，使系統運行更敏捷，管理更方便。

4 三層云架構改造方案

4.1 原車站層改造方案

在原有的五層架構中，車站服務器、車站三層交換機和緊急按鈕控制器部署在設備室的機柜內，車站服務器被搬遷到清分中心后，車站三層交換機和緊急按鈕控制器被保留下來。為了增強車站網絡的穩定性，我們在設備室機柜內增加了一臺三層交換機，和原來的三層交換機做冗余配置。當一臺三層交換機故障時，另一臺三層交換機立即接管工作，以保證車站終端設備和中央的網絡通信。

原有的緊急按鈕控制盒是通過RS232 通信線連接到車站服務器的，在車站服務器被搬遷后，我們使用232 轉網口的轉換器，將來自綜合監控系統的串口線連接到車站三層交換機上，來實現綜合監控和AFC 系統的接口功能。

在原有的五層架構下，車站系統和中央網絡通信中斷后，車站計算機將接管所有的業務。在完成三層架構改造后，如果車站和中央因為通信網故障而斷網，為了實現原有的車站計算機的功能，我們進行了如下的改造。

首先，更新終端設備的參數，使得終端設備增加一個上級節點，即車站工作站的網絡節點，在終端設備監測到和中央斷網以后，將上級節點切換到車站工作站。當終端設備監測到和中央的通信恢復以后，將上級節點切換到中央資源池中的網關地址，向中央虛擬機節點發送數據和接收參數。

同時，在車站的票務工作站上，部署一套車站計算機的應用軟件和MySQL 數據庫。部署在車站工作站上的車站計算機軟件定時監測和中央的網絡通信狀態，在監測到和中央的網絡通信連接斷開時，啟動車站計算機的應用軟件，包括通信服務，數據服務器和參數服務等子應用。

在車站離線狀態下，車站工作站將接管車站的所有業務，并采集終端設備的各類數據，存放在車站工作站的MySQL 數據庫中。

車站工作站的應用軟件在監測到和中央的網絡通信恢復以后，將車站斷網期間采集的各類數據和操作日志發送給中央服務器。

4.2 線路中心和清分中心的改造方案

原線路中心的應用服務器，數據庫服務器和存儲都搬遷到中央。線路中心的冗余配置的核心交換機保留在線路中心，作為本線路的匯聚交換機來使用。

各個線路中心的應用服務器作為資源池服務器，劃歸資源池進行統一管理。數據庫服務器和存儲，依然用來安裝數據庫管理軟件和備份軟件，作為分布式存儲來使用。

5 結論

本文通過對各個層級的改造方案的描述，詳細論述了自動售檢票系統中一種現實可行的三層架構的設計方案，對以后自動售檢票系統架構的升級改造提供了參考。