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

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

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

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

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

傳統(tǒng)AFC系統(tǒng)按照地鐵運(yùn)營(yíng)組織模式進(jìn)行劃分，分為乘車憑證層、車站終端設(shè)備層、車站計(jì)算機(jī)系統(tǒng)層、線路中央計(jì)算機(jī)系統(tǒng)層、清分中心層。傳統(tǒng)5層架構(gòu)內(nèi)部封閉，安全性高，具有一定伸縮性，且各層次分明、功能清晰，各站點(diǎn)、各線路均可獨(dú)立運(yùn)行，不受其他線路建設(shè)工期影響。目前中國(guó)大部分城市的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ù)包括運(yùn)營(yíng)管理、票務(wù)管理、清分管理、運(yùn)營(yíng)維護(hù)管理、賬戶管理、數(shù)據(jù)管理、發(fā)布信息管理、設(shè)備認(rèn)證管理等。

表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ù)極大冗余，同時(shí)需要定期維護(hù)各層級(jí)系統(tǒng)數(shù)據(jù)庫，提高了管理成本。

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1 組件化

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

2.2 部署和擴(kuò)展

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

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

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

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

2.4 容器化技術(shù)

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

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

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

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

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

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

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

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

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

3.1 云平臺(tái)設(shè)計(jì)

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1 服務(wù)注冊(cè)中心

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

4.2 負(fù)載均衡

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

4.3 服務(wù)容錯(cuò)

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

4.4 服務(wù)通信

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

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

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

4.6 日志中心

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

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

基于云平臺(tái)和微服務(wù)架構(gòu)的AFC系統(tǒng)，前期可先在部分新建線路車站進(jìn)行試點(diǎn)研究，在試點(diǎn)車站應(yīng)用并測(cè)試新架構(gòu)下系統(tǒng)的運(yùn)行狀況，發(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)分階段地合理引入云平臺(tái)，如圖7所示。

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

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

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

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

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

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

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

7 結(jié)語

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