网约车上报监管平台系统架构演变研究

陈晓阳

(上海赛可出行服务科技有限公司南京分公司， 南京 210018)

0 引言

随着社会经济和科技的飞速发展，出行方式变得多样化，人们逐渐把网约车作为主流的出行方式，这是社会发展到一定阶段的产物. 但是随着网约车的发展，其存在的问题也日益凸显，比如车辆准入和驾驶员审核不严、政府监管疏漏、平台监管真空等，严重触及公共利益[1]，所以必须对网约车进行合规化监管. 何谓合规？简单来说，就是网约车的司机和车辆是不是符合国家的相关网约车规范化标准，需要相关部门进行报审通过才能进行营运. 2016年12月份开始实施的《北京市网络预约出租汽车经营服务管理实施细则》，规定了网络服务平台数据库接入政府有关部门监管平台[2]. 2018年为了进一步加强对网约车的安全管理，交通运输部办公厅和公安部办公厅联合发布《进一步加强网络预约出租汽车和私人小客车合乘安全管理的紧急通知》，并在当年年底清退了不符合条件的车辆和驾驶员. 《紧急通知》(以下简称)标志着网约车行业合规化工作全面展开[3].

针对以上《紧急通知》的出台，对于网约车公司来说，技术实现上，有一定的挑战性. 网约车和交通部门技术对接主要依据的是交通运输部办公厅印发的《网络预约出租汽车监管信息交互平台总体技术要求(暂行)》的通知[4]，里面涉及网约车公司基本信息、车辆和驾驶员基本信息、车辆和司机实时定位信息、营运订单相关信息等，具体的接口有20多个.

基于上述背景，本文针对网约车上报监管平台的系统架构演变的相关问题展开研究，深入探讨此系统架构的演变，以求快速满足网约车监管平台的技术要求，同时对系统的可扩展性、性能等进行优化，以及存在的不足之处和后续工作的展望.

1 软件系统架构设计

1.1 软件系统架构

随着软件系统不断的升级换代，以及相关知识和经验的累积，软件系统架构的概念是软件系统发展到一定阶段的产物. 软件系统架构是一个既古老，又很现代的研究领域. 对于一个软件系统的设计，通常先要对软件系统的整体架构进行分析和设计，相当于盖房子要先有图纸一样，同时随着新技术的发展，为软件系统架构设计注入了新鲜血液，好的软件系统架构，会带来软件系统的各方面性能的提升. 软件系统架构不仅指定了软件系统的组织和拓扑结构，而且显示了系统需求和组件之间的对应关系[5].

1.2 系统架构前期总体设计

由于开发时间比较紧张，以及初始开通的城市也比较少，所以网约车上报监管平台系统初始的架构设计比较单一，没有考虑到通用性的设计模式，具体总体架构设计如图1所示. 说明:①公司的相关基础信息(如经营信息、运价信息、许可证信息等)、车辆和司机信息数据是通过Excel解析导入到数据库中(注:运营人员从后台管理系统页面上传Excel文件到服务器，服务自动解析Excel并把数据导入数据库中). ②运营订单的相关数据是大数据部门通过ETL工具(注:ETL工具主要用于大数据的抽取、清洗、转换、装载等)实时导入到数据库中. ③上游服务通过调用“心跳服务”(注：心跳服务主要是实时传输司机车辆的定位数据，同时监听司机是否在线. )传输司机车辆定位数据，“心跳服务”直接把数据写入kafka里面，然后交通部(地方交管委)上报服务直接消费kafka里的数据传输给交通部和地方交管委. ④交通部(地方交管委)上报服务分别定时去相应的数据库捞取未上报数据(注:根据传输标志位report_flag进行识别)进行传输.

图1 初始系统架构设计图

1.3 系统设计存在的问题

交通部监管平台和地方交管委监管平台存在较大差别. 交通部监管平台是网约车公司必须传输的平台，服务必须部署在Windows系统平台才能运行，因为交通部传输必须连接相应的Windows VPN客户端，不支持Linux操作系统. 而地方交管委的监管平台属于选择性传输的方式，有的地方交管委不需要进行对接，他们是直接拉取交通部的上报数据进行监管. 而有的地方交管委则单独做了一套监管平台，要求网约车公司进行传输，需要传输的内容会比交通部的要多，以实现网约车的精准化管控. 本系统初始对外传输方式示意图如图2所示，交通部和地方交管委是分开传输的，这里需要说明的是，初始阶段由于开通服务的城市数量少，开发时间比较紧，所以没有充分考虑后续系统的可扩展性，各个城市的传输都是单独的一套服务进行部署，数据库也是1城1个，主要考虑到不同的地方交管委传输的内容会有差异，而传输方式也存在一定的不同之处.

图2 初始对外传输方式示意图

以上海市传输为例，要部署1套交通部的监管平台传输的服务，还要部署1套上海交管委的监管平台传输的服务，共享1个数据库，其他城市以此类推，这样整个系统的架构设计显得十分地冗余和臃肿. 随着公司开城数量的增加，这样的系统架构已经明显跟不上开城的速度，每开1个城市都得至少部署1个服务和申请1台数据库，人力成本和资源成本不断增加，系统的可扩展性很差.

2 解决方案

2.1 系统架构重构

针对前述的系统架构设计存在的相关问题，经过慎重的评估，决定对当前系统采取“重构”的解决方案. 何谓重构?简单来说，重构是对软件内部结构的调整，目的是在不改变软件可观察行为的前提下，提高其理解性，降低其修改成本[6]. 在工程实践活动中，编程往往考虑的是功能的实现，而重构则是在功能实现的基础上，考虑系统的稳定性、性能、可扩展性等.

2.2 可行性分析

系统重构前，必须充分分析和评估重构的可行性和风险. 对此，本文基于如下几个方面进行了综合考量，决定进行重构.

1) 开城数量. 当前开城数量在10个左右，并不算太多，处于可控范围，重构后的系统传输功能不会受影响.

2) 交通部传输. 因为交通部传输的协议都是按同1个协议进行传输，没有什么变化，不同的只是各个城市的城市码不同，所以多个城市交通部的传输可合并成1套.

3) 地方交管委传输. 由于不同地方交管委的要求不同，传输的内容和传输方式都存在差异，所以总的思路是“求同存异”. 把相同之处采用直接合并的方式，不同之处采用扩展的方式，比如字段差异，就进行类中扩字段，再比如传输方式差异，就利用“策略模式”(注:1种软件设计模式)的设计模式进行传输方式的扩展. 通过2种不同的方式，把地方交管委传输也合并成1个服务.

4) 数据库. 由于交通部都是同样的传输协议，即传输内容完全一致，所以采用统一的表即可. 而地方交管委传输存在一定的差异，针对同样的上报内容，字段的差异，直接在表上进行字段扩展，或者在系统中进行字段转义;针对新增的上报内容，直接进行新增表的操作. 这样交通部和地方交管委的数据都可合并在1个数据库中，便于操作和管理.

5)上游服务影响. 整个系统是采用业界经典的SpringBoot微服务的架构,只需要重构上报监管平台相关服务，由于内部系统间没有传输协议的变动，所以上游服务不需要进行改动，系统间影响面较小.

6)可扩展性. 后续开城数量会越来越多，上报监管平台的对接速度直接影响公司开城拿证的速度，必须提高系统的可扩展性，适应开城速度.

7)分布式机制. 上报服务采用多实例部署，以加速数据的传输速度，同时为了防止重复传输数据，系统通过使用Redis锁机制，构建分布式锁，分布式锁是控制分布式系统之间同步访问共享资源的一种方式[7]. 此外，对每个实例可动态编组，比如几个城市为1组，专门消费这个组内的数据，这样有利于提升查询数据的效率，也防止瞬间数据量巨大，消费慢的问题.

3 重构后的系统架构

3.1 重构后的系统架构设计

图3为重构后的系统架构设计图，这里与初始架构图中，存在区别的地方是:①整个系统共享1个数据库，大大节约了资源，也便于进行维护. ②增加了可配置的页面，对相关交通部和地方交管委的传输方式、地址等配置进行集中管理，同时在服务中增加配置变化的监听机制，便于动态变更配置，提高了系统的动态性. ③增加定时数据清理和重试机制，以及每日统计功能. 对于传输成功的数据，次日凌晨1点之后先对前1天的订单数据进行统计，然后进行删除数据操作，防止数据积压数据库导致慢查询. 对于传输失败的数据，进行定时恢复传输标志位(注:传输标志位report_flag置0)再次重试传输. 如果有些数据一直传输失败，则可能存在问题数据，统一在周日凌晨1点进行删除.

3.2 重构后的效果

重构后的上报监管平台系统总体运行平稳，系统功能与重构前一致，属于平滑过渡.

表1是重构前后相关指标的对比，具体说明如下：

表1 重构前后相关评价指标对比

1)从可维护性的角度，系统的微服务数量从原有的20个下降到3个，服务器数量从原有的26个下降到6个，数据库从原有的10个下降到1个，大大降低了维护的难度.

2)从稳定性的角度，由于增加了相关网络健康状态的监控，使得系统上报断开的平均时间间隔从100 min下降到了2 min，系统的稳定性较之前更加稳定，数据消费更加连续.

3)从传输性能的角度，每分钟传输数据条数从10 000提升到25 000条，单次传输数据包容量从60 KB提高到800 KB，Kafka队列主题数量从10个下降到1个，消费的平均延迟时间从30 s下降到5 s，系统的响应速度增加，队列的消费速度加快，上报的及时性得到大幅提升，同时系统CPU的利用率从原来的30%提高到了65%.

4)从可扩展性角度，后续新增新的城市上报，只需要在页面进行配置相关的城市代码和传输地址即可，新开城开发速度从原来的7 d降低到了0.5 d，极大缩短了开城的时间，无需修改代码，同时也新增了订单数据的统计功能，做到了“开闭原则”.

此外，2021年2月，交通运输部发布1月份全国网约车平台数据传输情况(见图4)，当月订单量超过100万单的网约车平台公司中，按双合规完成订单率公司排前3名[8]，这是公司上报系统重构后进行数据传输的结果. 通过官方公布的数据，也从侧面验证了重构后的系统传输情况良好，达到了优化的效果.

图4 2021年1月交通部网约车平台数据传输情况截图

4 结论

软件系统架构设计对软件系统的影响是深远的，良好的系统架构设计是系统运转正常的关键. 本文通过论述网约车上报监管平台的系统架构演变过程，理论联系实际，使得网约车上报监管平台系统的传输性能得到提升. 当然系统的优化之路是无止境的，尽管上述的优化方案使得系统各方面性能得到大幅提升，但仍存在一些不足. 主要体现在几个方面:

1)有些基础数据的入库还是沿用Excel文件导入的方式，不够智能化，还需要人工的方式，后续可进行去人工化的改造.

2)对于上报监管平台服务的多实例分组特性还可继续细化，比如根据不同城市的传输性能再进行动态组合，以达到负载均衡的效果.

3)传输过程中对于数据的合规化率还有进一步优化空间，可增加对部分数据合规化的校验.

4)与“滴滴”等大型网约车公司的上报监管平台架构相比，当前系统性能还存在一定的差距，因为现阶段公司订单量并没有达到日均几千万单的级别，系统的承载力在可接受范围内，如何承载更大的流量，是今后的一个重要研究课题.

5)当前上报的订单数据是通过ETL工具从订单数据库实时导入到上报数据库，采用第3方工具，会存在不可控的因素，比如工具出现不工作的场景，导入数据过慢等现象. 后续系统设计中，考虑加入第3方工具的监控，如果出现异常及时发出告警进行排查和解决.

对于上报监管平台系统的进一步优化需要一个持续迭代集成的过程，不可能毕其功于一役，也要结合实际的业务需求，不能为了优化而优化.