New
EMQX Enterprise 6.3.0 发布:全新功能开关与安全加固,按需灵活部署 →
返回

光伏储能平台:从自建平台平滑迁移到 EMQX Cloud

EMQX Cloud TeamEMQX Cloud Team
2026-11-13应用案例
光伏储能平台:从自建平台平滑迁移到 EMQX Cloud

引言

在全球能源转型和分布式光伏、储能装机快速增长的背景下,光伏逆变器与储能设备正从单纯的发电单元,演变为可感知、可控制、可运维的智能终端。

某企业是一家全球领先的光伏逆变器与储能设备制造商,产品与解决方案覆盖户用、工商业和地面电站场景,在储能和分布式光伏领域具有较高的市场份额,业务遍及全球多个国家和地区。

为支持设备接入、电站监控、运维管理和远程控制,该企业构建了分布式光伏电站智能监控运维平台,将光伏逆变器、储能逆变器、储能电池、智能电表等设备统一接入云端,提供发电监测、组串级诊断、故障告警、远程参数配置等能力。

平台早期基于开源版 EMQX 搭建 MQTT 接入层。随着业务规模和单连接数据流量不断增长,原有架构逐渐暴露出功能与容量瓶颈,出现消息丢失、连接不稳定等问题。为提升数据链路的可靠性和平台的持续扩展能力,该企业决定将自建 MQTT 服务迁移至 EMQX Cloud 专有版,并在不更新设备固件、不影响业务连续性的前提下完成平滑切换,解决长期存在的上行消息丢失问题。

行业背景

分布式光伏与储能设备广泛部署在户用屋顶、工商业园区和地面电站,数量大、分布广,现场网络条件差异明显。设备既要持续上报发电、充放电和运行状态数据,也要接收参数配置、固件升级和调度指令,任何一段链路的长时间中断,都会直接影响电站收益核算和运维响应。因此,云端平台既要保障大规模设备的稳定连接,也要兼顾上行数据采集与下行指令传输的实时性和可靠性。

为降低联网成本,行业普遍采用网关汇聚架构:一个管控网关下挂多台设备,通过 MQTT 云端保持长连接。这样的架构减少了联网模块数量,却把海量设备流量集中到少数网关,对 MQTT 接入层的并发处理能力、消息吞吐和不同类型报文的调度能力提出了更高要求。

与此同时,光伏电站的业务数据具有不同的处理时效和传输特征。常规发电与运行数据需要持续采集并供监控、分析和运维系统使用;离网、过温、电弧故障等告警信息则需要及时送达,远程控制指令也需要保持低时延。平台需要在承载持续数据流量的同时,避免大报文传输影响关键小报文的处理。

项目挑战

面对原有架构暴露出的瓶颈,该企业在迁移过程中需要解决以下挑战:

  • 上行数据链路复杂,消息可靠性难以保障
    平台需要将设备上行数据可靠写入 Kafka。原有链路通过共享订阅分发给后端消费者,再由业务服务写入 Kafka,环节多、排障链路长;高峰时曾出现消息堆积超时、丢失情况,难以定位丢失发生在接入、分发还是写入环节。
  • 网关汇聚模式下,高并发与混合流量并存
    平台接入万级网关连接,单网关下挂多台逆变器、储能电池和电表,峰值上行吞吐达到数千条消息/秒。生产流量以 KB 级报文为主,毫秒级控制指令走 QoS 1,要求低时延;波形和日志文件单包可超过 1MB,并发时瞬间吞吐很大,容易与小包相互影响。
  • Kafka 消息大小限制增加数据集成难度
    下游 Kafka 集群单条消息上限为 1MB,短期内无法升级。EMQX 批量发送时,如果批次超过 1MB,Kafka 会拒收并报错,这类错误不可重试,消息最终被丢弃。迁移方案必须精确配置批量参数,并为超过 1MB 的文件设计旁路,避免堵塞主链路。
  • 存量长连接迁移要求业务连续性
    平台有万级存量长连接。DNS 切换只影响新建连接,已建立的 TCP 连接仍需在旧集群侧分批踢出;设备必须具备自动重连能力,否则迁移后无法自动上线。重连风暴下,连接建立速率需控制在 1000 连接/秒以内,HTTP 认证服务也要承受相应压力;迁移还会丢弃会话状态,需要评估待重传消息和订阅关系的影响。
  • 容量规划与后续运维需要兼顾
    原有自建开源版集群扩容涉及服务器和网络资源准备、容量评估及迁移窗口安排,运维投入较大,也缺乏原厂 SLA 支持。迁移至 EMQX Cloud 专有版后,虽然扩容流程得到简化,但扩容期间仍可能引发设备短时掉线和重连。根据项目评估,扩容预计需要 15–25 分钟,期间可能出现 2–3 次短时连接中断。考虑到业务缺少明确的升级窗口,项目需要在上线前按目标规模完成容量规划,降低后续扩容对业务运行的影响。

解决方案

该企业选择 EMQX Cloud 专有版,部署在与业务同区域的公有云环境,规格按万级连接、万级 TPS 规划。在整体架构中,现场设备先接入 MQTT 网关,再由网关通过原有业务域名与 EMQX Cloud 建立长连接。EMQX Cloud 通过规则引擎完成数据分流:遥测与运行数据经 Kafka 写入业务平台,高敏感告警则通过 HTTP 接口直达告警服务。

下行控制指令由业务平台经 EMQX Cloud 按主题下发至网关和设备;EMQX Cloud 通过 VPC Peering 与业务 VPC 互联,Kafka 流量走私网,避免公网带宽和时延波动。

整体架构:托管集群与私网互联

EMQX Cloud 专有版提供独立托管集群,无需企业自行采购服务器、部署集群或承担版本升级和日常巡检工作。部署规格按万级 TPS 规划,相较当前数千条消息/秒的峰值留有充足余量,为后续业务增长预留容量。

网络方面,EMQX Cloud 通过 VPC Peering 与该企业的业务 VPC 打通,Kafka 流量走私网,不占用公网流量额度;公网 NAT 作为备用通道。专有版提供官方 SLA 和技术支持,迁移及运行中的问题可通过工单获得原厂响应。

平滑迁移:DNS 切换与分批踢连接

迁移目标是让设备「无感」切换到新集群。该企业继续使用原有业务域名,通过 DNS 解析将域名指向 EMQX Cloud 专有版的连接地址,设备端不需要修改固件或重新配置连接地址。

迁移前,企业先创建专有版部署,利用 14 天的免费试用额度,完成了 HTTP 认证、主题重写、规则引擎、Kafka 数据集成和 TLS 证书迁移。随后用测试域名和通配符证书验证 TLS 链路,通过 1000 线试用环境验证连接迁移,并在扩容到 20000 线 POC 环境按稳态、峰值、大包、重连风暴等场景验证。

正式切换时,提前下调 DNS TTL,将业务域名通过 CNAME 指向 EMQX Cloud 连接地址。DNS 切换不影响已建立的 TCP 连接,因此在旧集群侧通过 REST API 分批踢出存量连接,触发设备重新解析域名并连接新集群;连接建立速率控制在 1000 连接/秒以内。

数据迁移采用「先生产者、后消费者」的顺序:

  1. 分批迁移网关设备,使新数据流入 EMQX Cloud;
  2. 保持后端消费者与旧集群的连接,直到积压消息消费完毕;
  3. 确认队列清零后,再切换消费者到新集群。

若出现异常,可通过 DNS 回切和批量踢连接触发设备回连旧集群。

数据集成:Kafka 承接遥测,HTTP 直达敏感告警

针对共享订阅与数据集成链路环节多、排障困难的问题,新架构将核心上行链路简化为「EMQX Cloud 规则引擎 → Kafka」。规则引擎通过 SQL 完成主题过滤、字段提取和路由,再由 Kafka 数据集成写入下游集群;设备上下线事件也通过规则引擎写入 Kafka。

对于离网、过温、电弧故障等高敏感告警,该企业通过规则引擎的 HTTP 集成直接推送至告警服务,只携带告警类型、设备标识、发生时间和关键测点等必要字段。告警链路不再经过高吞吐的数据队列,缩短了从设备上报到运维触达的路径,也避免告警消息在大流量时段排队。

Kafka 集群对批次大小敏感。EMQX 支持设置最大批量字节数低于 Kafka 单条消息 1MB 上限。对于单条超过 1MB 的波形和日志文件,该企业将文件上传改走 HTTP 旁路直传对象存储,MQTT 链路只传输文件元数据和上传结果。

EMQX Cloud 专有版单部署最多支持 50 条规则,该企业将生产规则数量控制在配额以内,并在 POC 中以 20 条规则模拟多 Topic 转发。对于需要更换 Topic 后重发的业务,使用主题重写完成名称转换,减少规则数量占用。

认证、安全与可观测

设备接入采用 HTTP 外部认证,EMQX Cloud 通过 POST 请求调用该企业的认证服务。为降低重连风暴对认证服务的冲击,启用认证结果缓存,最大缓存条数等于部署连接数,确保外部认证服务不再是性能瓶颈。

安全方面,平台公网接入使用 TLS 证书加密设备连接,Kafka 流量通过 VPC Peering 私网传输,API Key 按最小权限分配。

监控方面,EMQX Cloud 提供了内置的指标监控能力,该企业也通过自建的 Prometheus 采集集群连接数、吞吐、规则引擎和 Kafka 集成指标,实现统一监控管理。

EMQX Cloud 核心能力

EMQX Cloud 的以下能力为本次迁移提供了有力支撑:

  • 全托管与官方支持:独立托管集群省去服务器采购、部署、升级和日常巡检,提供官方 SLA 与工单支持。
  • 规模化连接与吞吐:单集群可承载万级连接和万级 TPS,满足万级网关汇聚架构的连接与突发吞吐需求。
  • 规则引擎与双通道集成:内置 SQL 规则,遥测数据经 Kafka 落库,高敏感告警经 HTTP 直达业务系统。
  • HTTP 外部认证与缓存:支持对接企业自有认证服务,并通过认证结果缓存抵御迁移和断网后的重连风暴。
  • 平滑迁移与可观测:可通过 REST API 分批踢连接配合 DNS 完成平滑迁移,并提供连接、吞吐与集成指标。

项目成果

  • 大规模连接与高吞吐稳定运行
    迁移后,平台稳定承载万级网关连接及数千条消息/秒的峰值上行流量。万级 TPS 的部署规格为未来连接规模、数据吞吐及大文件传输增长预留了充足空间。
  • 设备零改造,迁移平稳完成
    全程沿用原有业务域名,无需修改设备固件或连接配置,通过 DNS 切换与存量连接分批迁移,实现设备平滑切换。迁移期间未发生因迁移导致的批量业务中断,并保留了可执行的回退路径。
  • 消息可靠性显著提升
    核心遥测数据直接写入 Kafka,持续压测中写入成功率达到 99.99% 的验收基线。迁移后,原有共享订阅与数据集成链路中的消息丢失问题得到解决;敏感告警和大文件也通过独立链路传输,降低了不同类型流量之间的相互影响。
  • 运维负担降低,平台运行更有保障
    通过 EMQX Cloud 专有版,企业无需自行承担 MQTT 集群的服务器维护、版本升级等工作,并获得官方 SLA、工单支持及 Prometheus/Grafana 监控能力,将更多精力投入业务监控与数据应用。

结语

通过迁移至 EMQX Cloud 专有版,该企业在不改造设备、不影响业务连续性的前提下,完成了万级网关的平滑迁移,解决了原有平台的消息丢失与连接稳定性问题,进一步提升了设备接入与数据传输的可靠性。

随着分布式光伏与储能设备规模持续增长,能源物联网平台对连接能力、数据处理和长期运维提出了更高要求。EMQX Cloud 为该企业提供了稳定、可扩展的 MQTT 基础设施,也为能源行业大规模设备接入与存量平台平滑升级提供了实践参考。

咨询 EMQ 技术专家
联系我们 →

文章作者

EMQX Cloud Team

EMQX Cloud Team

EMQX Cloud 团队专注于提供安全可靠的全托管 MQTT 消息云服务,帮助物联网开发者轻松开启 MQTT 服务,无需担心基础设施的维护负担。

订阅我们的博客