第二章：平台架构总览
好，咱们直接进入正题。共享储能云平台，说白了就是把一堆储能电站的资源，通过云端统一管起来。那这个平台长什么样？我习惯把它拆成三层来看——IaaS、PaaS、SaaS。这三层各司其职，缺一不可。
2.1 云平台分层架构设计
先说说为什么一定要分层。你想想看，如果所有代码都揉在一起，改个充电策略还得动到底层数据库，那运维同学得疯掉。我在项目里见过不少团队，一开始图省事搞了个单体应用，结果业务一扩张，改一行代码要测三天。嗯，血的教训。
2.1.1 IaaS 层：基础设施即服务
这一层管的是“硬家伙”。服务器、存储、网络、虚拟化，全归它管。说白了，就是给你一块地，你自己往上盖房子。
- 计算资源：建议用 Kubernetes 集群管理容器，别再用裸机了。我早期做项目时，一台物理机挂了，整个调度服务瘫痪了半小时。后来上了 K8s，自动漂移，稳得很。
- 存储资源：储能数据量巨大，一天几十万条充放电记录。我建议用分布式存储，比如 Ceph 或 MinIO。别用单机 MySQL 硬扛，扛不住的。
- 网络资源：VPC 隔离是必须的。不同租户的储能数据，绝对不能串。我曾经见过一个平台，因为网络没隔离，A 租户的电池状态被 B 租户看到了，那叫一个尴尬。
核心原则：IaaS 层要弹性、要隔离、要可扩展。别想着一步到位，先搭起来，再慢慢优化。
2.1.2 PaaS 层：平台即服务
这一层是中间件的大本营。数据库、消息队列、缓存、微服务框架，全在这。我个人的习惯是，能托管的就托管，别自己造轮子。
| 组件 | 推荐方案 | 避坑指南 |
|---|---|---|
| 消息队列 | Kafka / RabbitMQ | 别用 Redis 做消息队列，丢数据你都不知道 |
| 时序数据库 | InfluxDB / TDengine | 储能数据是时序的，别用 MySQL 硬存 |
| 服务注册 | Nacos / Consul | Eureka 2.0 已经停更了，别踩坑 |
| 配置中心 | Apollo / Nacos | 配置别写死在代码里，改一次发版一次，太蠢了 |
这里我要多说一句。PaaS 层的选型，直接决定了你后面运维的幸福感。我曾经在一个项目里用了自研的消息队列，结果半年后写它的人离职了，没人会修。从那以后，我坚决只用社区活跃的开源方案。
2.1.3 SaaS 层：软件即服务
这一层是用户直接看到的。运营后台、租户管理、充放电策略配置、收益报表，全在这。SaaS 层的核心是多租户隔离。
- 租户隔离：每个储能电站的拥有者，看到的数据只能是自己家的。我建议用数据库字段隔离，别搞独立数据库，成本太高。
- 功能模块化：充电管理、放电管理、收益结算、告警中心，拆成独立模块。这样哪个模块出问题，不影响其他。
- API 网关：统一入口，统一鉴权。别让每个微服务都自己搞一套鉴权，那会乱成一锅粥。
我的经验：SaaS 层最容易被忽视的是“计费模块”。共享储能的核心是交易，计费逻辑一定要清晰。我曾经见过一个平台，因为计费公式写错了，一个月亏了十几万。嗯，后来那个程序员被开了。
2.2 微服务与容器化部署方案
好，三层架构说完了。那具体怎么落地？我推荐微服务 + 容器化。为什么？因为储能业务变化快，今天要对接一个新电站，明天要改一个调度策略。微服务能让你只改一小块，不影响全局。
2.2.1 微服务拆分原则
微服务不是拆得越细越好。我见过一个团队，把用户管理拆成了 5 个微服务，结果一个注册功能要调 3 个服务，延迟高得吓人。我的原则是：按业务边界拆。
- 设备管理服务：管电池、PCS、BMS 的注册和状态上报
- 调度策略服务：管充放电策略的制定和执行
- 交易结算服务：管租户之间的电量交易和费用结算
- 告警通知服务：管异常告警和推送
- 用户租户服务：管登录、权限、租户管理
每个服务独立数据库，独立部署。服务之间通过 API 或消息队列通信。别搞 RPC 直连，耦合太深。
2.2.2 容器化部署
容器化我选 Docker + Kubernetes。为什么？因为储能平台要 7x24 小时在线，K8s 的自动恢复能力太香了。我一个节点挂了，Pod 自动漂移到另一个节点，用户无感知。
# 一个简单的部署示例
apiVersion: apps/v1
kind: Deployment
metadata:
name: dispatch-service
spec:
replicas: 3
selector:
matchLabels:
app: dispatch
template:
metadata:
labels:
app: dispatch
spec:
containers:
- name: dispatch
image: shared-storage/dispatch:v2.1.0
ports:
- containerPort: 8080
resources:
requests:
memory: "512Mi"
cpu: "250m"
limits:
memory: "1Gi"
cpu: "500m"
注意：资源限制一定要设。我曾经见过一个没设 limits 的服务，内存泄漏把整个节点打爆了。嗯，从那以后我每个 Pod 都写 resources。
2.3 技术选型原则
技术选型这事儿，我踩过的坑比走过的路还多。总结几条原则，你照着做，至少不会出大错。
- 选熟不选新：新技术看着酷，但坑也多。我建议选社区活跃、文档齐全的。比如 Spring Cloud 比某些自研框架靠谱得多。
- 选轻不选重：储能平台的核心是调度和交易，不是大数据分析。别一上来就上 Hadoop，一个 MySQL + Redis 就能解决大部分问题。
- 选开不选闭：开源方案出了问题，你能自己修。商业软件出了问题，你得等厂商。储能业务等不起。
- 选稳不选快：性能差一点可以优化，稳定性差一点就是事故。我宁愿用慢一点的方案，也不愿意半夜被电话叫起来。
一句话总结：技术选型没有银弹。适合你团队、适合你业务、适合你运维能力的，才是最好的。
2.4 架构总览图
说了这么多，不如一张图来得直观。下面是我画的共享储能云平台分层架构图，你一看就明白了。
这张图我画得比较简洁。实际项目中，每一层下面还有更多细节。但核心逻辑不变：底层管资源，中间层管能力，上层管业务。各层之间通过 API 通信，互不干扰。
一个小建议：刚开始做架构时，别想着一步到位。先把三层搭起来，跑通一个最简单的流程——比如“一个租户登录，查看自己电站的实时状态”。然后再慢慢加功能。我见过太多团队，架构画得天花乱坠，结果半年了还没上线。
好了，这一章的内容就到这。架构总览是地基，地基打好了，后面盖楼才稳。下一章咱们聊聊具体的业务模块设计，到时候我会拿一个真实的储能调度案例来讲。
公众号:蓝海资料掘金营，微信deep3321