王瑞宗 陸鑫 陳玉燕

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

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

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

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

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

1 傳統五層架構

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

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

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

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

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

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

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

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

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

2 三層云架構可行性分析

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

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

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

3 三層云架構設計方案

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

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

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

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

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

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

4 三層云架構改造方案

4.1 原車站層改造方案

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

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

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

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

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

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

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

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

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

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

5 結論

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