马路边停车收费智能系统落地案例谈：微服务架构如何撑起高并发收费
这些年跑过不少城市的交通信息化项目，和一线停车运营公司、城管技术口的朋友聊得也多。有一个感受越来越深：马路边停车看似小事，真要做成“应收尽收、车主无感、财务对账清清楚楚”的智能系统，背后的技术坑比想象的要深得多。
尤其是早晚高峰、商圈节假日，一条街几百个泊位同时发生驶入、驶出，地磁、视频桩、巡检车还在不停上报状态，后台如果还是那种单体应用“一锅炖”的写法，基本撑不过两个月就得重构。我们去年在华东某地级市落地的路边停车收费系统，就直接上了微服务架构，跑了一年多，峰值并发收费请求稳定在每秒 4000 ，没掉过链子。今天借这个案例，聊聊微服务到底是怎么把高并发收费这个硬骨头啃下来的。
先说业务痛点：收费不是“收个费”那么简单
传统路边停车系统，很多是小厂商用一套 PHP 或 Java 单体系统搭的。泊位状态、计费规则、支付回调、欠费追缴、发票全部耦合在一个工程里。车一多，数据库行锁打架，计费延迟从毫秒级飙到几秒，车主离场时栏杆（或地磁状态）没更新，误扣、重复扣投诉一大堆。
我们接手时，当地城管给的指标很明确：覆盖主城区 1.2 万个路内泊位，支持地磁 视频桩双感知，微信/支付宝/银联全渠道，欠费自动入黑名单，并且要和市级静态交通平台实时对接。这种体量，单体架构想都别想。
微服务怎么拆？我们没照本宣科
市面上很多微服务拆法喜欢按“用户、订单、支付”一刀切，但停车场景有其特殊性。我们最终落地的核心服务大概是这样：
- 泊位状态服务：专门消费地磁和视频桩的 MQTT 报文，做状态机收敛（比如“占用中”连续心跳不跳变就不重复推）；
- 计费引擎服务：纯内存计算，规则用 DSL 配置，分时段、分车型、分路段，热更新；
- 收费交易服务：只管生成待支付单、调渠道、处理异步回调，做了幂等表；
- 对账与清结算服务：跑 T 1 批处理，和财政非税系统打通；
- 巡检调度服务：给巡检员 APP 派单，处理异常停车。
最关键的一招，是把“计费”和“交易”彻底分开。高并发时，大量请求只是“查询当前该收多少钱”，根本不走支付渠道。计费引擎用本地缓存 Redis 原子计数，单机就能扛住上万 QPS；真正落库的收费记录，由交易服务异步批量刷。
高并发实战：限流、熔断、降级一样不能少
上线第一个国庆，商圈周边泊位周转率奇高。我们通过 Sentinel 对收费交易服务做了接口级限流，超出阈值直接走“先离场后补交”降级逻辑，保证车道不堵。泊位状态服务因为用了 Kafka 做缓冲，设备报文积压时最多延迟 3 秒，业务无感知。
另外说一句实在话：微服务不是银弹。那套系统光运维编排我们就用了三个月才顺溜，K8s 网络策略、分布式追踪没点真经验根本玩不转。但回过头看，如果没有这次架构选型，当地路边停车收费率不可能从 61% 提到 89%。
做智能交通的同行都清楚，路内停车是城市治理的“微循环”。技术选对路，车主少骂娘，财政多进账——这事儿，值得我们多花点心思。
微信号：18581869297