一 业务说明
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； 上线后进行充电桩价格校验，并下发充电价格数据至桩侧
充电桩开机上线中期，数据量逐渐接近心跳1000/s（充电桩10s发送一次心跳）； 充电价格下发和其他业务未堆积；
一万台设备完成开机，无新上线桩（无价格校验和下发）； 心跳数据稳定在1000/s，桩状态实时数据稳定在150/s；
2.2 一万台充电桩并发插枪
持续时间20s-26s
一万台充电桩同时插枪，枪状态数据会立刻发送至服务端，产生消息高峰；（状态数据从150/s迅速上升至400+/s）； 由于需要通过互联互通（HTTP）推送至各运营平台，状态推送任务开始小规模堆积；
一万台插枪进行10s左右，消息处理到达最高峰，受消息推送业务影响，心跳数据存在轻微堆积。
一万台插枪完成2s左右，消息迅速恢复至正常水平。（当然，现实情况下不存在所有充电枪同时插枪的可能 ）
2.3 一千台充电桩并发下单
随机抽取一千台桩进行并发充电（启动速度约为10+单/s，约60s完成启动）
一千台充电桩逐步启动，心跳数据短暂堆积（由于心跳数据优先级低，因此主要是闲时处理逻辑）
启动到352个订单时，消息处理逐渐平滑
启动到750个订单时，充电状态推送和桩实时状态数量逐渐增长，用户运营端消费稳定
启动到979个订单
一千订单完成启动，整个业务环境运行稳定，实时数据（realtime）吞吐量200+/s，符合业务规划预期； 用户业务平台侧消费正常，正常向用户展现数据情况。
2.4 充电过程保持（含运营商推送）
订单持续7分钟，业务队列处理稳定。
2.5 订单陆续结算
订单结算因为充电进度不完全一致，虽每单均预设10元，单并不会同时结束，因此没有产生数据高峰。
三 消息队列介绍
3.1 基础设施服务层
heartBeat: 桩心跳消费（队列） realtimeData: 桩实时数据消费（队列） priceSender: 桩价格下发（队列） stationPriceSender: 充电基准价格推送至用户运营商（队列） connectorStatusNotify: 充电桩状态推送至用户运营商（队列） chargingStatusNotify: 充电订单状态数据推送至用户运营商（队列） chargeOrderData: 充电结算订单推送至用户运营商（队列）
3.2 用户运营服务商业务层
upStationStatus: 消费充电桩状态推送 upEquipChargeStatus: 消费充电订单状态数据 upChargeOrderInfo: 消费充电结算订单
四 高性能系统架构说明
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-charge-cloud
充电小程序源码
https://github.com/NaTieJun/orise-admin
充电管理后台源码
