Cloud API vs Self-Hosted：能源集团如何选择设备数据接入架构
数据出域、凭据管理、等保审计、SLA 责任——5 个采购维度决定部署模式，附 Cloud → Self-Hosted 迁移路径。
某央企的能源公司 PoC 完 Cloud 后,采购阶段最后一周把方向改成了 Self-Hosted。
转折点不是技术问题。是法务问了一句「Token 在哪里保管」、安全问了一句「数据出域不出域」、IT 问了一句「集团 IDaaS 怎么接」。三个问题一问,Cloud 方案直接出局。
技术上 Cloud 完全可以满足那个 PoC。可一旦进入采购委员会的桌面,「能不能跑」就不再是核心问题了。
这篇文章是 ZenovaConnect 三年里陪不同类型客户走过 Cloud / Self-Hosted 选择的复盘。结论是:这是采购问题,不是技术问题。
不是技术问题,是采购问题
Cloud 与 Self-Hosted 在功能上对等——同一套厂商接入、同一套统一 schema、同一套推送通道。技术上能跑的事情,两种模式都能跑。
真正决定选哪一种的,是这 5 个采购维度:
- 数据是否可以出域 — 央企、国企、政府能源平台、大集团有明确合规边界
- 凭据由谁保管 — 你的安全团队能接受第三方持有厂商 API Token 吗
- 网络与安全架构形态 — 你有内网堡垒、CMDB、专线吗
- 谁负责长期维护 — API 改版、安全补丁、扩容,SLA 责任在谁
- SLA 与责任边界 — 出了问题怎么定责、怎么赔
这 5 个维度决定的不是「能不能」,是「适不适合你这家公司」。
架构对比
下面这张图说明两种部署的数据流向差异:
注意右侧的虚线方框——那是你的网络边界。Self-Hosted 模式下,所有数据流路径都在这个边界内。Cloud 模式下,数据要经过 ZenovaConnect 的基础设施。
两种模式跑的是同一套软件,差异只是部署位置。
Cloud 模式适合谁
| 维度 | Cloud 适配性 |
|---|---|
| 上线时间 | 申请 API key → 几小时 |
| 试点验证 | 适合(2–4 周完成厂商覆盖 + schema + 推送验证) |
| 设备规模 | <1 万设备最划算 |
| 数据出域 | 数据流经 ZenovaConnect 基础设施 |
| 凭据保管 | ZenovaConnect 负责 |
| SLA | 99.5% / 99.9%(Pro) |
| 维护成本 | 我们承担,你不需要运维团队 |
三类客户最常选 Cloud:
- 能源 SaaS 团队——产品规模在 1 万设备以下,Cloud 的设备订阅比自己搭建更划算
- PoC 阶段的所有客户——快速验证厂商覆盖、统一 schema、推送链路是否符合预期。后面再决定是否转 Self-Hosted
- 数据合规允许出域的客户——Cloud 模式下设备数据流经 ZenovaConnect 基础设施,然后推送到你的 Webhook / Kafka / MQTT
Cloud 的真实优势不只是「省事」——更重要的是长期维护责任在 ZenovaConnect。API 改版、安全补丁、扩容、新厂商接入,客户不需要管。
Self-Hosted 模式适合谁
| 维度 | Self-Hosted 适配性 |
|---|---|
| 上线时间 | 部署评估 + 实施 = 4–8 周 |
| 试点验证 | 不适合(私有化 PoC 周期长) |
| 设备规模 | 适合任何规模,1 万+ 设备成本优势明显 |
| 数据出域 | 完全不出域 |
| 凭据保管 | 客户保管 |
| SLA | 双方约定,通常根据客户基础设施 |
| 合规 | 等保 2.0 三级 / 国密兼容架构 |
四类客户必须选 Self-Hosted:
- 数据不出域的客户——央企、地方国企、政府能源平台、部分大型集团明确要求设备数据不能流出公司外网。Self-Hosted 部署在客户 IDC 或私有云内,数据全程在客户的网络边界内
- 内网部署 / 集团网络架构——客户已有统一内网、堡垒机、CMDB、专线。Self-Hosted 比 Cloud 更容易接入这些既有体系
- 等保 / 国密 / 合规审计——需要等保 2.0 三级、密码法符合、国密算法适配的场景。Self-Hosted 让数据流路径完全在客户合规边界内,审计直接
- 集团权限体系——已有统一身份(IDaaS、SSO、OA 集成),Self-Hosted 接入更自然
Self-Hosted 的真实代价不在部署本身——是长期维护责任部分转移到客户的运维团队。下一节说责任边界。
责任边界对比
两种模式最大的差异不在功能,在责任分配。
| 项目 | Cloud | Self-Hosted |
|---|---|---|
| 厂商 API 凭据保管 | ZenovaConnect | 客户 |
| 上游 API 改版跟踪 | ZenovaConnect | ZenovaConnect 提供升级包,客户安排部署 |
| SLA | 99.5% / 99.9%(Pro) | 双方约定,通常根据客户基础设施可用性 |
| 数据备份 | ZenovaConnect | 客户 |
| 安全补丁 | ZenovaConnect 推送 | 客户安排部署窗口 |
| 升级节奏 | 持续(灰度) | 客户决定升级时间 |
| 故障排查 | ZenovaConnect | 双方协作,日志在客户侧 |
注意「客户决定升级时间」一行——这对集团客户是优势(可以排在变更窗口期);对小客户是负担(需要有人负责追升级日程)。
从 Cloud 到 Self-Hosted 的迁移路径
我们建议大客户从 Cloud 试点开始,2–3 个月内验证以下四项:
- 你需要的厂商是否都已覆盖
- 统一 schema 是否满足你的产品需求
- 推送通道(Webhook / Kafka / MQTT)与下游系统兼容
- 关键场景——告警、历史回补、下行控制——是否符合预期
试点验证完后,如果决定走私有化,我们提供:
- 部署评估:网络、容量、依赖系统、与集团既有 IT 的对接点
- 部署实施:4–8 周(含培训)
- 运维文档:给客户运维团队
- 年度维护与升级支持
- SLA 包(可选)
这个迁移路径的好处是先用 Cloud 把不确定性消化(产品 / 工程 / 业务层面),再以一个明确的方案进入私有化。Cloud 试点期间的所有适配工作,转 Self-Hosted 后直接复用,不重复。
一句话总结
不要先选「Self-Hosted 还是 Cloud」,先选这三个问题:
- 我的数据可以出域吗
- 我的工程师有没有空运维这套
- 我希望谁承担 SLA 责任
答案明朗了,部署模式就定了。