从0到1：路边停车收费系统App的云边协同架构，我们踩过的坑与想透的事
做了快六年智慧交通，我带团队从零搭过三套不同城市的路边停车收费系统。说出来你可能不信，最早那版我们纯靠云端，结果早晚高峰直接被现实教做人——车牌识别上传慢、计费延迟、断网就瘫痪，运维电话被打爆。后来才真正弄明白，路边停车这种场景，不上云边协同基本等于裸奔。
今天聊点干的，不讲PPT上的漂亮话，只说我们从一个空仓库走到上线十万车位规模，云边协同架构到底是怎么长出来的。
为什么非得“云边”不可？
路边停车和商场车库完全两码事。车位分散、网络环境野、设备廉价、还得抗得了暴晒和暴雨。如果我们把所有算力都压在中心云，前端相机一旦遇上4G波动，识别结果传不回去，杆子不抬、费算不出，车主骂街，城管也找你。
所以我们定的第一条铁律：边缘端必须能“独活”。也就是在路口或片区部署边缘网关，带轻量AI推理能力，车牌识别、车位状态判断、离线计费全在边缘完成。中心云只负责任务编排、大数据分析和跨区结算。
从0到1，我们怎么分层？
第一阶段，我们没急着写App，而是先定架构边界。云边之间不是主从，是协作。
边缘层用的是ARM架构工控机加自研推理引擎，模型只有不到30MB，专做“看到车牌→绑定车位→开始计时”这件小事。哪怕骨干网断了，边缘也能本地存48小时记录，恢复后增量同步。
云层反倒简单：K8s跑计费清结算、用户账户、违停举证、电子发票。关键是云要给边“喂模型”——我们用灰度分发，凌晨低峰把新识别模型推到10%边缘节点，观察误识率，再全量。
App本身不算重，但它必须是云边状态的“显微镜”。用户点开看到“已识别沪A·XXXXX，入场8分钟”，这个状态是边缘先算完、云再确认的。我们故意在App里暴露“数据来源：边缘节点#3207”，既透明，也方便排查。
真正难的不是技术，是妥协
你以为架构图漂亮就完事？实测里我们栽过跟头。有次边缘网关批量升温，识别帧率掉一半。后来发现是散热片偷工减料。还有一次云边时间不同步，导致计费差了三秒，被投诉“抢钱”。现在我们强制边缘走PTP对时，误差压到毫秒级。
另外，云边协同最怕“脑裂”。我们设计了双心跳 本地决策权，边缘发现云连续失联超90秒，自动切独立运营模式，并在恢复后做冲突消解，优先以边缘原始记录为准。
写在最后
路边停车收费系统App，表面看是个扫码缴费的工具，底子是云边协同的硬功夫。从0到1，我们不是先写代码，而是先认清楚：在哪算、算完找谁、断了怎么办。这套架构跑下来，单城部署周期从四个月压到六周，误计费率低于0.02%。
如果你也在做城市级停车，别信那种“全部上云最先进”的鬼话。路边的风很大，系统得自己站稳，再跟云握手。
微信号：18581869297