基于云平臺和微服務架構的城市軌道交通AFC系統

張義鑫，林 磊，張 寧，何鐵軍，陸 斌

（1. 北京城建設計發展集團股份有限公司，北京 100037；2. 南京地鐵建設有限責任公司，南京 210017；3. 東南大學ITS研究中心軌道交通研究所，南京 210018；4. 南京熊貓信息產業有限公司，南京 210012）

近年來，新型互聯網移動支付在地鐵中得到了廣泛應用，多元化的過閘方式推動 AFC(automatic fare collection system，自動售檢票)系統朝著扁平化的方向發展。2020年3月，中國城市軌道交通協會發布了《中國城市軌道交通智慧城軌發展綱要》，綱要中明確了城市軌道交通到 2025年的發展目標。其中和 AFC系統緊密相關的主要有實現無感支付等新型支付方式的普遍應用；實現城市軌道交通網絡化運營；完善城軌云與大數據平臺的體系建設和應用落地等[1]。

在城市軌道交通朝著智慧化發展這一趨勢下，AFC系統需要對傳統系統架構和建設模式進行調整[2]。將云計算、大數據等新型技術應用于AFC系統可解決硬件資源浪費、系統維護成本高等諸多弊端，乘客可使用無感支付、生物識別等新型互聯網方式過閘，地鐵運營方可利用數據挖掘、清洗等技術獲得更多有價值的數據和報表用來輔助決策、實現智慧運營[3]。從智慧城軌引入大量新型業務和軟件開發的角度考慮，AFC系統上云后，系統業務需求眾多，采用傳統的單體架構會帶來諸多不便，引入微服務架構將AFC系統業務拆分成多個微服務，后續改進和開發的微服務可單獨部署，適用于地鐵不斷新建線路和擴展新型業務的情況。基于上述優點，在傳統AFC系統架構的基礎上引入基于云平臺和微服務架構的城市軌道交通AFC系統以適應“互聯網+”新型支付和智慧城軌的發展要求。

1 AFC系統現狀分析

傳統AFC系統按照地鐵運營組織模式進行劃分，分為乘車憑證層、車站終端設備層、車站計算機系統層、線路中央計算機系統層、清分中心層。傳統5層架構內部封閉，安全性高，具有一定伸縮性，且各層次分明、功能清晰，各站點、各線路均可獨立運行，不受其他線路建設工期影響。目前中國大部分城市的AFC系統仍采用這種傳統架構，傳統5層架構如圖1所示。

圖1 傳統AFC系統架構Figure 1 Traditional AFC system architecture

1.1 傳統AFC系統分析

傳統AFC業務如表1所示，主要業務包括運營管理、票務管理、清分管理、運營維護管理、賬戶管理、數據管理、發布信息管理、設備認證管理等。

表1 AFC 系統業務分析Table 1 Business analysis of the AFC system

傳統AFC系統5層架構存在數據冗余、資源利用率低、建設成本高、數據通信等問題。

1) 數據冗余。地鐵交易數據在車站層、線路中心層、清分中心層系統均有備份，造成了數據極大冗余，同時需要定期維護各層級系統數據庫，提高了管理成本。

2) 資源利用率低。每個車站、線路中心均獨立建設服務器，部分站點和線路服務器利用率低造成資源浪費。

3) 建設成本高。傳統AFC系統在每條線路均建設線路中心系統，線路中心建設成本高。

4) 數據傳輸問題。傳統5層架構層級復雜，在網絡化運營和新型支付方式應用的情況下，交易數據需要層層傳輸，延時大。

1.2 新型互聯網支付分析

在智慧城軌背景下，技術革新日新月異，AFC系統涌入大量新技術，傳統AFC系統5層架構已無法滿足智慧城軌背景下的需求[4]，乘客使用互聯網支付方式過閘時，為獲取用戶支付授權，AFC系統須與第三方支付平臺進行實時交互驗證完成支付；乘客使用無感支付、生物識別等新型支付的情況下，進站時將交易記錄暫存于后臺服務器，待乘客出站時進行實時驗證，這些對AFC系統的網絡安全性、網絡實時性提出了嚴格要求。因此，有必要在傳統5層架構的基礎上進行調整，構建一個同時兼顧傳統AFC系統業務需求和新型支付需求的扁平化和實時化的AFC系統。

1.3 AFC 系統應用云技術的必要性

隨著城市軌道交通的不斷擴建以及城市人口的增多，選擇軌道交通出行的乘客數日益增多，移動支付技術的普及使得大部分乘客采用新型支付方式乘坐地鐵，這要求AFC系統能夠在日均處理百萬甚至千萬級別客流情況下能有很好表現。云計算技術可保證AFC系統運行效率和質量，利用云平臺統一管理計算機等系統設備提高系統管理效率、管理客流大數據、提高運營質量。在提高系統管理效率方面，構建云平臺統一部署應用服務，應用虛擬化技術提升設備資源利用率，利用負載均衡技術保證資源充分利用，方便技術部門更好地管理AFC系統。在提高運營質量方面，利用分布式存儲實現對全網以及各個車站數據的管理，方便運營部門對數據的集中管理，另一方面利用數據挖掘和分析技術處理實時客流和長期客流，輔助運營部門決策，實現智慧化運營[5]。

2 單體架構和微服務架構

在搭建基于云平臺的 AFC系統時，考慮兩種方案，第1種是采用傳統單體架構搭建云平臺，將AFC系統業務看作一個單體應用；第2種是采用微服務架構，將AFC系統業務拆分成多個微服務，使用微服務架構搭建云平臺。微服務架構相較于單體架構更易于維護和擴展，具有低耦合、高內聚等特征[6]。目前越來越多的企業云平臺采用微服務架構替代傳統單體架構，下面對單體架構和微服務架構進行分析。

如圖2所示，單體架構將所有的業務功能整合在一起，部署在統一的服務端應用。前端接口收到用戶請求后，將請求發送至服務端應用，服務端應用擁有統一的數據庫，通過與數據庫進行交互完成用戶請求，再將處理結果反饋至前端接口。

圖2 單體架構Figure 2 Monolithic architecture

如圖3所示，微服務架構將系統業務功能劃分成多個細粒度的微服務，這些微服務部署和運行在獨立的容器中，擁有獨立的數據庫，當前端接口收到用戶請求時，根據請求類型調用一個或多個微服務實例進行響應，多個微服務實例協作完成用戶請求。

圖3 微服務架構Figure 3 Microservice architecture

2.1 組件化

單體架構將系統劃分為前端、服務端、數據庫等模塊，服務端將業務功能統一部署實現組件化。微服務架構的組件化則是通過系統功能劃分出的微服務實現，微服務間耦合性不高，微服務間通信采用輕量化方式[7]。

2.2 部署和擴展

傳統單體架構只能整體部署和擴展業務，對某項業務進行修改或是擴展新業務時須對系統整體修改然后部署。微服務架構的擴展以單個微服務為單位，在改善某個微服務時，只需對該微服務功能進行修改，在擴展功能時只需部署單個或多個微服務，相較于傳統單體架構，部署和擴展更為方便[6]。

2.3 數據管理

傳統單體架構將數據集中存儲在一個數據庫中進行管理。微服務架構采用分布式數據管理，每個微服務有獨立數據庫，微服務間進行數據訪問時須通過微服務發布的接口，不能直接訪問。傳統單體架構和微服務架構的對比如表2所示。

表2 單體架構和微服務架構比較Table 2 Comparison of monolithic architecture and microservice architecture

2.4 容器化技術

采用傳統方式部署微服務時會帶來部署速度慢、資源利用率低等問題，容器化技術可保證微服務能高效部署和運行在云平臺中，把容器作為微服務實例運行的平臺。

在部署方面，容器技術解決了將微服務直接運行在虛擬機上啟動速度慢、利用率不高的問題，作為一款輕量化應用，容器的鏡像構建速度和運行速度非常快，能快速部署微服務。

在資源利用方面，容器技術不需要過多的設備資源，可以在物理機或者虛擬機上同時運行多個容器以部署數量更多的微服務實例，同時容器作為微服務執行環境，不依賴外部資源，而在虛擬機上直接運行微服務需耗費很多硬件資源，且部署耗費的成本更高，資源利用率低。

在容器管理方面，可采用諸如Kubernetes的集群管理工具，可監控實例運行狀況，在容器或節點發生異常時自動重啟或更換節點，根據系統負載值自動調整容器數量，一旦出現問題，集群管理工具會恢復更改，實現版本回滾，搭建開發和測試環境可以通過鏡像實現。

因此容器化技術是部署微服務的明智選擇，容器技術簡化了微服務部署流程，提高了資源利用率，降低了成本，相比傳統的虛擬機運行微服務優勢顯著。

3 基于云平臺和微服務架構的AFC系統

基于上述對傳統單體架構和微服務架構的對比分析，在智慧城軌背景下，不斷有新技術涌入，業務功能需持續調整和擴展，單體架構存在諸多缺陷，盡管微服務架構也存在缺陷，但容器化技術可解決微服務部署的難題，且微服務架構能有效解決單體架構存在的問題，因此使用微服務架構部署方案可為云平臺提供后臺服務。

基于云平臺和微服務架構的 AFC系統架構根據業務功能劃分出多個微服務，構建一個扁平化、實時化、部署和擴展靈活、資源利用率高的AFC系統。新型架構分為4層，第1層依舊是乘車憑證層，是乘客所持有的支付媒介；第2層是車站終端設備層，實現數據采集和乘客交互；第3層是車站計算機層，實現與云平臺的數據交互及車站系統的管理；第4層為云平臺層，取代了原有的 ACC、LC層級，部署 AFC系統業務，提供部署業務所需的軟硬件，系統架構如圖4所示。

圖4 基于云平臺和微服務架構的AFC系統架構Figure 4 AFC system architecture based on cloud platform and microservice architecture

3.1 云平臺設計

云平臺架構包括IaaS (Infrastructure as a Service，基礎設施服務)、PaaS (Platform as a Service，平臺服務)、SaaS (Software as a Service，軟件服務) 3個部分，如圖5所示，其中IaaS層即基礎設施層，PaaS層包括數據層和微服務層，SaaS層即應用層，下面對具體的每一層級進行介紹。

圖5 基于微服務部署的云平臺架構Figure 5 Cloud platform architecture based on microservice deployment

IaaS層即基礎設施層，起支撐作用，將云平臺所需的硬件設備集中，抽象出虛擬化資源池，提供算力、數據存儲、網絡服務等基礎資源，支撐AFC系統的運轉。

PaaS層可細化為數據層和微服務層兩個層級。數據層為微服務提供數據訪問接口，實現數據對接和共享，具體負責各類數據的存儲，包含的數據庫主要有Redis分布式緩存數據庫、關系數據庫(如 SQL Server、MySQL 等)、文件存儲數據庫、數據倉庫等；微服務層根據業務功能劃分出多個微服務，通過調用和組合微服務來滿足AFC系統的功能需求，微服務層又分為基礎微服務、共享微服務中心、業務微服務3個部分。

1) 基礎微服務為上層業務提供基礎支撐功能，包括身份認證、權限管理、數據安全加密等。身份認證對終端用戶進行身份認證，保護終端的安全性。權限管理對用戶權限進行管理，避免發生誤操作和越級操作。數據加密為數據傳輸和數據存儲提供加密解密支持，有效保障了數據安全。

2) 共享微服務中心由網關、注冊中心、配置中心和服務監控等組成，網關為系統內部微服務提供外界訪問的統一入口，網關有效地在系統內部和外界之間形成一道屏障，有效地防范系統外部帶來的安全隱患，當外部發來請求時，網關判別外部請求的權限，有效保障系統內部安全性；注冊中心用于微服務的注冊和發現，實現服務消費者對微服務的發現和調用；配置中心對微服務的配置信息進行統一管理，通過各微服務實時同步過來的信息實現動態更新；服務監控主要分為對微服務本身的監控和對整個調用鏈的監控兩部分，保障微服務的穩定運行。

3) 業務微服務結合AFC系統傳統業務和新型互聯網支付需求將業務功能細化，劃分出各類微服務，通過微服務之間的組合和調用完成業務需求。

SaaS層即業務層，為使用者提供服務，按模塊分為數據管理、賬戶管理、清算管理、維護管理、發布管理、票務管理、交易管理、云平臺管理8個模塊。模塊功能通過微服務層中微服務的相互調用、組合實現。

3.2 系統功能組成

圖6詳細地展示了AFC系統功能以及拆分出的微服務，數據管理功能由數據采集服務、數據分析服務、數據共享服務、數據可視化服務支持；賬戶管理功能由注冊服務、設備賬戶服務、乘客賬戶服務、業務賬戶服務、密鑰服務支持；清算管理功能由對賬服務、清分模型服務支持；維護管理功能由設備維護服務、人員調度服務、參數服務支持；發布管理功能由查詢服務、客流監視服務、設備監視服務、營收監視服務支持；票務管理由票卡服務、現金服務、發票服務、票務參數服務、TP服務支持；交易管理功能由交易上傳服務、交易處理服務、支付服務、驗證服務、異常處理服務支持；云平臺管理功能由網絡服務、備份服務、日志服務、容災與恢復服務支持，單個微服務擁有獨立的數據庫。

圖6 微服務劃分業務功能Figure 6 Business divisions of microservices

4 微服務治理方式

AFC系統業務眾多且訪問量很大，由系統功能拆分出的眾多微服務在調用時勢必會出現眾多問題，因此需要進行服務治理，保證服務質量和系統正常運轉。

4.1 服務注冊中心

在運行過程中，微服務實例處于動態變化的過程，存在被銷毀、重新定位的情況，因此服務之間需要感知到彼此的存在，服務發現和注冊中心實現了這一功能。服務注冊中心在服務啟動時完成統一注冊和服務訂閱。服務注冊中心根據服務提供者和消費者實時傳輸的信息完成各個微服務的狀態更新，實現了包括服務注冊、發布、服務監控等功能[8]。

4.2 負載均衡

在微服務架構下，一個微服務部署多個服務實例來提供業務支持。采用負載均衡算法來合理選擇服務實例保證每個實例所處理的請求數目大致相同。負載均衡有兩種方式，分別是客戶端負載均衡和服務端負載均衡，考慮到負載均衡的性能、穩定性和安全性，采用服務端硬件負載來協調 API(application programming interface，應用程序接口)網關請求轉發和微服務間的調用。特別是在地鐵高峰期，可以有效保證服務消費者發出的請求得到快速響應。

4.3 服務容錯

在網絡異常或者訪問量過大的情況下，會發生網絡連接超時、請求失敗、服務過載等問題，需要考慮容錯問題，保證出現異常時系統能夠正常運行[9]。若AFC系統因網絡超時或異常原因導致服務無法訪問，可以將服務數據暫存在本地，同時與此項交易數據相關的事務都將終止，待網絡恢復后再進行處理更新，其他各項事務不受影響正常進行。若服務過載引起異常，例如在高峰期，各個站點交易記錄暴增可能引起服務過載，可以暫時停掉一些不重要的業務，保證核心服務(進出站交易處理事務)正常運行。

4.4 服務通信

微服務架構下的通信方式有同步通信和異步通信。同步通信模式指的是服務端接收到客戶端請求后立即響應，客戶端會一直等待直至獲取服務端響應，在基于線程的應用中可能會引起堵塞；異步通信模式指服務端收到客戶端請求后根據情況對客戶端采取立即響應或者稍后響應的方式，客戶端等待響應時不會阻塞線程，適用于響應時間較長的情況，故采用同步、異步相結合的通信方式以提高系統的運行效率，實現對數據層各數據存儲中心進行并發訪問。

4.5 數據一致性管理

在微服務架構中，單個服務的事務可以使用ACID(atomicity、consistency、isolation、durability，數據庫事務正確執行的4個基本要素的縮寫)事務，保持數據的一致性，在跨越多個微服務進行數據操作時可采用Saga(長時間運行的事務)來維護數據一致性，一個Saga表示更新多個服務中數據的一個系統操作，Saga由多個本地事務組成，每一個本地事務負責更新它所在服務的私有數據庫。完成一個本地事務后會觸發另一個本地事務的執行，當某項后續事務失敗后會對前向的已經執行的事務進行補償，撤銷之前已經執行的事務的影響。

4.6 日志中心

微服務架構在運行過程中系統內部以及調用過程會出現異常，需及時排查，查看日志文件需從微服務節點獲取，而這些節點是分散的，且微服務交互鏈路較長，通過查看這些分散的日志文件來找到問題根源很不方便，需要借助日志中心來定位處理異常。目前ELK(elasticsearch、logstash、kibana 3個開源框架縮寫)框架是微服務系統的主流日志框架，ELK由日志收集處理、日志存儲、日志可視化分析3個部分組成。日志收集處理組件分布在各個節點上搜集日志和相關數據，進行分析處理后發送給服務器并由日志存儲組件將數據進行壓縮存儲，同時提供接口供用戶進行查詢，日志可視化分析組件幫助用戶更直觀地查詢日志，生成各類數據報表，輔助定位和決策。

5 基于云平臺和微服務架構的 AFC系統與既有系統融合

基于云平臺和微服務架構的AFC系統，前期可先在部分新建線路車站進行試點研究，在試點車站應用并測試新架構下系統的運行狀況，發現問題后優化現有架構。考慮到現階段大部分城市的地鐵線網比較成熟，傳統AFC系統5層架構不可能在短期內直接轉變成新架構，因此需要結合現有架構和新架構分階段地合理引入云平臺，如圖7所示。

第1階段，保持已有線路的5層架構不變，在新建線路的系統建設中，不再設清分中心和線路中心，新線路形成乘車憑證—車站終端設備—車站中心—云平臺4層架構。第2階段，在采用4層架構的新線路運營較為成熟后，將已有線路的清分中心業務逐步遷移至云平臺；待業務全部轉移后，取消清分中心層級，在AFC系統已有線路形成乘車憑證—車站終端設備—車站中心—線路中心—云平臺5層架構，其中清分中心業務被整合至云平臺中。第3階段，待清分中心業務遷移至云平臺的5層架構的AFC系統積累長時間的運營經驗，系統運營完全成熟后，將既有線路的線路中心業務逐步轉移至云平臺層中，形成全線網乘車憑證—車站終端設備—車站中心—云平臺的 4層架構，實現AFC系統的扁平化。

6 微服務架構應用的挑戰

將微服務直接應用于云平臺會帶來嚴重問題，需要結合新的舉措消除這些缺陷，下面從運維成本、接口匹配兩個方面簡要介紹。

1) 從運維成本角度考慮。傳統單體架構在部署時采用一小片應用服務區集群來部署整體應用，運維成本較低。而一個整體系統包含多個微服務，若采用虛擬技術將微服務部署在多個虛擬機上會產生耗費時間長、管理成本高、資源利用率低等問題。解決措施：采用容器技術，在容器中部署微服務，化解了部署速度慢、運維成本高等一系列問題，實現與微服務的完美結合。

2) 從接口匹配角度考慮。將整體系統劃分為多個微服務組件會產生多個接口，系統調用某項功能需要保證微服務組件接口的正確匹配和組合，避免微服務架構集成點過多帶來的風險。解決措施：將微服務注冊到注冊中心，需要調用某項服務時在注冊中心找到服務即可，服務實例銷毀和狀態信息會在注冊中心同步更新。

除了以上2個問題之外，將微服務應用于AFC系統還存在很多問題，例如：微服務采用分布式系統，分布式事務管理網絡故障和延遲、網絡安全是不可避免的問題；各微服務間存在依賴關系，修改某個微服務時所有使用該接口的微服務都需要調整；對AFC系統業務的微服務劃分是否合理；服務監控的開銷龐大，微服務架構中需要對系統劃分出的眾多微服務以及整個鏈路進行監控。

因此使用微服務架構來搭建AFC系統云平臺時，需要根據實際情況采用具體方案解決，如何系統且有效地解決引入微服務所帶來的問題仍是一大難點。目前，昆明地鐵4號線已經嘗試使用城軌云平臺搭載包括AFC系統在內的多個應用系統，將業務以微服務的形式部署在云平臺中，為AFC系統引入云平臺和微服務以實現智慧化、網絡化運營提供了經驗和解決方案。

7 結語

在城市軌道交通的“智慧化”發展趨勢下，采用新型AFC系統架構是滿足新型業務需求、實現網絡化運營的必然選擇。首先分析了傳統AFC系統5層架構和單體架構存在的缺陷及新型互聯網支付特點，設計基于云平臺和微服務架構的AFC系統，然后從云平臺層按功能劃分的微服務切入，探討基于云平臺的AFC系統實現方案以及微服務治理的關鍵技術，進而從實際出發，考慮現有系統逐步推進至基于云平臺和采用微服務部署的AFC系統的過程，提出分階段地應用云架構的方法，將傳統AFC系統架構逐步轉變成新型架構，最后分析AFC系統引入微服務架構帶來的挑戰，需根據項目實際情況實施解決方案。為AFC系統引入云平臺和微服務架構以適應未來的城市軌道交通朝著智慧化方向發展提供了參考。