城市级部署思考：路边停车收费系统的微服务弹性扩容方案
这两年，不少城市在搞“智慧停车”改造，路边泊位装上了地磁、高位视频、巡检车，再加上移动端缴费，看起来挺美。但真到了节假日景区周边、商圈晚高峰、或者演唱会散场那几个小时，系统就各种掉链子——缴费页面打不开、欠费记录对不上、后台调度直接瘫痪。
我在好几个地级市的交投和城管项目里都见过类似情况。说白了，传统那种单体架构或者简单集群的停车收费平台，平时跑得顺，一遇到潮汐式流量就扛不住。城市级部署和园区、商场完全不同，它天然是分布式、高并发、且不可预测的。
所以这两年我们更推荐用微服务 弹性扩容的思路来重做底座。
为什么必须是微服务？
路边停车系统表面看就“拍照—计费—收款”三步，实际上背后牵连着设备接入、车牌识别、违停推送、清分结算、欠费追缴、和交管平台对接等十几个模块。单体系统里一个模块写错日志，可能拖垮整个计费链路。
拆成微服务后，设备接入归设备接入，计费引擎归计费引擎，支付网关单独隔离。某个区的地磁批量离线，不会影响其他区缴费；支付渠道抖动，也不至于让巡检员APP卡在上传界面。
弹性扩容的关键不在“云”，在“策略”
很多厂商一上来就说“我们上容器、用K8s，自动扩”。但城市级系统真这么简单就好了。
我们实际踩过的坑是：只扩无状态服务没用。比如计费服务可以随便加实例，但背后的时序数据库（存地磁心跳）和规则引擎（阶梯计费、夜间免费逻辑）往往是有状态、难伸缩的。
真正能扛住潮汐流量的方案，得做三层弹性：
1. 接入层用消息队列削峰，设备数据先进Kafka，后端按能力消费；
2. 计算层对车牌识别、计费这类服务做HPA（基于CPU和队列长度双指标扩缩）；
3. 数据层提前做分库分表，按行政区路由，避免跨区锁表。
去年南方某旅游城市，五一期间日均订单从30万飙到210万，就是靠这套组合拳，峰值自动扩到日常6倍节点，假期结束半小时内缩回，资源成本没破预算。
别忘了“边缘”这一环
城市路边停车有个特点：网络脏。有些老城区4G丢包严重。纯中心化微服务在弱网下一扩再扩也救不了体验。
我们现在倾向“中心微服务 边缘轻节点”的混合态。路口就近放个边缘盒子，做本地缓存和脱机计费，中心只做最终一致校验。这样即便光纤被挖断，车主也能先离场后补交，不堵路才是城市治理的底线。
写在最后
路边停车看似小事，却是城市数字化最真实的抗压测试。微服务弹性扩容不是赶技术时髦，而是让系统在“大多数人同时用车”的极端时刻，依然安静地把账算清楚。这件事，决定了一个城市智慧化的成色。
微信号：18581869297