业主单位选型指南：路侧停车电子收费系统的微服务架构避坑要点
这几年，随着城市静态交通治理提速，路侧停车电子收费（ETCP）几乎成了新基建里的“标配”。但凡稍微上点规模的业主单位——无论是城投、交投，还是区一级的停车管理专班——在招投标或自研立项时，都会被厂商引导去看“微服务架构”。听起来很美：弹性扩展、故障隔离、持续交付。可真到了落地和运营阶段，不少单位吃过的亏，比省下的钱还多。
我在行业里做了快十年信息化集成，经手过四个地级市、两个新区的路侧停车平台从无到有的过程。今天不聊虚的，就站在业主方视角，把微服务架构选型里几个最容易踩的坑，摊开来说说。
第一个坑：为了“微”而微，把单体硬拆成碎片
很多厂商拿着标准产品改个名，就说自己原生微服务。结果呢？一个车牌识别上报服务、一个计费服务、一个支付回调服务，全靠REST接口来回调。高峰期并发一上来，网络抖动一次，订单状态就乱。业主单位要盯紧：你们的业务域划分有没有边界上下文（Bounded Context）？地磁/视频桩采集、违停取证、清分结算，这些领域是不是真能独立部署、独立扩容？如果拆完之后，一次发版还要十个服务一起动，那不叫微服务，叫“分布式单体”。
第二个坑：忽视数据一致性与最终落库
路侧停车最怕什么？收了钱没记录，或者记录了对不上账。微服务强调异步和解耦，但计费、支付、对账如果只用消息队列“fire and forget”，遇到 broker 积压，就会出现T 1都对不齐。选型时，必须让厂商讲清楚：跨服务的事务怎么补偿？有没有做幂等表和死信队列？我们之前审计过一家厂商，号称日处理百万订单，结果月底人工调账占了三个人力，这就是架构债。
第三个坑：运维复杂度转嫁给业主
微服务不是免维护金牌。K8s、注册中心、链路追踪，这一套下来，业主单位的IT科室扛得住吗？很多标书写着“提供容器化部署”，但真出P0故障，原厂远程都要半小时才进集群。建议业主在选型阶段就明确SLA：是否带托管式运维？是否输出 Grafana 看板和告警规则？别等系统半夜崩了，才发现没人会看 Pod 日志。
第四个坑：边缘与云端的职责模糊
路侧场景特殊，网络丢包常有。如果把所有识别逻辑全放云端，一个路口断网就罢工。靠谱的架构应该端边云协同：边缘箱体做初步车牌校正和断网续传，云端做全局调度。这点一定要写进技术规格书，别信厂商“全云化更先进”的话术。
说到底，微服务只是手段。业主单位选型，得先看自己日均泊次、接入设备类型和自有运维能力，再决定架构粒度。把上面的坑避开，系统才稳得住，审计才过得去。
18581869297
