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

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

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

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

1 AFC系統(tǒng)現(xiàn)狀分析

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

圖1 傳統(tǒng)AFC系統(tǒng)架構(gòu)Figure 1 Traditional AFC system architecture

1.1 傳統(tǒng)AFC系統(tǒng)分析

傳統(tǒng)AFC業(yè)務(wù)如表1所示，主要業(yè)務(wù)包括運營管理、票務(wù)管理、清分管理、運營維護管理、賬戶管理、數(shù)據(jù)管理、發(fā)布信息管理、設(shè)備認證管理等。

表1 AFC 系統(tǒng)業(yè)務(wù)分析Table 1 Business analysis of the AFC system

傳統(tǒng)AFC系統(tǒng)5層架構(gòu)存在數(shù)據(jù)冗余、資源利用率低、建設(shè)成本高、數(shù)據(jù)通信等問題。

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

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

3) 建設(shè)成本高。傳統(tǒng)AFC系統(tǒng)在每條線路均建設(shè)線路中心系統(tǒng)，線路中心建設(shè)成本高。

4) 數(shù)據(jù)傳輸問題。傳統(tǒng)5層架構(gòu)層級復(fù)雜，在網(wǎng)絡(luò)化運營和新型支付方式應(yīng)用的情況下，交易數(shù)據(jù)需要層層傳輸，延時大。

1.2 新型互聯(lián)網(wǎng)支付分析

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

1.3 AFC 系統(tǒng)應(yīng)用云技術(shù)的必要性

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

2 單體架構(gòu)和微服務(wù)架構(gòu)

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

如圖2所示，單體架構(gòu)將所有的業(yè)務(wù)功能整合在一起，部署在統(tǒng)一的服務(wù)端應(yīng)用。前端接口收到用戶請求后，將請求發(fā)送至服務(wù)端應(yīng)用，服務(wù)端應(yīng)用擁有統(tǒng)一的數(shù)據(jù)庫，通過與數(shù)據(jù)庫進行交互完成用戶請求，再將處理結(jié)果反饋至前端接口。

圖2 單體架構(gòu)Figure 2 Monolithic architecture

如圖3所示，微服務(wù)架構(gòu)將系統(tǒng)業(yè)務(wù)功能劃分成多個細粒度的微服務(wù)，這些微服務(wù)部署和運行在獨立的容器中，擁有獨立的數(shù)據(jù)庫，當前端接口收到用戶請求時，根據(jù)請求類型調(diào)用一個或多個微服務(wù)實例進行響應(yīng)，多個微服務(wù)實例協(xié)作完成用戶請求。

圖3 微服務(wù)架構(gòu)Figure 3 Microservice architecture

2.1 組件化

單體架構(gòu)將系統(tǒng)劃分為前端、服務(wù)端、數(shù)據(jù)庫等模塊，服務(wù)端將業(yè)務(wù)功能統(tǒng)一部署實現(xiàn)組件化。微服務(wù)架構(gòu)的組件化則是通過系統(tǒng)功能劃分出的微服務(wù)實現(xiàn)，微服務(wù)間耦合性不高，微服務(wù)間通信采用輕量化方式[7]。

2.2 部署和擴展

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

2.3 數(shù)據(jù)管理

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

表2 單體架構(gòu)和微服務(wù)架構(gòu)比較Table 2 Comparison of monolithic architecture and microservice architecture

2.4 容器化技術(shù)

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

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

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

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

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

3 基于云平臺和微服務(wù)架構(gòu)的AFC系統(tǒng)

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

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

圖4 基于云平臺和微服務(wù)架構(gòu)的AFC系統(tǒng)架構(gòu)Figure 4 AFC system architecture based on cloud platform and microservice architecture

3.1 云平臺設(shè)計

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

圖5 基于微服務(wù)部署的云平臺架構(gòu)Figure 5 Cloud platform architecture based on microservice deployment

IaaS層即基礎(chǔ)設(shè)施層，起支撐作用，將云平臺所需的硬件設(shè)備集中，抽象出虛擬化資源池，提供算力、數(shù)據(jù)存儲、網(wǎng)絡(luò)服務(wù)等基礎(chǔ)資源，支撐AFC系統(tǒng)的運轉(zhuǎn)。

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

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

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

3) 業(yè)務(wù)微服務(wù)結(jié)合AFC系統(tǒng)傳統(tǒng)業(yè)務(wù)和新型互聯(lián)網(wǎng)支付需求將業(yè)務(wù)功能細化，劃分出各類微服務(wù)，通過微服務(wù)之間的組合和調(diào)用完成業(yè)務(wù)需求。

SaaS層即業(yè)務(wù)層，為使用者提供服務(wù)，按模塊分為數(shù)據(jù)管理、賬戶管理、清算管理、維護管理、發(fā)布管理、票務(wù)管理、交易管理、云平臺管理8個模塊。模塊功能通過微服務(wù)層中微服務(wù)的相互調(diào)用、組合實現(xiàn)。

3.2 系統(tǒng)功能組成

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

圖6 微服務(wù)劃分業(yè)務(wù)功能Figure 6 Business divisions of microservices

4 微服務(wù)治理方式

AFC系統(tǒng)業(yè)務(wù)眾多且訪問量很大，由系統(tǒng)功能拆分出的眾多微服務(wù)在調(diào)用時勢必會出現(xiàn)眾多問題，因此需要進行服務(wù)治理，保證服務(wù)質(zhì)量和系統(tǒng)正常運轉(zhuǎn)。

4.1 服務(wù)注冊中心

在運行過程中，微服務(wù)實例處于動態(tài)變化的過程，存在被銷毀、重新定位的情況，因此服務(wù)之間需要感知到彼此的存在，服務(wù)發(fā)現(xiàn)和注冊中心實現(xiàn)了這一功能。服務(wù)注冊中心在服務(wù)啟動時完成統(tǒng)一注冊和服務(wù)訂閱。服務(wù)注冊中心根據(jù)服務(wù)提供者和消費者實時傳輸?shù)男畔⑼瓿筛鱾€微服務(wù)的狀態(tài)更新，實現(xiàn)了包括服務(wù)注冊、發(fā)布、服務(wù)監(jiān)控等功能[8]。

4.2 負載均衡

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

4.3 服務(wù)容錯

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

4.4 服務(wù)通信

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

4.5 數(shù)據(jù)一致性管理

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

4.6 日志中心

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

5 基于云平臺和微服務(wù)架構(gòu)的 AFC系統(tǒng)與既有系統(tǒng)融合

基于云平臺和微服務(wù)架構(gòu)的AFC系統(tǒng)，前期可先在部分新建線路車站進行試點研究，在試點車站應(yīng)用并測試新架構(gòu)下系統(tǒng)的運行狀況，發(fā)現(xiàn)問題后優(yōu)化現(xiàn)有架構(gòu)?？紤]到現(xiàn)階段大部分城市的地鐵線網(wǎng)比較成熟，傳統(tǒng)AFC系統(tǒng)5層架構(gòu)不可能在短期內(nèi)直接轉(zhuǎn)變成新架構(gòu)，因此需要結(jié)合現(xiàn)有架構(gòu)和新架構(gòu)分階段地合理引入云平臺，如圖7所示。

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

6 微服務(wù)架構(gòu)應(yīng)用的挑戰(zhàn)

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

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

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

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

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

7 結(jié)語

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