干过城市停车平台的人都知道，路内停车这件事，表面看是立个地磁、装个摄像头，背后真正的硬仗在计费。尤其这两年各地推行的城市级停车治理，动辄几万个路边泊位一张网管理，早高峰半个小时内数万辆车同时离场，系统要是多收了或者少收了哪怕一笔，投诉电话能打爆指挥中心。
我印象很深，去年我们去华中某市做老旧系统替换，他们原先的单体应用撑了不到两年就废了。原因很简单，在节假日景区周边，并发计费请求瞬间超过八千，数据库行锁直接拖死，结果同一辆车被重复生成订单，市民收到两张缴费通知单，舆情闹得挺大。后来我们给出的方案，核心就是一句话：用微服务架构把计费链路拆碎，让高并发下的稳定计费有处着力。
说到路边停车无人收费系统，它和封闭停车场最大的不同在于边界模糊、事件随机。车可能停了三分钟就走，也可能蹭泊位一整天。微服务在这里不是赶时髦。我们把整个业务切成五个相对独立的域：泊位感知接入服务、车牌识别流转服务、计费规则引擎、支付网关适配服务、以及后台对账服务。每个域用独立的容器部署，资源隔离。比如识别流转服务因为要接视频AI，CPU消耗大，就单独调度；而计费引擎对延迟敏感，挂在内存型实例上。
特别要提的是，城市级系统往往涉及多个行政区，我们采用多租户模式，每个区的计费规则（如核心区首半小时免费，郊区阶梯收费）在规则引擎里以独立配置文件加载，互不干扰。这也避免了某区政策调整引发全局重启，保障了对外的服务连续性。
保障高并发稳定计费，关键在三处设计。第一，计费引擎彻底无状态化。所有分时费率、节假日优惠策略预热进Redis集群，引擎本身不落库，只算账。这样水平扩容极简单，K8s监控到消息积压就自动起新pod。第二，用消息队列做削峰。车辆离场事件先丢进Kafka，哪怕支付渠道微信支付宝回调慢，计费主链路不受影响，异步生成账单。第三，严格防重。利用分布式锁和泊位状态机的版本号机制，一辆车在同一个泊位生命周期内，订单只能由特定事件触发一次。我们甚至在代码里埋了混沌测试，随机杀掉计费节点，验证账单最终一致性。
实际跑起来什么效果？中部那个城市部署完后，核心城区两万七千个路内泊位，日常并发峰值在一万二千左右。今年三月连续暴雨，晚高峰车辆集中驶离，系统自动扩容了40%的计费实例，平均计费延迟控制在47毫秒，当日对账差异笔数只有3笔，差错率低于百万分之一，而且那3笔还是因为地磁电池耗尽导致状态漂移，不是系统算错。
另外，微服务让我们能灰度发布计费算法。有一次某区要试水“拥堵调控费率”，我们在镜像里打了标签，只对该区计费pod生效，观察一周没问题再推全量。这种灵活性单体架构想都不敢想。
站在城市治理角度，路边停车无人收费不只是省人力，更是把公共资金流变得透明。但透明的前提是技术底盘稳。一些同行喜欢吹“一体化大数据平台”，我倒觉得微服务这种看起来笨拙的拆分，才是真能扛事。参照交通运输部公路科学研究院的一些指导意见，路内停车系统应该具备弹性伸缩和故障隔离能力，微服务刚好对齐这些要求。
当然，架构师也得提醒一句：微服务不是银弹，运维复杂度上来了。城市甲方如果没有相应的容器云底座，硬上微服务反而会散架。所以我们通常建议，先做计费核心的微服务化，周边慢慢演替。
写到这里，想起前阵子和一个省会城管领导聊天，他说现在考核他们不光看车位利用率，还要看收费投诉率。这背后，就是微服务架构在默默兜着底。城市级停车治理这场长跑，技术派得上用场的地方，往往就在这种看不见的高并发计费里。
微信号：18581869297