超低运维成本，构建自有高性能商业充电运营平台

一 业务说明

1.1 业务场景与环境：

一万桩在线；
一千桩并发充电业务；
奥升高性能试验集群，可实现海量TCP充电桩真实通信仿真环境。

1.2 资源：

服务名称	配置	说明	成本
基础设施服务（设备通信与业务交换服务）	阿里云ECS 2CPU 4G	本演示场景使用1台部署	541.44元/年
用户运营商服务（业务交换与业务平台服务）	阿里云ECS 2CPU 4G	本演示场景使用1台部署	541.44元/年
小程序服务（用户服务）	阿里云ECS 2CPU 4G	本演示场景使用1台部署	541.44元/年
数据库 MySQL	阿里云 RDS Mysql8.0 2CPU 4G 最大IOPS 4800	与ECS同使用区，内网连接	227.99元/年 （阿里云特惠）
缓存服务 Redis	阿里云 Redis倚天版 1GB 高可用 2节点 QPS 100K 最大连接数 10K	与ECS同使用区，内网连接	375.12/年
消息队列服务 RabbitMQ	阿里云ECS 2CPU 4G	本演示场景使用1台部署	541.44元/年
业务脚手架 ruoyi-* / xxl-job	阿里云ECS 2CPU 8G	本演示场景使用1台部署	761.76元/年
Nacos服务	阿里云ECS 2CPU 4G	本演示场景使用1台部署	541.44元/年
		合计费用	4072.07元/年

1.3 并发业务数量：

业务名称	业务介绍	一般频度（10000标准）	消费业务复杂度
桩心跳上送业务	每台充电桩，10s发送一次心跳	1000/s	低
桩实时数据上送业务	每台充电桩，闲时60s发送一次数据（通常>=5分钟），充电时15s发送一次数据	空闲实时数据：150/s 充电实时数据：100/s	空闲（低） 充电（高）
桩订单结算上送业务	充电完成时上送	低于10/s	极高
桩充电价格业务	桩启机和价格变动时交互	集中启机（大于1000/s） 本项目桩采用集中上线方式进行高压测试。	中
业务交换-桩状态改变推送	充电桩状态改变时，向各运营商平台推送状态数据	集中启机、集中插枪 高峰期（大于1000/s）	低
业务交换-充电状态数据推送	向运营平台推送充电状态数据	100/s	高
业务交换-订单结算推送	向运营平台推送订单结算数据	低于10/s	极高

二 演示过程

2.1 一万台充电桩并发上电

持续时间 60s-100s

登录后复制

一万台快充桩开始上线，上线速度约为50-150台/s；
上线后进行充电桩价格校验，并下发充电价格数据至桩侧

• 1.
• 2.

登录后复制

充电桩开机上线中期，数据量逐渐接近心跳1000/s（充电桩10s发送一次心跳）；
充电价格下发和其他业务未堆积；

• 1.
• 2.

登录后复制

一万台设备完成开机，无新上线桩（无价格校验和下发）；
心跳数据稳定在1000/s，桩状态实时数据稳定在150/s；

• 1.
• 2.

2.2 一万台充电桩并发插枪

持续时间20s-26s

登录后复制

一万台充电桩同时插枪，枪状态数据会立刻发送至服务端，产生消息高峰；（状态数据从150/s迅速上升至400+/s）；
由于需要通过互联互通（HTTP）推送至各运营平台，状态推送任务开始小规模堆积；

• 1.
• 2.

登录后复制

一万台插枪进行10s左右，消息处理到达最高峰，受消息推送业务影响，心跳数据存在轻微堆积。

• 1.

登录后复制

一万台插枪完成2s左右，消息迅速恢复至正常水平。（当然，现实情况下不存在所有充电枪同时插枪的可能 ）

• 1.

2.3 一千台充电桩并发下单

随机抽取一千台桩进行并发充电（启动速度约为10+单/s，约60s完成启动）

登录后复制

一千台充电桩逐步启动，心跳数据短暂堆积（由于心跳数据优先级低，因此主要是闲时处理逻辑）

• 1.

登录后复制

启动到352个订单时，消息处理逐渐平滑

• 1.

登录后复制

启动到750个订单时，充电状态推送和桩实时状态数量逐渐增长，用户运营端消费稳定

• 1.

登录后复制

启动到979个订单

• 1.

登录后复制

一千订单完成启动，整个业务环境运行稳定，实时数据（realtime）吞吐量200+/s，符合业务规划预期；
用户业务平台侧消费正常，正常向用户展现数据情况。

• 1.
• 2.

2.4 充电过程保持（含运营商推送）

登录后复制

订单持续7分钟，业务队列处理稳定。

• 1.

2.5 订单陆续结算

登录后复制

订单结算因为充电进度不完全一致，虽每单均预设10元，单并不会同时结束，因此没有产生数据高峰。

• 1.

三 消息队列介绍

3.1 基础设施服务层

登录后复制

heartBeat: 桩心跳消费（队列）
realtimeData: 桩实时数据消费（队列）
priceSender: 桩价格下发（队列）
stationPriceSender: 充电基准价格推送至用户运营商（队列）
connectorStatusNotify: 充电桩状态推送至用户运营商（队列）
chargingStatusNotify:  充电订单状态数据推送至用户运营商（队列）
chargeOrderData: 充电结算订单推送至用户运营商（队列）

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.

3.2 用户运营服务商业务层

登录后复制

upStationStatus: 消费充电桩状态推送
upEquipChargeStatus: 消费充电订单状态数据
upChargeOrderInfo: 消费充电结算订单

• 1.
• 2.
• 3.

四 高性能系统架构说明

4.1 MySQL还是InfluxDB？

本文主要以最优系统成本为目标，在满足可用的情况下，MySQL表现足以支撑规划业务量，InfluxDB在运营统计分析和数据吞吐、压缩上有明显优势，但其仅单服务版免费，高可用（多服务）版费用高出MySQL较多，因此作者会在其他的文章里再讨论InfluxDB的方案。

其实重运营类的公司，只要合理分表，MySQL已经可以完全满足业务需要，不要被忽悠了哦，浪费那么多成本。

如果以数据为核心的公司，作者还是推荐InfluxDB方案的，不过MySQL也的确够用！

4.2 框架设计

奥升充电平台采用微服务体系，在合理规划下具备无限拓展的可能，2核4G“基础设施服务器”即可带动一万台充电桩的日常业务量，高可用版本也仅需要增加1-2个“基础设施服务器”节点。

即 50万根充电桩约需要60-80台2核4G“基础设施服务器”即可保障业务正常工作，其余服务根据吞吐量自行换算。

五 结束语

奥升新能源技术服务平台，致力于高性能高费效比技术框架研发与实施，致力于为客户提供性价比最优的技术解决方案和运维服务。

奥升开源仓库（非商业）

充电管理后台源码

 https://github.com/NaTieJun/orise-mp

原创作者: u_16941055 转载于: https://blog.51cto.com/u_16941055/11641973