DOI : 10.13439/j.c n k i.i t s c.2021.04.0052021年第04期（总第2S5期）I中国交通信息化
99 C H I N A I T S J O U R N A L V o l255N o042021
刘刚，傅宏杰，孙晗
(北京云星宇交通科技股份有限公司，北京100101)
摘要：木文立足于建设高速公路收费服务体系，实现高性能、高可能的系统，为高速公路业主及高速公路用户提供更好的服务，充分比较、理解微服务与传统软件架构之间的优缺点，为新一代智慧高速公路收费系统的开发提供技术选型依据
关键词：微服务；高速公路；收费系统
目前我国高速公路收费系统仍然采用集中式的软件服务体 系，面临着提升处理能力只能升级硬件、冗余处理能力不足、异 常备份处理能力难以实现、功能分布分散不易统一监控和管理等 诸多问题拆除省界收费站…旦实施，精确路径识別必然会部 ®应用。由此产生的交易数量、业务处理压力必然成倍增长: 据测算，拆除省界站前一辆车…入一出产生的2条交易记录，将 会变为一入一_加平均经过5个门架的7条交易记录；同$
还会产生大量的监测信息、图片信息等：极大增加的数据处理 M，以及严格的准实时性要求，使目前集中式的服务系统已不 能很好地满足要求。本研究内容探索微服务软件开发架构在高 速公路收费系统中应用的可能性，充分比较、理解微服务与传 统软件架构之间的优缺点，为新一代智慧高速公路收费系统的 开发提供技术选型依据:，
一、微服务架构及选型
(一）微服务架构
目前，业界对于微服务并没有一个统一的、标准的定义。通常而言，微服务架构是-•沖架构模式或者说是一种架构风 格，它提倡将单一应用程序划分成一组小的服务，每个服务运 行自己独立的进程，服务之间互相协调、互相配合，为用户提 供《终服务。
服务之间采用轻量级的通倍机制互相沟通，通常是基于H TTP 的RESTful API。每个服务都围绕着具体业务进行构建，并且能够 被独立地部署到生产环境、类生产环境等:
系统设汁时，应尽量避免统-的、集中式的服务管理机制 对具体的簡言，应根据业务上下文，选择合适的语言、T.H对其进行构建，可以通过非常轻量级的集中式管理来协调这 些服务可以使用不同的语言来编写服务，也可以使用不同的数 据存储。
微服务在架构上具有以下基本特点，如图1所示
毎一组雇务®很小|
狭立的进程1
g轻置级通憒
务 ___________________________
*基于业务的能力|
»立部署|
无集中式管理!
图|微服务架构特点
(1)小服务：没有特定的标准或规范，但每个服务
规模上一定是小的；
(2)进程独立：每一组服务都是独立运行的，通过进程方 式，不断横向扩展整个服务；
(3 )轻量级通信：意味费拒比过去更智能更轻量的服务相
互调用，服务的端到端都M解耦的，完成一个业务通信调用串起
这些微服务就像是linux系统中通过管道串连起一系列命令业务；
(4 )基于业务的能力：过去的业务通常会考虑各沖各样的
依赖关系，考虑系统耦合带来的问题，而微服务可以让开发者更
专注于业务的逻辑开发；
(5)独立部署•：不1丨:、丨丨(务要独立，部署也要独立，这意味 着传统的开发流程会出现一定程度的改变，通过独立部署，可以
方便地扩展业务处理节点数量，进而提升业务处理能力；
(6)无集中式管理：传统的企业级SOA服务往往很大，不 易于管理，耦合性高，团队开发成本比较大。微服务可以让团队
各司其职地选择技术实现，不同的服务可以根据各自的需要选择
不同的技术栈来实现其业务逻辑由于不同的服务分配给多个不
同的独立的进程执行，因此无需在业务层面上对各个服务集中管
理，仅需提供对各个服务的监控即可
(二）微服务选型
实现微服务的软件架构有很多沖，Spring Cloud是java 平台
技术 < TECHNOLOGY
最为常见的微服务架构，它为分布式系统模式提供了 •沖简单且易于使用的编程模型，能够有效帮助开发人员构建有弹性、可
«
靠、协调的应用程，：
Spring Cloud构建于Spring Boot之上，是微服务系统架构的 一站式解决方案，开发者很容易入手并f央速应用于生产中，Spring Cloud的基本架构如图2所示，它集成了微服务各组成
发送消患
在收费系统中，无需部署Spring Cloud中的所有组件，而是 按实际情况做了删减，后文详述。
二、高速公路收费系统解决方案
传统的收费系统存在以下问题：（1 )国家倡导的拆除省界 站、不停车移动支付、二义性路径等业务，对于数据的时效性和 实时在网需求不断增强，而传统的收费系统的处理能力已经无法 满足这驻需求；（2)传统的收费系统查询车辆状态名单、费额 计算均在车道本地进行，车道负担过重，传输延迟等会对车道交 易造成影响；（3 )传统的收费系统中间层级数据的存储转发也 是造成传输延迟的原因，而且中间层级数据多次存储，计算机硬 件及数据资源会出现冗余；（4)系统层级多，升级维护困难、为了解决这些问题，考虑采用新兴技术对高速公路收费系统 重新设计改进。
(一）微服务的优势
1、复杂度可控
微服务在一定程度上解决了复杂性的问题。它将整体应用程 序分解成一组服务，虽然功能总量不变，但是应用程序已分解为 可管理的块或服务。每个服务都以RPC或消息驱动的AP丨的形式定义了一个明确的边界，将业务的整体复杂度进行了分解，
2、独立按需扩展
这沖架构使每个服务都能够由专注于该服务的团队独立开 发，开发人员可以自由选择任何有用的技术，只要该服务符合 API规约。
3、技术选型灵活
演员王琳这沖自由意味着开发人员不再有义务使用在新项目开始时存 在的可能过时的技术在编写新服务时，他们可以选择使用当前 的技术。此外，由于服务相对较小，使用当前技术重写旧服务变 得可行。
4、可用性高
微服务架构模式使得每个服务独立扩展。可以根据每个服务 的规模来部署满足需求的规模，甚至可以使用更适合于服务资源 需求的硬件。同时，允许在频繁发布不同服务的同时保持系统其 他部分的可用性和稳定性。
(二）收费系统总体架构
收费系统基本架构如图3所示。
云中心外部系统
收费收费收费收费
车a车道车
a”‘车道
图3收费系统基本架构
在当前网络传输速度已基本满足要求，传输稳定性以及费 用均可接受的前提下，将多级系统扁平化为云中心及车道两级 系统。
同时，为了解决车道系统可能出现的计算压力过大的情况，信息不全时将所有路径推算、费率计算、用户状态确定等由车道 系统完成的复杂计算功能，移至中心端完成。当车道系统需要 时，向中心发起查询，取得结果后进行交易。
大多数保存在用户车辆ETC卡或C PC卡内的交易信息完整，车 道系统可以在本地进行处理。但由于
交易量巨大，车辆所经途中 又和多个门架进行交互，所以有相当数量的交易信息不完整，此 时车道无法完成计费，必须向云中心查询（极端情况下，如断网 时只能采用最短路径计费，造成通行费流失）。
云中心首先根据车道系统上传的ETC及CPC卡内信息，在系统 Redis缓存中查询近两天所有卡号泪同或车牌相同的在途通行 记录，通过一定的逻辑拟合出车辆的通行路径，於后从费率表中 查询收费金额，再查询状态名单、绿通车名单、大件运输车名单 等数据，最终返回计算结果。
在途通行记录从全市近千条入口车道和约380个门架数据中 汇总得到，两天的记录近3千万条，且在不断变化，不可能广播 到所有出口车道目前，云中心使用在线计费服务由路径拟合、
模块，不必冉逐一适配
f.；l 消息总线
明例••
中心拆夕
子系
中心数
据汇聚
管理子
系统特情业务*务
奔流不息的意思服务
下較参数*务
E B密禊权雇务
分中心CPC+*
iR囅每_._
北斗对时雇务
分中心运行监
测接收服务二十不惑三十而立四十
围片f t询*务
围片接收*务
TWWM 路径拟合*务后台*分屢务參数打包*务路M推算后6
软件
服务
运行监测f W I
飄务I
图4收费系统业务体系
微服务注册中心集
获取服务列表
服务注册
文件落地雇务
PSAVI臁务发票上传服务数裾修正脈务费顴査询服务图片多特征服务
账务传輸雇务預约通行服务
以微雇务方式檯供的业务服务集
FTP Redis集文件云存储高淅数据库集
数据存储监
测
阁片推送服务
Uongodb
(围片索引）
(图片文件）
费率计算、状态名单查询、特殊车辆查询等多个微服务完成。整 个计算过程平均耗时低于1秒。
各类车道数据的接收在云端以微服务的方式提供，数据主要 分为入口数据、出口数据、门架数据、抓拍数据等。
接收数据并保存到数据库中，然后由其他服务进行处理，并 最终转发给北京清分中心。
每类微服务至少运行3个实例，保证高可用性。由于每台主 机的性能是确定的，根据不同的业务量，不同业务的微服务运行 实例数量不同，最多的是门架数据接收服务，运行12个实例（门架的数量虽然比入、出口车道数量少，但其产生交易数量更多。平均每一组入、出交易，要经过4至5个门架）。多个实例部署，可以提供足够的性能，并且能弹性扩展。
(三）收费云中心的业务体系
对于非关键性业务，仍采用单体应用架构；对于数据传输及 处理业务，全面采用微服务架构，以提高可用性及可扩展性，在 系统稳定性及处理能力方面提供保证。
收费系统业务体系如图4所示。
(四）收费云中心的微服务架构
云中心（即总中心）关键业务采用微服务架构替代原有单体 应用架构，如图5所示。
1、服务网关
网关采用Spring Cloud Zuul集搭建，并实现其高可用。
2、服务注册中心
采用Spring Cloud Consul集搭建，并实现其高可用:
3、Redis集服务
采用Redis接收车道和门架上传的各类数据，分类存储，一
收费分中心收费总中心
服
-
调用
负教均衡集微臘务网关集
断路器/熔嘶器负教
2021年第04期（总第255期）I中国交通信息化
C H I N A I T S J O U R N A L V o l.255N o042021
Windows Linux Linux本地（可■云大数据平台软广表地结构f t f 本地软件云平台软件平台）软件件（可云> 丨l n m-[ u E
访服务集处理服务/软件
接牧®务交易处理服务
V B2
(O O S_)
对上接口模块/软件
►
交輅发送雇务
部级特情*务
消分结算接收
参数接收上报
»密授权对接
V
C P C卡跨
拨对接
件
运行监测上报
部级感知对接
部级稽我对接
视糲点擂
用片按霱上传
营改增传输
参数上传服务
分中心应 用系统
后
台
软qq英语情侣网名
件
逻
辑
架
构
交
理
统
心
处
系
中
易
维嘉的老婆子
费
特
工作检查书务
统
行
砌
业
系
对
件
斗
软
北
时
客
搜
系
辆
征
子
统
车
特
索
输
统
传
系
原
子
鹊
*
-
软
件
异
常
采
集
I
s
备
运
fy-
s
札
f
、
f i;
W
络
安
全
采
集图5
收费系统云中心微服务架构
技术 < TECHNOLOGY
1、consu l+ke e pa live d
2、zuul
3、j d k l.8.0_121
4、数据接收服务
5、解析午边数据服务
6、解析门架数据服务
7、psaa k职务
8、特情服务
9、费额i l W服务+路径还原
10、下软衫数服务
11、交易处理服务
12、濟分结算服务
13、业务朴偿*务
14、统…发送服务
15、监拧数据采集
安*和舖i s用
1、2、J d k l. 8. 0_121
lo g sta sh
安饕鞠用
3、E la s tic s e a rc h
1、J d k l. 8.0—121
2、lo gsta sh
3、E la s tic s e a rc h
4、kibana
图6收费云中心部署视图
类存储文件基础信息，一类存储文件信息。
4、 业务服务
使用Spring Boot开发架构，集部署
5、 H志管理
采用E L K进行日志管理、展示等。
(五）收费云中心部署
收费云中心部署视图如图6所示。
微服务应用分别部罟到多台虚拟机上每个应用都有多个 实例提供服务，保证高可用；虚拟机可根据实际业务需要随时增 减，提供了系统扩展性。
三、结束语
通过将收费业务拆分为多个单独的、小的服务，开发人员 可以更专注于其所负责的业务。在预先确定各个服务之间接口调 用规则的前提下，开发人员不必过多考虑是否影响其他系统的业 务，提高了开发效率。此外，专精某一业务领域的处理也使开发 人员更容易掌握业务规则，而不是一大套相关性不强的业务规 则，进一步提升了开发效率。
基于以上特点，在开发人员的组织安排上比单一集中式应用 程序的开发更加灵活有效，
每个微服务程序均可部著多个实例，即以集方式运行。该模式有如下几个优点：
(1 )提供了高可用，一两个实例发生异常并不影响整个系
统的运行；
(2)随着业务压力的增加，可以部署更多的业务实例，针对性地扩展某些（或全部）业务的处理能力，提供了高扩展性，
且这些实例可以部®到相对老旧的硬件上运行，其扩展能力是横
向的；
(3)系统升级时可逐步替换，不必像单一集中式程序一样必须停机升级，这样可以使业务处理在升级期不中断，有效降低
升级所导致的业务中断风险。
虽然微服务存在运维难度提升的缺点，但通过技术培训以及
使用适当的监控工具，可以很大程度解决该问题：相比于微服务
的这些优点，运维难度提升是可以接受的。因此，新一代智慧高
速公路收费系统应采用微服务架构进行开发。
参考文献
[1] Mdrt'r Fowler关于微服务的说明[EB.〇L].http:.’martinfow丨e r/article':..' microservices,html.
12]尚服务架构的理论基础…東我定律[EB/O L丨.http:/konway.〖嫌H om e/ Committee'...Paper.htm!.
[3] Spring CUou‘1组件的选型[EB,0L].h t t p-,/w w w .karu loud.t_n/
o p r in t.'Joucl/ 1599297.
责任编辑刘睿健
发布评论