微服务架构设计与服务器部署方案《广东省某充电桩平台架构》

微服务架构设计与服务器部署方案《广东省某充电桩平台架构》

0. 设计背景与架构目标

该充电运营平台自 2019 年启动建设，设计接入十万台不同品牌与不同协议的充电桩设备。整体系统的核心要求包括：

高并发设备接入能力 —— 大规模 TCP 长连接稳定保持；毫秒级报文响应 —— 充电启停必须实时响应，延迟容忍度极低；多品牌设备隔离与灵活适配 —— 不同前置服务独立维护升级；高可用与可观测性 —— 运营级别 SLA 要求，异常快速响应；可持续扩容能力 —— 随接入桩企增长动态增加协议处理能力。

在这些约束下，本系统选择 Spring Cloud 微服务体系 + 自主高性能协议前置层 + RabbitMQ 解耦链路 + MySQL 读写分离架构 + Redis 高性能缓存 的技术栈，并刻意不引入 API Gateway，确保协议链路最短、时延最低，保障实时控制能力。

---

架构图：总体架构

---

1. 总体架构设计

整体架构分为五大层：

设备层 → 前置接入层 → 消息队列层 → 协议处理层 → 业务应用层

再辅以：

数据库与缓存层统一监控、告警体系安全体系与权限模型灰度发布与高可用部署策略

---

2. 高速数据流设计（该系统的核心价值点）

为了保证“充电不中断、启停实时、功率上报实时”，系统采用 前置微服务 → MQ → 协议处理 → MQ → 前置服务 → 设备 的高性能闭环。

2.1 数据流关键路径

TCP/WebSocket 桩设备
        ↓
前置接入微服务（Netty）
        ↓
RabbitMQ（不同品牌独立 Virtual Host）
        ↓
协议处理服务（DataManageService 集群）
        ↓
RabbitMQ（回写队列）
        ↓
前置服务发送指令（毫秒级 ACK）
        ↓
TCP/WebSocket 设备

架构图：核心数据链路

2.2 核心原则

前置服务不做业务逻辑，仅做报文收发 + 校验 + ACK
→ 保证毫秒响应，避免耗时操作阻塞 I/O 线程。协议处理层只做业务逻辑，不与设备直接通讯
→ CPU 密集型的解析/持久化不阻塞设备通讯。所有与数据库相关的操作异步化，不影响设备链路
→ 持久化延迟对业务无影响，设备控制链路优先级最高。任何链路的异常不会扩散到其它品牌设备
→ 多品牌隔离：前置服务隔离 + MQ Virtual Host 隔离。

---

3. 架构分层与服务说明

3.1 前置接入层（极高并发 TCP 层）

全部基于 Netty，单机可稳定支撑 万级长连接。
不同厂商、不同协议独立部署，互不影响升级。

服务	协议	适配品牌	特点
dev_gqaa	TCP	广汽	二进制协议，低延迟
dev_jfy	TCP	晶福源	1 分钟状态上报
dev_ykc	TCP	云快充	私有协议
dev_occp	WebSocket	OCPP 1.6/2.0	支持 TLS/WSS

职责：

维护长连接解析报文头、校验完整性将原始报文写入 RabbitMQ毫秒级返回 ACK接收协议处理回写的控制指令

为何不用 API Gateway？

网关层对 TCP/WebSocket 设备通讯并无价值；会带来额外链路延迟（不可接受）；提供 OCPP 的 WSS 终端也不需要 API Gateway。

API Gateway 只会出现在未来 APP 端/第三方 API 的场景，与设备链路完全隔离。

---

3.2 协议处理层（业务逻辑计算层）

服务： DataManageService（4+ 节点集群）

职责：

消费前置层推送的原始 MQ 报文自动识别品牌与协议（设备标识/报文头）使用对应协议解析器处理异步写数据库队列更新 Redis 实时状态（电流、电压、SOC、交易状态）将控制指令推回 MQ → 前置层

关键能力：

无 DB 阻塞：所有数据库写入通过业务队列异步处理高性能批量持久化解析失败报文写死信队列协议异构无影响（可按品牌独立部署解析器）

---

3.3 应用服务层（运营+开放 API）

服务：

服务名	角色
backend	后台运营管理（低并发）
order	订单生命周期管理
thrid_api	App/第三方开放接口（高并发）
jobTask	定时任务中心
chargeReg	服务注册中心
common	公共工具模块

特点

完全与协议链路解耦与设备通讯链路隔离，避免运营压力影响设备

为何 thrid_api 才是高并发点？

因为：

APP 用户量大第三方平台强依赖实时查询查询设备状态全部来自 Redis（不压 DB）

架构图：服务组件关系

---

4. 中间件与存储层

4.1 RabbitMQ —— 项目选型的关键点

你们最终选择 RabbitMQ 的原因非常专业：

✔ 可为每个供应商创建独立 Virtual Host
✔ 出现问题只影响单个桩企
✔ 控制级报文使用专用队列
✔ 延迟极低，稳定性高
✔ 插件生态成熟（延时队列、监控等）

相比：

MQ	放弃原因
ActiveMQ	脆弱、稳定性不够，消息堆积问题突出
RocketMQ	对你们的多租户隔离需求不友好（无 VirtualHost）

RabbitMQ 完全契合充电桩 SaaS 场景。

---

4.2 MySQL 5.7 选型原因

2018-2025 多年验证稳定性极高读写分离架构（主写从读）成熟单表两亿级数据稳定可查业务模型稳定，5.7 已足够成本低，维护门槛低

---

4.3 Redis 缓存

用途：

设备实时在线状态交易中实时功率、电量、计费数据分布式锁（定时任务防重）JWT 黑名单热点站点/电价配置

---

5. 高可用与运维

5.1 灰度发布机制（无停机）

协议服务更新流程：

先更新一台协议处理节点观察一段时间（比如 10～30 min）再逐台滚动更新前置服务是独立的 → 不会影响其它品牌设备

这种方式比 K8s Rollout 更透明更可控，在协议类业务尤其适用。

---

5.2 日志与数据清理

日志量大，按照 3 个月保留报文库按月分表定时任务自动归档保持数据库规模稳定，避免膨胀

---

5.3 监控与告警（Uptime Kuma + 系统指标）

监控所有微服务 /actuator/health监控前置 TCP/WebSocket 端口可用性监控 MySQL 主从延迟监控 Redis 和 RabbitMQ 状态出问题第一时间通知运维/运营对运营人员非常友好（非技术也能理解）

后期可接入 Prometheus + Grafana 做 QPS/JVM/GC 深度监控。

---

6. 扩缩容策略（非 K8s 模型）

你们采用的是非常高效、务实的扩容方式：

协议处理层可通过增加节点横向扩容前置层按品牌拆分，访问压力分散应用层访问量本身不大，不需要自动扩容所有持久化异步化，因此扩容成本极低

结论：无需 K8s，也能做到高可用与可扩容。

---

7. 安全体系

JWT 登录 + 刷新机制第三方 API 调用还需具备数据级权限设备端： TCP 设备使用预共享密钥OCPP 使用 TLS/WSS 敏感接口可加入二次认证（资金类操作）

安全模型完整、覆盖度高。

---

8. 部署拓扑（最终版本）

服务器类型	数量	部署内容
前置接入服务器	4	各品牌独立 Netty 服务
协议处理服务器	4+	DataManageService
应用服务器	2+	backend、order、thrid_api、jobTask、common
主业务数据库	1 主 + 1 从	MySQL 5.7
报文数据库	1	MySQL 5.7
中间件服务器	2	Redis Sentinel + RabbitMQ 集群
监控服务器	1	Uptime Kuma + Nginx

架构图：服务器部署拓扑

---

9. 架构总结

该架构已在真实大规模充电桩运营场景中运行多年，并具有以下优势：

✔ 极强的实时性：核心链路无阻塞，高速闭环 design。
✔ 极高的稳定性：多品牌隔离、自主前置层、高性能 MQ。
✔ 扩容简单：无需容器/K8s，也可轻松线性扩展。
✔ 低运维成本：MySQL 5.7 + Redis + RabbitMQ 均稳定性极高。
✔ 灰度更新安全：协议类服务可独立滚动升级。
✔ 长期验证可行：稳定支撑 20 万设备规模，单表两亿数据无压力。

这是一个真正为“充电桩行业强实时、高并发、异构协议”量身打造的成熟微服务架构。