# 驱动一崩，平台全挂——被现场事故逼出来的物联网平台，我把它开源了

做过工业数采的同学应该都遇到过类似的事：某个协议的采集模块出了问题，整个平台跟着挂。监控白屏、告警失联，客户电话马上就到。

根子上的原因是驱动和平台挤在一个进程里，共享同一个 JVM。协议代码千奇百怪，谁的内存泄漏、谁的死循环，都是全平台陪葬。

我两年前被这个问题折磨得不轻，后来下决心重写了架构：每个协议驱动独立成一个进程，崩了就崩了，平台和其他协议照常跑。这就是这次开源的 UNIHH-IOT——一套 Java 技术栈的工业物联网数据采集与管理平台，断断续续磨了两年多，在几个项目上稳定跑下来之后，索性整理出来开源，Apache 2.0 协议，随便用。

- GitHub：https://github.com/unihh-iot/UNIHH
- Gitee：https://gitee.com/giteeRepo/unihh

先看张图，这是平台的监控大盘：

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-4868272/09b2b8d4c939c8d897605bbe0336dc9e.png)


设备在线情况、告警统计、实时曲线都在这一屏。下面按我踩坑的顺序，聊聊这套东西的设计取舍，有些地方做得也不算完美，放到最后说。

## 为什么不用 SPI 动态加载驱动

重写架构的时候，我认真评估过主流方案：把驱动做成 jar 包，用 SPI + 自定义 ClassLoader 在平台进程内热加载。ThingLinks 等一些平台就是这么干的，看着很优雅——用户上传个 jar，驱动就装上了。

但我放弃了这个方案。之前维护单体平台的那两年，ClassLoader 泄漏、依赖冲突、驱动里一个死循环拖垮整个平台，这些坑我一个没躲过。热加载的 jar 卸载不干净导致 Metaspace 涨上去，这种问题线上查起来能把人逼疯。

所以 UNIHH-IOT 的驱动就是普通的 Spring Boot 微服务。Modbus 驱动、西门子 S7 驱动、OPC UA 驱动，各自一个进程，各自一个端口（28011、28012、28013），崩了重启就行，平台主进程和其他协议完全不受影响。新写一个协议就是新建一个 Maven 工程的事，不需要实现任何平台的 SPI 接口去"注册"自己。

驱动管理界面长这样，每个驱动一张卡片，能看到在线状态，还有个"通道心跳自检"按钮，点一下会真实探测驱动进程的 HTTP 端点并计算往返时延，不是只看数据库里那个状态字段：

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-4868272/e87e4478ec2951871bf175b2cb21191c.png)


代价当然有：部署上比单体复杂，一个驱动一个进程，内存占用是"多个 JVM"而不是"一个 JVM"。不过我给驱动做了极限压内存的调优（后面细说），单个驱动进程 32~64MB 堆就能跑，换来的是故障隔离，我认为值。

## 驱动断电了，平台 15 秒内必须知道

工业现场最常见的事故不是代码 bug，是有人拔电源、换 PLC、踢掉网线。以前遇到过很尴尬的情况：驱动明明断了，平台页面上还显示在线，客户拿着在线状态去排查设备，查了一下午发现是平台骗人。

这次我把驱动的存活检测做成了三层：

1. **LWT 遗嘱**。驱动连 MQTT 总线（EMQX）时先注册遗嘱消息，进程崩溃或断网，Broker 会替它广播下线通知，平台立刻把驱动和它下挂的所有设备置为离线。这是最快的一层，秒级。
2. **5 秒心跳**。驱动每 5 秒往总线上报一次心跳和活跃通道数。
3. **15 秒看门狗**。万一遗嘱消息也没送达（网络分区的时候会发生），后台的看门狗巡检发现心跳超过 15 秒没更新，兜底置离线。

整套机制走的是 EMQX 的 retained 消息，平台重启也不会拿到过期的在线状态。驱动和平台之间的所有通信——注册、心跳、配置下发、数据上报、反向控制——全走 MQTT 主题，这个决定让两边彻底解耦：驱动可以跑在车间另一台机器上，甚至跑在客户内网里，只要能连上总线就行。

## 物模型：属性、服务、事件

设备建模这块我没发明新概念，就是行业通用的三要素：属性（能读什么）、服务（能调什么）、事件（会上报什么）。物理点位通过映射绑定到物模型测点上，比如 S7 的 DB10.DBD4 这个地址，绑到"1号炉温度"这个属性上。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-4868272/8ce28e90c011bff4c50653b0e4704c08.png)


为什么坚持要做这层抽象？因为前端和规则引擎不应该关心点位是 DB 块还是 Modbus 寄存器还是 OPC UA 的 NodeId。绑好之后，上层看到的就是干净的"设备-属性-值"，换个协议，业务层一行代码不用改。

设备台账界面，能看到每台设备的在线状态和所属驱动：

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-4868272/744e7fbb5ef8b75bc932811fb54b506c.png)


## RS485 总线上，写寄存器这件事必须排队

这套平台不光能读，还能写——反向控制是工业场景绕不开的需求，改个设定值、远程启停一台电机，都要求指令下发到寄存器。

这里有个特别现实的坑：一条 RS485 总线是半双工的，一条 Modbus TCP 链路通常也就一个 TCP 会话。前端的采集轮询和用户的反写指令如果同时打到这条链路上，轻则粘包错帧，重则设备直接不回话。我在现场见过因为并发写导致仪表进入异常状态，最后是断电重启才恢复的。

所以驱动底层做了**通道级的公平互斥锁**：以物理链路（目标设备连接）为粒度加锁，同一时刻这条总线上只有一个读写操作在跑，读和写都老老实实排队。采集周期内被反写指令"插队"，也只会慢一个周期，不会乱。

从网页上下发一条反写指令，链路是这样的：前端 → 网关（28000）→ 管理中心（28001）→ MQTT 的 cmd 主题 → 驱动拿锁排队 → 寄存器写入。整条链路毫秒级，实测在同一台机器上几十毫秒内能到设备。

实时采集监控页面，每个点位的最新值、品质和时间戳都在：


![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-4868272/7404368a992a0014c649a5d69de88151.png)
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-4868272/d609ff4bdcdca7d0399bca4173df2d35.png)
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-4868272/4acc9642e6848b2d9b98eef4df40b3c2.png)


## 规则引擎和告警

数据上报到总线之后，数据中心服务（unihh-data，28002）负责消费：清洗、按物模型校验、跑规则、判断告警、然后分流入库。

规则引擎目前是表单配置式的——选设备、选属性、设阈值和持续时间、配告警级别和动作，还不支持可视化的拖拽编排。这个我承认是偷懒了，但表单式胜在上线快，现场实施的人员学几分钟就能配。可视化编排在我清单上，优先级看这版发出去的反馈。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-4868272/23494e1432518391ac125d342baee0a6.png)
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-4868272/c3de1c6ba57174ac159f45c0594bd4c7.png)


告警记录页，触发时间、触发值、处理状态都有留痕：

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-4868272/b24e2855462304f306b93332f2c9a3d7.png)
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-4868272/0415e3c1b2401acaf9c2c1989246792a.png)


## 存储做成了可插拔的

时序数据往哪放，每家的情况不一样，所以我没把存储写死。`unihh-storage` 模块用策略模式做了一个路由层，统一接口就五个方法：初始化、单条存、批量存、查历史、关闭。内置了四个实现：内存环形缓冲、Redis 实时快照、MySQL、TDengine。TDengine 负责专业时序落库，MySQL 兜底存配置和低频数据，Redis 存点位最新值供页面秒开。

理论上你写一个 InfluxDB 的实现类扔进去就能用，接口就那么几个方法，半小时的活。

## 它有多省内存

驱动独立进程的架构，最容易被质疑的就是内存。所以我在这套代码上做了比较极端的约束：通信链路上的读写串行化复用缓冲、高频路径上基本不创建临时包装对象、JVM 参数用小堆 + Serial GC（这种进程数多、堆又小的场景，G1 自己的开销反而不划算）。

实际跑下来的数字：核心业务服务 64~128MB 堆，单个驱动进程 32~64MB 堆。一套最小的系统（网关 + 管理中心 + 数据中心 + 一个驱动 + EMQX + MySQL + Redis）加起来 1GB 内存的工控机就能跑。这个配置是给边缘部署留的余地——很多项目的现场根本没有"服务器"，就一个工控机或者树莓派挂在配电柜里。

启动就是普通的 `java -jar`，没有注册中心、没有配置中心、没有 K8s 依赖。微服务间地址就是 application.yml 里写死的 IP 和端口。有人可能觉得这不"云原生"，但工业现场的部署环境就那样，能双击启动、能在没外网的内网跑起来，比什么都重要。

## 自己动手写一个驱动

这是我认为这套平台最值得玩味的部分：写一个新协议驱动，核心工作量就三个方法。

第一步，Maven 引入 `unihh-protocol` 这个底座依赖。第二步，继承 `AbstractDriverPlugin`：

```java
@Component
@IoTDriver(code = "custom-protocol", name = "自定义协议驱动", version = "1.0.0")
public class CustomDriverPlugin extends AbstractDriverPlugin {

    @Override
    public boolean openConnection(DeviceConfig config) throws Exception {
        // 和设备握手建连
        return true;
    }

    @Override
    public ParsedPayload readPoints(DeviceConfig config,
                                    List<ThingModel.PropertySpec> points) throws Exception {
        ParsedPayload payload = new ParsedPayload();
        // 按点位地址批量读取，填充值、品质、时间戳
        return payload;
    }

    @Override
    public boolean writePoint(DeviceConfig config, String pointCode,
                              String address, Object value, String dataType) throws Exception {
        // 反写：编码报文发到设备
        return true;
    }
}
```

第三步，写个普通的 Spring Boot 启动类跑起来。

然后就没了。注册到平台、心跳保活、遗嘱、设备配置拉取、采集轮询调度、反控指令监听，全是底座（`BaseDriverMqttManager` + `DriverPollingEngine`）自动托管的。你要关心的只有一件事：这个协议的报文怎么读、怎么写。连字节序这种烦人的东西，底座里也放了工业大小端工具类。

仓库里的 Modbus、S7、OPC UA 三个驱动就是照这个模式写的，既是功能也是示例——想知道某个钩子怎么用，直接看这三个驱动的源码比看文档快。

## 怎么跑起来

官方镜像把 EMQX 的总线配置和鉴权都预置好了，两行命令：

```bash
docker pull registry.cn-shenzhen.aliyuncs.com/deversun/unihh-emqx:v20261009

docker run -d --name unihh-emqx -p 1883:1883 -p 18083:18083 \
  registry.cn-shenzhen.aliyuncs.com/deversun/unihh-emqx:v20261009
```

然后按 README 里的顺序把后端 jar 和前端跑起来（也可以用仓库里的 docker-compose 一键起）。平台默认账号 admin / unihhiot，EMQX 控制台账号 admin / public，详细的端口和配置说明 README 里都写了，不在这里重复占篇幅。

## 最后说点实话

把项目翻出来开源，总得说说它现在还不行的地方：

- 内置驱动就三个：Modbus（TCP/RTU）、西门子 S7、OPC UA。BACnet、DLT645 这些在计划里，但还没写。
- 规则引擎是表单式的，没有可视化编排，复杂联动逻辑表达不了太多。
- 文档还不够全，README 写了架构和上手，详细的接口文档还在补。有疑问直接提 issue，我看到都会回。
- EMQX 本身支持集群，但这套平台我没在超大规模集群上验证过，目前生产验证的量级是单站点几百个点位。再往上我不敢拍胸脯。

至于为什么开源——这套东西一个人闭门造车做下去，能覆盖的协议和场景终究有限。工业协议这个领域，分散度太高，靠一个人的业余时间是堆不完的，指望商业收费又不现实。索性摊开来，让也在做这块的人少踩几个我踩过的坑。

如果觉得有用，去 GitHub 或 Gitee 点个 star，比什么都实在。想参与的话，先看看 CONTRIBUTING 部分，PR 走 feature 分支，提交信息用语义化前缀就行。

- GitHub：https://github.com/unihh-iot/UNIHH
- Gitee：https://gitee.com/giteeRepo/unihh

技术栈：Java 17 / Spring Boot / EMQX 5.x / MySQL / Redis / TDengine / Vue 3 + Element Plus。协议：Apache 2.0。

做过工业数采的同学应该都遇到过类似的事：某个协议的采集模块出了问题，整个平台跟着挂。监控白屏、告警失联，客户电话马上就到。

工业物联网平台驱动一崩全挂？我开源了一套Java驱动进程隔离架构

工业数据采集低内存，驱动解耦，

物联网

UNIHH-IOT：Java开源工业物联网平台，驱动独立进程崩溃隔离，解决协议采集模块故障导致平台全挂的痛点。支持Modbus、S7、OPCUA驱动，三层存活检测，MQTT通信，物模型三要素，32-64MB低内存占用，可插拔存储，适用于边缘部署，Apache2.0协议。

代码解释

数据中心

数据库

服务器

云原生

Docker

路由

GitHub

MySQL

Redis

MQTT

Java

让每一个 Agent，都跑在云上

iotinsight

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

工业物联网平台驱动一崩全挂？我开源了一套Java驱动进程隔离架构-腾讯云开发者社区-腾讯云

工业物联网平台驱动一崩全挂？我开源了一套Java驱动进程隔离架构

工业物联网平台驱动一崩全挂？我开源了一套Java驱动进程隔离架构

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐