拓扑重构：面向城市管理者的路边停车收费系统app云原生架构实践
做了快十年的智慧交通集成，最近这两年跟各地城管局、交委的领导坐下来聊，话题总绕不开路边停车收费那点事。很多城市早些年上的停车APP，初衷是好的，取缔人工收费、杜绝跑冒滴漏，可真跑起来才发现，一到节假日或者商圈晚高峰，系统不是卡在支付页就是地磁状态对不上，市民投诉电话被打爆，基层管理人员对着后台干瞪眼。这背后的根子，往往不在摄像头或者地磁设备，而是系统架构的“拓扑”早就僵化了。
我们团队去年在中西部一个常住人口破千万的城市做了套重构实践，主责就是把这个城市原本单体架构的路边停车收费APP连根拔起，用云原生思路重做了一遍。这里说的拓扑重构，不是简单把应用扔到云服务器上，而是从接入拓扑、服务拓扑到数据拓扑三层全拆开重组。
先说接入侧。路边停车场景有个铁律：车牌识别和设备状态上报必须快，哪怕中心云短暂不可用，前端也不能瘫痪。原来的老系统是所有道闸和地磁直接写中心数据库，网络一抖就丢数据。我们这次在区一级加了边缘计算节点，跑轻量Kubernetes，把车牌识别推理和泊位状态聚合放在边缘做完，只把结构化结果通过MQTT回传。具体落地时，用了挂载在运营商基站机房里的工控机，配置不算高但跑containerd足够。这样一来，即便中心机房做版本发布，路边缴费体验也不受影响。
服务架构上，我们把原来一个巨无霸的Java war包，拆成了大概三十多个微服务。用户端APP的登录、地图泊位查询、计费规则引擎、电子发票、申诉处理，各自独立部署。编排用K8s，流量治理上了Istio。这里有个细节，城市管理者最关心的是“钱别算错”，所以我们把计费服务用Go重写并做了双活隔离，原来Java那套GC停顿在月底对账时实在受不了。任何发布不波及计费。压测的时候，模拟了商圈国庆期间那种突发流入，旧架构在每秒并发八百就崩，新拓扑扛住了五千以上，P99延迟从过去八百多毫秒降到了一百二十毫秒左右。
数据拓扑更得提一提。停车数据看起来简单，一条记录含泊位号、车牌、起止时间，但架不住量大且要实时出报表给城管考核用。我们用了时序库接设备流，业务库用分布式PG，中间靠CDC同步。管理者在后台大屏看实时周转率，再不用等T 1抽取。配合今年住建部关于城市停车设施智慧化的导则，这种清晰的数据拓扑才好对接市级城市大脑。
当然，作为过来人得说句实话，云原生不是银弹。有些县级市上来就要学大城市搞服务网格，结果运维团队连Prometheus告警都配不明白，反而添乱。我的建议是，城市管理者推动这类项目时，先让技术团队把现有调用链画出来，看看拓扑瓶颈到底在哪一环。如果是数据库连接池打满，那重构重点在数据层；如果是APP发版就得停服，那是交付流水线的问题。别被厂商的“大而全平台”话术带着走。
那个千万人口城市的项目上线半年，路边停车逃费率从百分之七降到了两点几，最关键是12345投诉工单少了一大半。前阵子他们交通局开研讨会，还拿这套架构当标杆给兄弟单位讲。我做这行久了，越来越觉得，智慧停车的“智慧”不该只体现在摄像头多高清，而是底层拓扑能不能柔性的适应城市脉搏。这方面，云原生确实给了我们一把趁手的手术刀。有兴趣的主管单位或者同行，可以私下交流，脱敏后的拓扑图我手头还有备份。
微信号：18581869297