从 45+ 城市级项目中总结的停充一体化架构设计与实战经验
作者：yuncitys | 停充一体化云平台架构师
写在前面
做了几年城市级智慧停车+新能源充电的项目，从贵州到西藏，从沿海到西北，落地了 45+ 个城市级项目。踩过的坑不少，积累的经验也挺多。
最近在整理架构文档的时候，觉得很多设计决策和技术选型值得写下来分享。如果你也在做停车/充电/城市级物联网平台，或者正在评估这类方案，希望对你有帮助。
本文主要聊三件事：
- 停充一体化为什么要从架构层面融合，而不是简单拼接
- 微服务架构在城市级 IoT 平台中的实际落地经验
- 45+ 个项目踩出来的设备兼容和数据治理经验
一、行业现状：停和充，为什么总是各管各的？
1.1 背景
截至 2024 年底，全国汽车保有量突破 4.3 亿辆，新能源汽车渗透率超过 50%。停车和充电，从两个独立的需求，变成了一个强关联的场景------「停车的时候顺便充电」。
但现实是，大部分城市里的停车系统和充电系统仍然是两套完全独立的东西：
- 停车系统由停车公司做，充电系统由充电桩厂商做
- 两套后台、两个 App、两套计费引擎
- 车主端体验割裂，运营端数据不互通
1.2 我见过的真实痛点
痛点一：数据孤岛
某市路内停车用的是 A 家方案（地磁+PDA），路外用 B 家道闸，充电桩用 C 家平台。三个系统，三套数据库，财务对账靠人工导出 Excel 合并。每月月底，财务团队加班三天对账。
痛点二：计费无法联动
充电用户停车费减免，理论上很合理------充了电，停车费打个折。但实际上，停车系统和充电系统根本不知道对方的存在。要实现这个功能，得写一堆接口做数据同步，而且经常出错。
痛点三：设备绑定
某城投公司花了 2000 万建设智慧停车，结果发现底层系统绑定了某品牌的相机。三年后想升级设备，被告知只能用原厂的。要么忍，要么推翻重来。
痛点四：运维断层
系统上线了，但运营团队不会用。分析不了数据，调不了计费规则，设备报警了不知道怎么处理。最后还是打电话找供应商，供应商排期排到两个月后。
二、架构设计：停充一体化的正确打开方式
2.1 我们的架构思路
我们从第一个项目开始，就没打算做「停车系统 + 充电系统」的拼凑方案。而是从底层数据模型开始，就把停车和充电作为同一个业务域的不同场景来处理。
核心思路：统一订单引擎、统一支付中心、统一数据底座。
┌──────────────────────────────────────────────────────┐
│ 统一云平台 │
├────────────┬────────────┬────────────┬───────────────┤
│ 路内停车 │ 路外停车 │ 新能源充电 │ 运营/财务 │
├────────────┴────────────┴────────────┴───────────────┤
│ 统一订单引擎 | 统一支付中心 | 统一数据底座 │
├──────────────────────────────────────────────────────┤
│ Nacos | Seata | Sentinel | Skywalking │
│ Spring Cloud 微服务架构 │
└──────────────────────────────────────────────────────┘2.2 为什么用微服务？
城市级停充平台有几个特点：
- 模块多：路内停车、路外停车、充电桩、支付、财务、巡查、车主端......十几个业务模块
- 扩展需求差异大：充电业务可能一年翻 10 倍，路内停车相对稳定
- 部署场景复杂：有的城市需要本地化部署，有的可以走云端
- 团队协作：多个团队并行开发不同模块
如果是单体架构，这些问题会非常棘手。微服务天然适合这种场景。
2.3 服务拆分
我们按业务域拆分了 16+ 个独立服务：
| 服务 | 职责 | 设计考量 |
|---|---|---|
| gateway | API 网关 | 统一鉴权、路由、限流 |
| oauth-server | 认证中心 | OAuth2，支持多租户登录 |
| tenant-server | 多租户管理 | 数据隔离，一套平台服务多个运营主体 |
| inside-server | 路内停车 | 地磁/视频桩/PDA 等多方案接入 |
| outside-server | 路外停车 | 道闸控制、车道管理、云岗亭 |
| charging-server | 充电业务 | 充电桩管理、尖峰平谷计费 |
| pay-server | 聚合支付 | 微信/支付宝/ETC/数字人民币 |
| iot-server | IoT 设备接入 | 统一设备管理协议 |
| customer-server | 车主端接口 | 小程序/App 后端 |
| app-server | 巡查 APP | PDA、巡查员移动端 |
| system-server | 系统运营 | 后台管理 |
| job | 定时任务 | 数据统计、催缴触发等 |
每个服务独立部署、独立扩缩容。路内升级不影响路外，充电桩接入量暴增就给充电服务加机器。
2.4 关键中间件选型
| 组件 | 版本 | 选型理由 |
|---|---|---|
| Nacos | 2.0 | 服务注册 + 配置中心一体化，社区活跃 |
| Seata | --- | 分布式事务，保证「计费→扣款→更新泊位」的原子性 |
| Sentinel | 1.8 | 流量控制 + 熔断降级，高峰期自动降级非核心服务 |
| Skywalking | 8.3 | 链路追踪，跨服务调用问题一目了然 |
| MySQL | 5.7 | 稳定可靠，生态成熟 |
| Redis | 6.0 | 缓存 + 分布式锁 |
Seata 的使用有一个实际经验分享：在停车计费场景下，一个停车订单的完成涉及「生成账单 → 扣除余额（或发起支付）→ 更新泊位状态 → 写入统计」多个步骤。如果没有分布式事务，中间任何一步失败都可能导致数据不一致。我们用 Seata 的 AT 模式解决了这个问题，对业务代码的侵入很小。
三、设备兼容：如何做到「什么设备都能接」
3.1 问题
城市级项目最头疼的不是软件，是硬件。每个城市的存量设备千差万别：
- 路内有用地磁的，有用视频桩的，有用高位相机的
- 路外有用臻识相机的，有用华夏相机的
- 充电桩有直流快充，有交流慢充
- 甚至还有巡逻车+人工收费的混合方案
如果系统只能接一种设备，那每到一个新城市就要适配一轮，成本极高。
3.2 我们的做法：统一设备抽象层
我们在 IoT 接入层做了一个 设备抽象协议，把不同品牌、不同类型的设备统一抽象成标准的「设备模型」：
设备类型: 地磁 | 视频桩 | 高位相机 | 道闸 | 地锁 | 充电桩 | PDA
品牌适配: 臻识 | 华厦 | 芊熠 | 百胜 | ...
通信协议: MQTT | HTTP | TCP私有协议上层业务代码不需要关心底层是什么设备、什么品牌，只需要调用统一的设备接口。
3.3 兼容矩阵
| 场景 | 支持设备 |
|---|---|
| 路内感知 | 低位视频路牙机、中位视频桩、视频桩、高位相机、地磁车辆检测器、巡逻车 |
| 路外道闸 | 臻识、华厦、芊熠、百胜等主流品牌 |
| 车位管理 | 车位引导诱导屏、平板锁/U型锁、地锁 |
| 辅助设备 | PDA 手持打票机 |
| 充电设备 | 交流桩（慢充）、直流桩（快充） |
这个设计在实际项目中帮了大忙。某市的项目，路内用的是 A 家的地磁，路外用的是 B 家的道闸，充电桩用的是 C 家的产品。因为我们的系统底层有统一抽象层，三套设备无缝接入，一个后台统一管理。
四、数据治理：城市级平台的数据挑战
4.1 数据量级
一个中等城市，假设 5 万个泊位：
- 每个泊位每天产生 5-10 条停车记录
- 每天 25-50 万条停车数据
- 加上设备心跳、支付流水、催缴记录等
- 每天数据量在 100 万条以上
一年就是 3.6 亿条数据。
4.2 数据清洗
城市级停车最大的数据质量问题来自「异常订单」：
- 无牌车：占比约 5-10%，需要独立的处理流程
- 识别错误：车牌识别置信度低于阈值的订单
- 重复订单：同一辆车在相邻泊位产生重复记录
- 设备故障：地磁误报、相机离线导致的数据缺失
我们的做法是在订单引擎中内置 数据清洗管线：
原始订单 → 置信度过滤 → 去重 → 异常标记 → 人工复核 → 有效订单在某 3 万泊位的项目中，这套管线把订单准确率从 92% 提升到了 98.5%。
4.3 催缴引擎
欠费追缴是城市级停车运营的核心问题之一。
我们设计了一个 多通道自动催缴引擎，支持：
- 微信模板消息催缴 --- 按欠费金额/次数/天数触发
- 短信催缴 --- 定时批量发送
- AI 电话催缴 --- 智能语音，支持回执反馈
配置界面可以灵活设置：欠费金额 > X 元、欠费次数 > Y 次、欠费超时 > Z 天，满足任一条件即触发对应通道的催缴。
实际运营数据显示，三通道联合催缴比单一通道的缴费率提升了约 30%。
五、财务对账：聚合支付的坑
5.1 问题
城市级平台通常要接入多个支付渠道：微信、支付宝、ETC、余额支付、数字人民币等。每个渠道的对账逻辑不一样，退款流程不一样，手续费计算也不一样。
5.2 我们的方案
设计了一个 统一支付抽象层：
业务层 → 支付网关 → 渠道路由 → 微信/支付宝/ETC/...
↓
对账引擎 → 差错识别 → 差错处理自动对账流程：
- 每日凌晨拉取各渠道的交易明细
- 与平台侧的订单数据逐笔对比
- 自动识别差错类型：银行漏单、金额不符、状态不一致
- 生成差错记录，分配给财务人员处理
六、源码交付：一个被低估的决策
在智慧城市项目中，「源码是否交付」往往被当作一个合同条款的小问题。但实际上，它决定了项目的 长期可控性。
不交付源码的隐性成本：
- 每年的运维费（通常按合同额 10-15%）
- 每次二开都要找供应商排期（通常 2-4 周起步）
- 供应商如果倒闭或转型，系统就断了维护
交付源码的价值：
- 自有技术团队可以接手维护和迭代
- 可以对接本地的 ERP、财务、OA 系统
- 数据安全------核心数据在自己的服务器上
- 不依赖任何单一供应商
从技术角度看，交付源码也倒逼我们把代码写得更规范：完整的部署文档、数据库脚本、配置说明、接口文档。这些文档在项目交接时帮了大忙。
七、一些实战经验总结
7.1 关于技术选型
- 全选开源组件，不要选闭源的中间件。Nacos、Seata、Sentinel、Skywalking 都是 Apache 或 Alibaba 开源项目，社区活跃，不用担心断更。
- Java 生态是城市级平台的最佳选择。原因很简单：能找到人。小城市的运维团队大多熟悉 Java，培训成本低。
- MySQL 5.7 够用。城市级数据量到千万/亿级，MySQL 分表就够了，不需要上分布式数据库。
7.2 关于部署
- 建议每台服务 JVM 配置：
-Xmx500m -Xms500m -Xmn180m -Xss1024k - 启动顺序很重要：Nacos → Seata → Sentinel → 业务服务
- 源码和依赖路径 禁止包含中文、空格、特殊字符（这是血泪教训）
7.3 关于项目交付
- 从规划阶段就介入运营，不要等系统上线了才培训运营团队
- 设备安装和系统部署 并行推进，不要串行
- 建营一体化是关键------系统建设的最后一步是运营团队能独立运转
总结
停充一体化不是简单的「停车系统 + 充电系统」，而是需要从 架构设计、数据模型、设备接入、计费引擎 等多个层面做深度融合。
45+ 个城市级项目的实践告诉我们：
- 微服务架构是城市级平台的正确选择
- 设备兼容层决定了方案的适用范围
- 数据治理能力决定了运营效率
- 源码交付决定了项目的长期可控性
如果你也在做类似的项目，欢迎交流讨论。
#智慧停车 #停充一体化 #微服务架构 #SpringCloud #充电桩 #Java #物联网