广东省某充电桩微服务架构及服务器部署方案

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

0. 设计背景与架构目标

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

高并发设备接入能力 —— 大规模 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 设备

架构图：核心数据链路

sequenceDiagram
    participant D as 充电桩设备
    participant F as 前置接入服务 (Netty)
    participant MQ_IN as RabbitMQ (上行队列)
    participant P as 协议处理服务
    participant DB as 数据库/缓存
    participant MQ_OUT as RabbitMQ (下行队列)

    Note over D, P: 1. 设备状态上报/充电启停请求 (高优先级)
    D->>F: 发送报文 (TCP/WebSocket)
    F-->>D: 立即回复ACK (毫秒级)
    F->>MQ_IN: 推送原始报文 (异步)
    MQ_IN->>P: 消费并解析报文
    P->>DB: 异步更新状态/持久化 (不影响链路)
    
    Note over P, D: 2. 业务逻辑处理与控制指令下发
    P->>MQ_OUT: 推送控制指令/响应
    MQ_OUT->>F: 消费控制指令
    F->>D: 发送指令至设备
    D-->>F: 指令响应

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）

架构图：服务组件关系

graph TB
    %% 定义样式
    classDef frontend fill:#e1f5fe,stroke:#01579b,stroke-width:2px
    classDef processor fill:#f3e5f5,stroke:#4a148c,stroke-width:2px
    classDef business fill:#e8f5e8,stroke:#1b5e20,stroke-width:2px
    
    %% 前置接入层
    subgraph "前置接入层 (Netty 长连接维护)"
        F1[dev_gqaa<br/>广汽协议]:::frontend
        F2[dev_jfy<br/>晶福源协议]:::frontend
        F3[dev_ykc<br/>云快充协议]:::frontend
        F4[dev_occp<br/>OCPP协议]:::frontend
    end
    
    %% 协议处理层
    subgraph "协议处理层 (DataManageService集群)"
        P1[实例1<br/>协议解析]:::processor
        P2[实例2<br/>协议解析]:::processor
        P3[实例3<br/>协议解析]:::processor
        P4[实例4<br/>协议解析]:::processor
    end
    
    %% 业务应用层
    subgraph "业务应用层 (运营与管理)"
        B1[backend<br/>运营管理]:::business
        B2[order<br/>订单服务]:::business
        B3[thrid_api<br/>开放API]:::business
        B4[jobTask<br/>定时任务]:::business
        B5[chargeReg<br/>注册中心]:::business
        B6[common<br/>公共模块]:::business
    end
    
    %% 消息队列 - 隐藏节点，用于整理连接线
    MQ1[消息队列]
    MQ2[消息队列]
    MQ3[消息队列]
    MQ4[消息队列]
    
    %% 连接关系 - 上行数据流
    F1 --> MQ1 --> P1
    F2 --> MQ2 --> P2
    F3 --> MQ3 --> P3
    F4 --> MQ4 --> P4
    
    %% 连接关系 - 下行控制流
    P1 --> MQ1 --> F1
    P2 --> MQ2 --> F2
    P3 --> MQ3 --> F3
    P4 --> MQ4 --> F4
    
    %% 协议层到业务层的数据推送
    P1 --> B1
    P1 --> B2
    P2 --> B2
    P2 --> B3
    P3 --> B3
    P3 --> B4
    P4 --> B4
    P4 --> B1
    
    %% 业务层到协议层的指令触发
    B1 -.-> P1
    B2 -.-> P2
    B3 -.-> P3
    B4 -.-> P4
    B3 -.-> P2
    B2 -.-> P3
    
    %% 应用层内部依赖
    B1 --> B6
    B2 --> B6
    B3 --> B6
    B4 --> B6
    B5 -.-> B1
    B5 -.-> B2
    B5 -.-> B3
    B5 -.-> B4
    
    %% 图例说明
    subgraph "图例"
        L1[前置接入层]:::frontend
        L2[协议处理层]:::processor
        L3[业务应用层]:::business
    end

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

架构图：服务器部署拓扑

graph TB
    subgraph IDC [数据中心]
        subgraph Web_Server [Web/接入层]
            W1[负载均衡器 Nginx]
        end
        
        subgraph Frontend_Server [前置接入服务器 x4]
            FS1[dev_gqaa<br>dev_occp]
            FS2[dev_jfy]
            FS3[dev_ykc]
            FS4[备用/灰度]
        end
        
        subgraph Process_Server [协议处理服务器 x4]
            PS1[DataManageService]
            PS2[DataManageService]
            PS3[DataManageService]
            PS4[DataManageService]
        end
        
        subgraph App_Server [应用服务器 x2]
            AS1[backend, order, common]
            AS2[thrid_api, jobTask, chargeReg]
        end
        
        subgraph Middleware_Server [中间件服务器 x2]
            MS1[(RabbitMQ 节点1)]
            MS2[(RabbitMQ 节点2)]
            MS3[(Redis Sentinel)]
        end
        
        subgraph DB_Server [数据库服务器]
            DB1[(MySQL 主库)]
            DB2[(MySQL 从库)]
            DB3[(MySQL 报文库)]
        end
        
        subgraph Monitor_Server [监控服务器 x1]
            MON[Uptime Kuma<br>Prometheus?]
        end
    end
    
    Internet --> W1
    W1 --> Frontend_Server
    Frontend_Server <--> Middleware_Server
    Process_Server <--> Middleware_Server
    Process_Server --> DB_Server
    App_Server --> DB_Server
    App_Server --> Middleware_Server
    App_Server --> Process_Server
    
    Monitor_Server -.->|监控| Web_Server
    Monitor_Server -.->|监控| Frontend_Server
    Monitor_Server -.->|监控| Process_Server
    Monitor_Server -.->|监控| Middleware_Server
    Monitor_Server -.->|监控| DB_Server

9. 架构总结

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

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

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