基于云平台和微服务架构的城市轨道交通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系统引入云平台和微服务架构以适应未来的城市轨道交通朝着智慧化方向发展提供了参考。