全域感知拓扑下路侧停车电子收费系统的流式计算架构演进
城市路侧停车这块硬骨头，啃了十几年，从最早城管贴条、收费员打票，到如今手机自动扣费、离场无感支付，背后的技术脉络其实挺有意思。我入行做智慧交通架构设计快十年，经手过北方某直辖市和几个新一线城市的路侧停车系统改造，亲眼看着电子收费系统从“晚上回去算账”变成了“车子刚走钱就到账”。这两年行业里都在提“全域感知拓扑”，这种说法虽然听着有点学术，但落到实处，就是怎么把街上林林总总的探头、地磁、咪表甚至巡检车，织成一张能自我印证的数据网，再用一套跟得上的计算架构去喂饱它。
早些年，大概2015年之前，路侧停车系统基本是离线的。地磁埋下去，只能记个出入时间，收费员手拿POS机，下班了把数据导进数据库，第二天批处理算一遍，出账单。这种架构简单，MySQL加个定时任务就搞定，但漏洞太大：收费员截留、车主逃费、误报错报，投诉电话接不过来。后来有些城市上了高位视频，纯视频识别车牌，但后端还是T 1结算，只是证据链稍微好点，实时性为零。
真正的转折发生在分布式流式计算框架成熟之后。2017年前后，我们在一个沿海城市试点，第一次把Kafka接进停车数据管道，用Storm做实时拓扑。那时候的“拓扑”仅仅是消息流拓扑，还不是感知拓扑。地磁触发一条消息，视频识别触发一条消息，两路流在Storm里做join，匹配上了就生成预账单。时延从一天压缩到几分钟，逃逸率肉眼可见往下掉。但问题来了：设备一多，Storm的ACK机制扛不住，ZooKeeper经常抖动，而且视频流和地磁流时间不同步，半夜误扣费的情况不少，运维同学差点住进机房。
到了最近这两年，“全域感知拓扑”才真正在物理层和逻辑层统一。所谓全域，不只是覆盖全，而是多源异构设备组成了一张有冗余、能互校的网。比如一条路边车位，头顶有视频桩，地面有地磁，巡逻车经过还能补点毫米波雷达。这些设备通过NB-IoT或者5G回传，在边缘网关先做了一层流式预处理——这很关键，边缘侧把无效数据过滤掉，只把车牌事件、occupancy状态变更往中心推。中心云这边的架构也早就从Storm换成了Flink，而且得是改过的Flink。
我们在西南某个新区做项目时，设计了一套分层流式架构。端侧设备产生原始流，边缘节点跑轻量流处理（比如用EdgeX加自研算子）做时间对齐；中心平台用Flink做三流合一：地磁状态流、视频识别流、支付交易流。这里有个细节，Flink的Event Time窗口必须依赖设备端打的时间戳，但我们给每个边缘网关配了北斗授时，解决了乱序问题。状态后端用RocksDB，恰好一次语义保证计费不出错。车主停进去，系统秒级感知，离场时若没缴费，巡检车上的喇叭直接喊话，同时推送到车主APP。这种体验，放五年前不敢想。
流式架构演进到今天，已经不是单纯追求“快”，而是追求在复杂拓扑下的确定性。全域感知带来了数据洪峰，节假日商圈峰值能达到平时二十倍，Kafka分区数和Flink并行度都得动态扩。我们踩过坑，前期静态资源配置，结果春节直接把消费延迟拉到半小时，车主都开出去二环了才收到缴费提醒，被骂惨。后来上了弹性资源调度，基于YARN或者K8s的弹性伸缩，才算稳。
回头看，路侧停车电子收费系统的架构演进，本质是用流式计算去消化全域感知带来的连续性事件。批处理时代是“事后诸葛亮”，初级流处理是“事后秒级”，而现在这套边缘协同的流式拓扑，是“事中干预”。作为从业者，我觉得下一步挑战在跨域拓扑联邦——把一个区、一个市甚至城市群的路侧数据当成一张大图来做流式计算，那时候计费、诱导、执法就彻底一体化了。对于正在规划智慧停车底座的城市来说，认清这条架构演进路线，比盲目堆摄像头重要得多。
18581869297
