简介基于 Java 主流技术栈SpringMVC、Spring、MyBatis与 MySQL 构建的物联网监控平台源码界面由 HTML、jQuery、CSS 实现适用于工业设备监控、智能家居环境监测等场景面向需要快速搭建数据采集与远程控制系统的开发者或运维人员。系统集成 TCP/IP、HTTP、MQTT 等通讯协议可无缝对接海康摄像头并具备报警信息管理、自动控制触发、历史数据查询与报表导出、子账户与场景授权等完善功能。压缩包约 832.96MB共 2000 个文件以 jsp、java、js、css 前后端代码为主附带 sql 数据库脚本、xml 及 properties 配置、pdf 与 doc 文档方便二次开发和部署维护。目前已有 245 人学习下载文档齐全、目录结构清晰可帮助读者节省大量自研时间是一套值得参考的成熟物联网监控解决方案。1. 一套 Java 全栈物联网平台源码能替你省掉的是协议栈和组态这两件难事做物联网平台的人都有个共同感受设备接入和组态画布这两件事比想象中耗时得多。一台 Modbus 设备、一个 MQTT 传感器、一路海康摄像头协议各不相同每接一种就要写一遍解析、断线重连、数据入库组态更是从零开始画图元、做属性绑定、调实时刷新。这套基于 Java 全栈技术的物联网平台源码把组态、大屏可视化和通讯协议集成MQTT、TCP、海康摄像头打包在一起意味着你拿到的不是一套空壳代码而是一条从设备数据到浏览器页面的完整链路。如果你正在评估是自研还是基于源码二次开发这篇文章会告诉你这套源码怎么拆、怎么跑、坑在哪。2. 先拆解这套源码组态、大屏、协议接入各自想解决什么问题2.1 Web 组态把传统组态软件的能力搬进浏览器到底少了什么传统组态软件像 WinCC、KingSCADA装在 Windows 上拖拽图元、配置采集驱动功能很全但二次开发基本走封闭接口。Web 组态的思路不同前端用 SVG 或 Canvas 画图元把图元的位置、颜色、数据源保存成 JSON后端只负责存储和推送实时值。运行时浏览器拿着 JSON 渲染画面再通过 WebSocket 接收数据刷新。这套 Java 全栈源码里的组态模块常见做法是前端 Vue SVG后端存组态模板和设备绑定关系。好处是部署简单客户打开浏览器就能看省掉插件安装。代价是复杂动画、历史曲线回放、报警联动这些传统组态自带的能力在 Web 组态里往往需要自己补。源码里一般内置了基础图元库比如管道、阀门、仪表、传感器图标够画流程工艺图。你要是想把它做成类似 WinCC 那种重型画面就得往图元脚本和动画编辑器里加代码。组态的核心不是画布渲染而是图元和数据源的绑定。一个温度计图元绑定设备的 temperature 属性运行时后台把最新值推到前端图元指针跟着转。这个绑定关系的数据结构设计决定了组态好不好扩展。源码里通常会有类似dataSource: { deviceId: dev001, property: temperature }的 JSON 配置图元组件统一读取这个字段再订阅对应的实时通道。理解了这条链路你看组态模块的源码就有主线了。2.2 可视化大屏从设备数据到页面像素的完整链路可视化大屏是物联网平台的招牌功能。工厂产值、设备在线率、报警数量、环境温湿度全堆一个屏上。大屏的数据链路比组态更长设备上报 → 协议网关解析 → 后端业务处理 → 写入数据库 → 推送通道 → 前端图表渲染。任何一环慢了大屏就出现数据断层。源码里大屏常见的数据推送方式有两种一种是大屏页面直接订阅 MQTT绕过后端业务层另一种是后端转发到 WebSocket前端再订阅。我更推荐后者。因为大屏需要展示的不只是原始测量值还有聚合结果比如最近一小时的平均温度、设备故障率。这些计算放在后端做前端拿现成数据渲染链路更稳。直接订阅 MQTT 虽然实时性高但长时间大流量下前端很容易被消息淹没也不方便做权限控制。大屏和历史数据是绑在一起的。常见方案是后端定时把设备数据从 Redis 或 MySQL 聚合到一张大屏统计表前端展示时先查一次历史数据再订阅实时增量。这套源码里的大屏模块一般会提供设备总数、今日报警数、实时曲线这几个基础组件你可以照着扩展。做二次开发时先摸清大屏接口返回的字段和推送消息的格式再动手改图表。2.3 协议接入层MQTT、TCP、海康摄像头在源码里的位置协议接入层是物联网平台的地基。源码里这一层通常分三个入口MQTT 客户端、TCP 服务端、摄像头拉流服务。MQTT 负责传感器、DTU、智能仪表这类小数据量设备按主题订阅消息体多用 JSON。TCP 服务端负责 PLC、控制器、防火墙一类走自定义帧协议的设备需要做报文解析。海康摄像头则走独立通道用 RTSP 拉流再转成 HLS 或 WebRTC 供前端播放。三层接进来后数据必须统一收口。源码里一般设计一个DeviceMessage内部模型包含设备标识、属性名、数值、时间戳。MQTT 回调、TCP 解码器、摄像头告警事件最终都转成这个模型再交给消息队列和业务层。统一模型的好处是上层做告警、存储、大屏不用关心底层是什么协议。你接新设备时只需要把新协议解析成DeviceMessage其余链路不用动。选型和架构说完了下面进入实际操作。把源码跑起来你会遇到第一个问题环境版本不匹配启动直接翻车。3. 把源码跑起来环境版本、数据库初始化和最小启动流程3.1 环境搭配JDK 17、MySQL 8、Redis 与 MQTT Broker 怎么选拿到源码第一件事是看pom.xml里的 Spring Boot 版本。如果是 Spring Boot 2.x配套 JDK 8 最稳如果是 Spring Boot 3.x必须 JDK 17 起。我习惯先看pom.xml再定 JDK省得启动时碰到UnsupportedClassVersionError。数据库这块MySQL 8 是主流注意驱动要配套pom.xml里用的是mysql-connector-j那版本就得兼容 MySQL 8。Redis 用于缓存和实时数据临时存储版本 6 以上就行。MQTT Broker 是独立软件平台本身不实现 Broker。源码里如果配置的是本地端口 1883那你需要先启动一个 EMQX 或其他 Broker。有的源码在pom.xml内嵌了 Moquette 这类轻量 Broker但生产不建议用。用 EMQX 的好处是管理界面能直接看连接数、订阅关系出了问题好排查。部署时我把 EMQX 装在独立服务器避免和业务应用抢资源。环境版本搭配参考下表避免头疼组件推荐版本备注JDK8 或 17看 Spring Boot 主版本MySQL8.0必须 utf8mb4 字符集Redis6.x/7.x用于缓存和实时数据MQTT BrokerEMQX 4.x/5.x或 MosquittoNode.js16/18前端构建按 package.json 要求3.2 初始化数据库建库脚本、时区和 utf8mb4 一个都不能少数据库是源码跑起来的第一道坎。源码目录里一般有个sql/文件夹里面放iot_platform.sql。我习惯先手动建库指定字符集和排序规则再导入数据避免 MySQL 默认 latin1 导致中文乱码。mysql -uroot -p -e CREATE DATABASE IF NOT EXISTS iot_platform DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; mysql -uroot -p iot_platform doc/sql/iot_platform.sql逻辑说明第一条命令建库utf8mb4保证能存 emoji 和生僻字第二条命令导入建表语句和初始化数据。如果导入报Unknown database说明第一条命令没执行成功先确认 MySQL 登录权限。导入完成后用show tables;检查是否有设备表、规则表、组态表、报警表。接下来改application.yml里的数据源配置。这里的坑多是时区和参数拼写。spring: datasource: url: jdbc:mysql://localhost:3306/iot_platform?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root redis: host: localhost port: 6379 password:参数说明characterEncodingutf8是给 JDBC 驱动用的和数据库字符集无关但业内习惯写上serverTimezoneAsia/Shanghai防止 MySQL 8 的时区报错。Redis 密码如果没有留空。还有人会漏掉web端口配置确认server.port是你要的端口默认 8080。3.3 按顺序启动后端、协议网关、前端以及验证标准启动顺序有讲究。先启动 Redis 和 MQTT Broker再启动 Java 后端最后启动前端。后端启动时需要连接 Redis 和数据库如果 Redis 没起来Spring Boot 会一直重试日志刷屏。我先写一个启动脚本按顺序控制。# 1. 启动 Redis取决于你的安装方式 redis-server /etc/redis.conf # 2. 启动 MQTT Broker以 EMQX 为例 emqx start # 3. 编译并启动 Java 后端 cd /opt/iot-platform mvn clean package -DskipTests nohup java -jar target/iot-platform.jar --spring.profiles.activeprod logs/app.log 21 # 4. 启动前端如果是 Vue 项目 cd /opt/iot-platform-web npm install npm run dev逻辑说明-DskipTests跳过测试加速打包--spring.profiles.activeprod指定生产配置如果你的源码里没有prod配置就用default。nohup让进程在后台运行日志重定向到logs/app.log。前端npm install第一次可能很慢挂代理也常见耐心等。验证标准后端日志出现Netty server started或Tomcat started on port(s): 8080说明启动成功。然后访问http://localhost:8080/api/health返回{status:UP}。前端页面能登录、能看到默认的组态画面和大屏模板说明源码环境跑通了。这个健康检查接口如果 404就看日志里有没有DispatcherServlet报错。4. 设备接入与组态绑定实操MQTT、TCP、海康摄像头怎么打通4.1 MQTT 接入订阅设备消息、解析 payload 并写入业务表大多数 IoT 源码都会用 Eclipse Paho 或 Spring Integration MQTT 做客户端。核心是订阅设备上报主题把payload转成业务数据。先看一个典型的订阅回调代码。Component public class MqttMessageHandler { Autowired private DeviceDataService deviceDataService; public void handleMessage(String topic, byte[] payload) { // 过滤非设备主题避免处理系统消息 if (!topic.startsWith(device/)) { return; } String body new String(payload, StandardCharsets.UTF_8); // 假设 payload 为 JSON: {deviceId:dev01,temperature:25.6,humidity:60} JsonObject data JsonParser.parseString(body).getAsJsonObject(); String deviceId data.get(deviceId).getAsString(); Double temperature data.get(temperature).getAsDouble(); // 统一走设备数据服务落库并推送到实时通道 deviceDataService.savePoint(deviceId, temperature, temperature); } }逻辑说明这个方法只关心device/开头的主题防止 MQTT 系统消息混入业务线程。解析 JSON 后把设备 ID、属性名、数值传给savePoint这一步就是统一收口。你接新设备时只需要改 payload 解析这一段后面的入库、推送、告警逻辑不用动。参数说明QoS 建议用 1保证消息至少送达一次同时避免 QoS 2 的性能开销。Broker 端配置max_message_rate等参数前先压测再调不要盲改。clientId必须唯一否则 Broker 会先踢掉旧连接出现反复断连。4.2 TCP 接入解决粘包/半包自定义报文长度字段TCP 设备接入复杂度比 MQTT 高一截尤其是粘包和半包。Netty 里常见做法是自定义ByteToMessageDecoder先解析长度字段再按长度切帧。public class DeviceFrameDecoder extends ByteToMessageDecoder { private static final int MAX_FRAME_LENGTH 1024; Override protected void decode(ChannelHandlerContext ctx, ByteBuf in, ListObject out) throws Exception { // 先等待 4 个字节的长度头 if (in.readableBytes() 4) { return; } in.markReaderIndex(); int length in.readUnsignedShort(); if (length MAX_FRAME_LENGTH) { ctx.close(); // 非法长度直接断开 } if (in.readableBytes() length) { in.resetReaderIndex(); // 半包等待更多数据 } byte[] body new byte[length]; in.readBytes(body); out.add(Unpooled.wrappedBuffer(body)); } }逻辑说明这段代码解决两个问题。粘包时readableBytes大于 length第一次只读出完整的一帧剩下的留在ByteBuf里下次再处理。半包时长度头读到了但内容不完整调用resetReaderIndex回到标记位置等下一次数据到达。out.add输出的就是完整的一帧字节数组业务层拿到后不再关心字节边界。TCP 设备协议千差万别常见的有 Modbus、自定义头部CRC 校验、JSON 换行符分隔。我把解码器设计成策略模式每种协议一个FrameDecoder通过工厂类注册进去。业务 handler 接收解码后的帧再按协议类型解析。这个分层能省掉后期很多改协议的痛苦。4.3 海康摄像头接入RTSP 拉流、鉴权过期与 Web 播放海康摄像头接入到 Java 平台最稳的方案是后端用 FFmpeg 拉 RTSP 流转成 HLS 分片前端用 video.js 播放。先看 FFmpeg 转流命令。ffmpeg -rtsp_transport tcp -i rtsp://admin:password192.168.1.64:554/Streaming/Channels/101 \ -c copy -f hls -hls_time 2 -hls_list_size 3 -hls_flags delete_segments \ /var/www/live/camera01/index.m3u8参数说明-rtsp_transport tcp强制走 TCP避免 UDP 在弱网下丢包花屏/Streaming/Channels/101是海康主码流102是子码流预览用子码流更流畅-hls_time 2每个分片 2 秒hls_list_size 3只保留 3 个分片降低延迟。这个命令在 Java 里用ProcessBuilder启动注意定期检查进程是否存活。摄像头鉴权有个常见坑海康摄像头空闲一段时间后会要求重新鉴权FFmpeg 进程还在但流已经不更新了。我一般在 Java 里定时比如每 30 分钟检查 FFmpeg 进程输出如果接收不到数据或者返回码非零就杀掉进程重新拉起。另外并发拉流很吃带宽如果 20 个摄像头同时推主码流服务器带宽直接打满。我的做法是预览用子码流 转码录像才用主码流。很多平台为了省资源会直接在前端用 WebRTC 播放但海康摄像头原生不支持需要ZLMediaKit或SRS做二次转封装。如果这套源码里没有包含流媒体服务器用 FFmpeg 转 HLS 是最省事的方式延迟 3-5 秒对于监控画面足够。4.4 组态与大屏把设备数据绑定到图元和图表组态画布的图元绑定数据源核心是 JSON 配置。下面是一个简单的温度计图元配置。{ type: thermometer, id: node_01, x: 120, y: 80, dataSource: { deviceId: dev001, property: temperature, aggregate: latest } }逻辑说明dataSource告诉运行时这个图元的数值从哪里来。后端收到设备数据后根据deviceId和property找到对应图元通过 WebSocket 推送新的数值。aggregate字段表示取值策略latest是最近一次值也可以写成avg_1m表示最近一分钟平均值。前端收到推送后更新图元代码结构大致如下。socket.onmessage (event) { const data JSON.parse(event.data); const node diagram.getNode(data.nodeId); if (node) { node.setValue(data.value); // 图元组件内部处理动画 node.updateStyle(); // 可触发颜色/闪烁等联动 } };参数说明diagram.getNode在画布缓存中查找图元实例避免频繁操作 DOM。setValue的方法图元内部可自行实现仪表盘转指针阀门图标变色数字直接更新。大屏图表比如 ECharts 折线图同理订阅device_point主题往series里追加数据再做时间戳窗口裁剪。组态模块最容易设计混乱的是「保存」和「运行」两条路径。编辑时前端是画布组件保存时把整个画布的 JSON 提交后端运行时画布组件进入只读模式后端只推数据。两边状态要分离否则画布一刷新编辑状态丢失。这套源码里如果发现保存后回到运行页图元位置变了多半是这两个模式的数据没有做隔离。5. 避坑与排查这套物联网平台源码在生产前最常见的 5 个坑5.1 设备连上又掉线心跳和 keep-alive 参数互相打架现象用 MQTT 测试工具连平台发一条消息后几十秒内设备就显示离线日志里能看到 MQTT 客户端不断重连。原因设备端设置了自动休眠或者心跳发送间隔大于 Broker 的keep_alive超时时间。MQTT Broker 在超过 keep_alive 时间没收到客户端心跳包就判定客户端掉线主动断开连接。很多传感器为了省电上报间隔 60 秒但 Broker 默认keep_alive只有 30 秒自然会被踢。解决排查两端参数。EMQX 里调整keep_alive到 90 秒或者修改设备端的heartbeat_interval为 20 秒。另外设备必须支持发送 MQTT 心跳包PINGREQ有些模块自带心跳但默认关闭需要打开。这个坑最折磨人因为现象是「连接不稳定」但不报错只能靠抓包确认。5.2 数据已入库但大屏不刷新WebSocket 推送与回查的时序问题现象数据库里能看到最新设备数据但大屏页面上的数值一直停在几分钟前刷新页面才恢复。原因后端写入数据库和推送 WebSocket 消息不是同一个事务。如果先推送再提交前端拿到的是未提交数据数据库回滚后前端就显示了一个不存在的值如果先提交但推送失败前端没有新数据。还有一种是用户开了两个浏览器标签其中一个页面断开了 WebSocket 但代码没有自动重连。解决用 Spring 的TransactionalEventListener(phase TransactionPhase.AFTER_COMMIT)监听事务提交事件再推送消息保证拿到的数据一定已落库。前端统一封装 WebSocket 重连逻辑断线后指数退避重连避免重连风暴。另外大屏的接口要设计成「先查一次全量再订阅增量」不要只依赖推送否则断线期间的数据就丢了。5.3 海康摄像头画面卡顿或黑屏码流参数与鉴权并发现象摄像头接入平台后预览画面每隔几分钟卡一次严重时黑屏FFmpeg 日志报错method OPTIONS failed: 401 Unauthorized。原因海康摄像头默认开主码流4K 分辨率高码率服务器带宽和转码能力扛不住另一个是 RTSP 鉴权过期FFmpeg 进程还活着但已经失效。如果多个页面同时看同一路摄像头FFmpeg 会发起多次拉流浪费资源。解决预览统一用子码流地址后缀用102分辨率降到 1280x720码率限制在 512kbps。用一条 FFmpeg 进程拉流再通过 HLS 分发给多个前端避免每个浏览器各自拉 RTSP。写一个定时任务每 5 分钟检查 FFmpeg 进程的stderr一旦出现401就杀掉进程重启。黑屏时先看 FFmpeg 日志不要盲目重启。5.4 组态图元保存后又变回原样缓存和版本号没对上现象在组态编辑器里拖动图元、修改颜色点击保存提示成功但刷新页面后又回到旧布局。原因前端在保存时把整份画布 JSON 提交给了后端但后端图元数据是缓存到了 Redis保存只更新了 MySQL刷新时前端请求先打到 Redis取到的是旧缓存。还有的源码做了一层版本号控制但编辑器的保存接口没有递增版本号导致新数据覆盖不了旧缓存。解决先看后端保存接口有没有设置CacheEvict。如果没有手动在saveDiagram方法上加上清除对应画布的 Redis key。如果源码用的是版本号方案确认前端每次保存时携带version 1后端做乐观锁比较冲突时提示用户重新加载。这个坑属于源码逻辑不严谨改起来不复杂但影响体验很严重。5.5 TCP 上报数据乱码报文定界必须放在业务解析之前现象串口和 TCP 设备上报的数据到平台后台字符串频繁出现乱码或多字节拼接错误十六进制看是两个半包拼接。原因设备端响应慢数据分多次到达 Netty 的 channelRead业务 handler 拿到每个 ByteBuf 就开始解析没等完整帧。或者粘包时没有按长度切分把两个数据帧的尾部和一个数据帧的头拼在一起。解决检查解码器是否在decode里输出了完整的数据帧。Netty 准则是解码器只负责定界业务 handler 只负责解析内容。我用的是 4.2 节的DeviceFrameDecoder先把长度头解析出来等完整数据到齐了再out.add。业务 handler 里再按照协议格式比如 JSON 或二进制结构解析。这个坑的排查手段是抓包把收到的原始字节流 dump 下来确认粘包和半包现象再改解码器。6. 进阶把协议接入层改造成适合自己业务的插件式框架6.1 抽象协议接口新增一种设备协议需要动哪几个类设备接入的终极形态是插件化。定义一个统一接口MQTT、TCP、摄像头各自实现再通过工厂注册。public interface DeviceAdapter { // 解析出的标准消息统一交给上层 void onMessage(DeviceMessage message); // 启动连接 void start(); // 停止连接 void stop(); }逻辑说明新增一种协议时只需要新建一个实现类在start()里启动 Netty 服务、MQTT 订阅或 FFmpeg 进程在onMessage()里把原始报文转成DeviceMessage。然后在工厂类里注册映射比如ProtocolType.TCP - TcpDeviceAdapter。上层业务不用改。6.2 数据存储优化时序数据按天分表别让 MySQL 扛全量设备采集数据写入 MySQL 时单表数据量超过千万后查询明显变慢。常见做法是按天分表表名带日期后缀。CREATE TABLE device_data_20260711 ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_id VARCHAR(32), property VARCHAR(32), value DECIMAL(10,2), ts DATETIME, INDEX idx_device_ts (device_id, ts) );逻辑说明写入时先算出今天的表名拼接 SQL 插入。查询时也按日期路由。配合定时任务清理 90 天前的数据MySQL 压力可控。更极端的方案是引入 TDengine 或 InfluxDB但那是后话。6.3 上线前验证用模拟器压测 MQTT 与 TCP 接入上限正式上线前我会写一个模拟器用多线程同时建立 MQTT 连接随机 topic 上报。MySQL 和 Redis 的监控看 CPU 和连接数。TCP 压测用 Netty 客户端并发连接每个连接定时发长度固定报文。压测时注意生产环境的连接数限制先测 1000 个并发再逐步加到 5000看服务端 GC 情况和消息延迟。这里有个血泪经验压测通过不代表上线稳因为模拟器数据规律性太强真实设备的抖动、断线重连、乱序报文才是真正的考验。我习惯压测时随机丢包、随机停发消息逼着系统走一遍重连和超时分支。回到开头说的问题这套 Java 全栈物联网平台源码能帮你省掉的是最基础的协议栈、组态画布和大屏框架但真正适配你的业务场景协议插件化、数据分表、压测上线还得自己动手。要是你遇到的是设备报警没推出来、组态动画不丝滑、TCP 报文结构改了一点就解不了包建议先从第 5 章的排查思路入手八成问题都在通道时序和协议定界上。希望帮到你。本文还有配套的精品资源点击获取 Java全栈物联网平台源码解析：从协议接入到Web组态大屏
简介基于 Java 主流技术栈SpringMVC、Spring、MyBatis与 MySQL 构建的物联网监控平台源码界面由 HTML、jQuery、CSS 实现适用于工业设备监控、智能家居环境监测等场景面向需要快速搭建数据采集与远程控制系统的开发者或运维人员。系统集成 TCP/IP、HTTP、MQTT 等通讯协议可无缝对接海康摄像头并具备报警信息管理、自动控制触发、历史数据查询与报表导出、子账户与场景授权等完善功能。压缩包约 832.96MB共 2000 个文件以 jsp、java、js、css 前后端代码为主附带 sql 数据库脚本、xml 及 properties 配置、pdf 与 doc 文档方便二次开发和部署维护。目前已有 245 人学习下载文档齐全、目录结构清晰可帮助读者节省大量自研时间是一套值得参考的成熟物联网监控解决方案。1. 一套 Java 全栈物联网平台源码能替你省掉的是协议栈和组态这两件难事做物联网平台的人都有个共同感受设备接入和组态画布这两件事比想象中耗时得多。一台 Modbus 设备、一个 MQTT 传感器、一路海康摄像头协议各不相同每接一种就要写一遍解析、断线重连、数据入库组态更是从零开始画图元、做属性绑定、调实时刷新。这套基于 Java 全栈技术的物联网平台源码把组态、大屏可视化和通讯协议集成MQTT、TCP、海康摄像头打包在一起意味着你拿到的不是一套空壳代码而是一条从设备数据到浏览器页面的完整链路。如果你正在评估是自研还是基于源码二次开发这篇文章会告诉你这套源码怎么拆、怎么跑、坑在哪。2. 先拆解这套源码组态、大屏、协议接入各自想解决什么问题2.1 Web 组态把传统组态软件的能力搬进浏览器到底少了什么传统组态软件像 WinCC、KingSCADA装在 Windows 上拖拽图元、配置采集驱动功能很全但二次开发基本走封闭接口。Web 组态的思路不同前端用 SVG 或 Canvas 画图元把图元的位置、颜色、数据源保存成 JSON后端只负责存储和推送实时值。运行时浏览器拿着 JSON 渲染画面再通过 WebSocket 接收数据刷新。这套 Java 全栈源码里的组态模块常见做法是前端 Vue SVG后端存组态模板和设备绑定关系。好处是部署简单客户打开浏览器就能看省掉插件安装。代价是复杂动画、历史曲线回放、报警联动这些传统组态自带的能力在 Web 组态里往往需要自己补。源码里一般内置了基础图元库比如管道、阀门、仪表、传感器图标够画流程工艺图。你要是想把它做成类似 WinCC 那种重型画面就得往图元脚本和动画编辑器里加代码。组态的核心不是画布渲染而是图元和数据源的绑定。一个温度计图元绑定设备的 temperature 属性运行时后台把最新值推到前端图元指针跟着转。这个绑定关系的数据结构设计决定了组态好不好扩展。源码里通常会有类似dataSource: { deviceId: dev001, property: temperature }的 JSON 配置图元组件统一读取这个字段再订阅对应的实时通道。理解了这条链路你看组态模块的源码就有主线了。2.2 可视化大屏从设备数据到页面像素的完整链路可视化大屏是物联网平台的招牌功能。工厂产值、设备在线率、报警数量、环境温湿度全堆一个屏上。大屏的数据链路比组态更长设备上报 → 协议网关解析 → 后端业务处理 → 写入数据库 → 推送通道 → 前端图表渲染。任何一环慢了大屏就出现数据断层。源码里大屏常见的数据推送方式有两种一种是大屏页面直接订阅 MQTT绕过后端业务层另一种是后端转发到 WebSocket前端再订阅。我更推荐后者。因为大屏需要展示的不只是原始测量值还有聚合结果比如最近一小时的平均温度、设备故障率。这些计算放在后端做前端拿现成数据渲染链路更稳。直接订阅 MQTT 虽然实时性高但长时间大流量下前端很容易被消息淹没也不方便做权限控制。大屏和历史数据是绑在一起的。常见方案是后端定时把设备数据从 Redis 或 MySQL 聚合到一张大屏统计表前端展示时先查一次历史数据再订阅实时增量。这套源码里的大屏模块一般会提供设备总数、今日报警数、实时曲线这几个基础组件你可以照着扩展。做二次开发时先摸清大屏接口返回的字段和推送消息的格式再动手改图表。2.3 协议接入层MQTT、TCP、海康摄像头在源码里的位置协议接入层是物联网平台的地基。源码里这一层通常分三个入口MQTT 客户端、TCP 服务端、摄像头拉流服务。MQTT 负责传感器、DTU、智能仪表这类小数据量设备按主题订阅消息体多用 JSON。TCP 服务端负责 PLC、控制器、防火墙一类走自定义帧协议的设备需要做报文解析。海康摄像头则走独立通道用 RTSP 拉流再转成 HLS 或 WebRTC 供前端播放。三层接进来后数据必须统一收口。源码里一般设计一个DeviceMessage内部模型包含设备标识、属性名、数值、时间戳。MQTT 回调、TCP 解码器、摄像头告警事件最终都转成这个模型再交给消息队列和业务层。统一模型的好处是上层做告警、存储、大屏不用关心底层是什么协议。你接新设备时只需要把新协议解析成DeviceMessage其余链路不用动。选型和架构说完了下面进入实际操作。把源码跑起来你会遇到第一个问题环境版本不匹配启动直接翻车。3. 把源码跑起来环境版本、数据库初始化和最小启动流程3.1 环境搭配JDK 17、MySQL 8、Redis 与 MQTT Broker 怎么选拿到源码第一件事是看pom.xml里的 Spring Boot 版本。如果是 Spring Boot 2.x配套 JDK 8 最稳如果是 Spring Boot 3.x必须 JDK 17 起。我习惯先看pom.xml再定 JDK省得启动时碰到UnsupportedClassVersionError。数据库这块MySQL 8 是主流注意驱动要配套pom.xml里用的是mysql-connector-j那版本就得兼容 MySQL 8。Redis 用于缓存和实时数据临时存储版本 6 以上就行。MQTT Broker 是独立软件平台本身不实现 Broker。源码里如果配置的是本地端口 1883那你需要先启动一个 EMQX 或其他 Broker。有的源码在pom.xml内嵌了 Moquette 这类轻量 Broker但生产不建议用。用 EMQX 的好处是管理界面能直接看连接数、订阅关系出了问题好排查。部署时我把 EMQX 装在独立服务器避免和业务应用抢资源。环境版本搭配参考下表避免头疼组件推荐版本备注JDK8 或 17看 Spring Boot 主版本MySQL8.0必须 utf8mb4 字符集Redis6.x/7.x用于缓存和实时数据MQTT BrokerEMQX 4.x/5.x或 MosquittoNode.js16/18前端构建按 package.json 要求3.2 初始化数据库建库脚本、时区和 utf8mb4 一个都不能少数据库是源码跑起来的第一道坎。源码目录里一般有个sql/文件夹里面放iot_platform.sql。我习惯先手动建库指定字符集和排序规则再导入数据避免 MySQL 默认 latin1 导致中文乱码。mysql -uroot -p -e CREATE DATABASE IF NOT EXISTS iot_platform DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; mysql -uroot -p iot_platform doc/sql/iot_platform.sql逻辑说明第一条命令建库utf8mb4保证能存 emoji 和生僻字第二条命令导入建表语句和初始化数据。如果导入报Unknown database说明第一条命令没执行成功先确认 MySQL 登录权限。导入完成后用show tables;检查是否有设备表、规则表、组态表、报警表。接下来改application.yml里的数据源配置。这里的坑多是时区和参数拼写。spring: datasource: url: jdbc:mysql://localhost:3306/iot_platform?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root redis: host: localhost port: 6379 password:参数说明characterEncodingutf8是给 JDBC 驱动用的和数据库字符集无关但业内习惯写上serverTimezoneAsia/Shanghai防止 MySQL 8 的时区报错。Redis 密码如果没有留空。还有人会漏掉web端口配置确认server.port是你要的端口默认 8080。3.3 按顺序启动后端、协议网关、前端以及验证标准启动顺序有讲究。先启动 Redis 和 MQTT Broker再启动 Java 后端最后启动前端。后端启动时需要连接 Redis 和数据库如果 Redis 没起来Spring Boot 会一直重试日志刷屏。我先写一个启动脚本按顺序控制。# 1. 启动 Redis取决于你的安装方式 redis-server /etc/redis.conf # 2. 启动 MQTT Broker以 EMQX 为例 emqx start # 3. 编译并启动 Java 后端 cd /opt/iot-platform mvn clean package -DskipTests nohup java -jar target/iot-platform.jar --spring.profiles.activeprod logs/app.log 21 # 4. 启动前端如果是 Vue 项目 cd /opt/iot-platform-web npm install npm run dev逻辑说明-DskipTests跳过测试加速打包--spring.profiles.activeprod指定生产配置如果你的源码里没有prod配置就用default。nohup让进程在后台运行日志重定向到logs/app.log。前端npm install第一次可能很慢挂代理也常见耐心等。验证标准后端日志出现Netty server started或Tomcat started on port(s): 8080说明启动成功。然后访问http://localhost:8080/api/health返回{status:UP}。前端页面能登录、能看到默认的组态画面和大屏模板说明源码环境跑通了。这个健康检查接口如果 404就看日志里有没有DispatcherServlet报错。4. 设备接入与组态绑定实操MQTT、TCP、海康摄像头怎么打通4.1 MQTT 接入订阅设备消息、解析 payload 并写入业务表大多数 IoT 源码都会用 Eclipse Paho 或 Spring Integration MQTT 做客户端。核心是订阅设备上报主题把payload转成业务数据。先看一个典型的订阅回调代码。Component public class MqttMessageHandler { Autowired private DeviceDataService deviceDataService; public void handleMessage(String topic, byte[] payload) { // 过滤非设备主题避免处理系统消息 if (!topic.startsWith(device/)) { return; } String body new String(payload, StandardCharsets.UTF_8); // 假设 payload 为 JSON: {deviceId:dev01,temperature:25.6,humidity:60} JsonObject data JsonParser.parseString(body).getAsJsonObject(); String deviceId data.get(deviceId).getAsString(); Double temperature data.get(temperature).getAsDouble(); // 统一走设备数据服务落库并推送到实时通道 deviceDataService.savePoint(deviceId, temperature, temperature); } }逻辑说明这个方法只关心device/开头的主题防止 MQTT 系统消息混入业务线程。解析 JSON 后把设备 ID、属性名、数值传给savePoint这一步就是统一收口。你接新设备时只需要改 payload 解析这一段后面的入库、推送、告警逻辑不用动。参数说明QoS 建议用 1保证消息至少送达一次同时避免 QoS 2 的性能开销。Broker 端配置max_message_rate等参数前先压测再调不要盲改。clientId必须唯一否则 Broker 会先踢掉旧连接出现反复断连。4.2 TCP 接入解决粘包/半包自定义报文长度字段TCP 设备接入复杂度比 MQTT 高一截尤其是粘包和半包。Netty 里常见做法是自定义ByteToMessageDecoder先解析长度字段再按长度切帧。public class DeviceFrameDecoder extends ByteToMessageDecoder { private static final int MAX_FRAME_LENGTH 1024; Override protected void decode(ChannelHandlerContext ctx, ByteBuf in, ListObject out) throws Exception { // 先等待 4 个字节的长度头 if (in.readableBytes() 4) { return; } in.markReaderIndex(); int length in.readUnsignedShort(); if (length MAX_FRAME_LENGTH) { ctx.close(); // 非法长度直接断开 } if (in.readableBytes() length) { in.resetReaderIndex(); // 半包等待更多数据 } byte[] body new byte[length]; in.readBytes(body); out.add(Unpooled.wrappedBuffer(body)); } }逻辑说明这段代码解决两个问题。粘包时readableBytes大于 length第一次只读出完整的一帧剩下的留在ByteBuf里下次再处理。半包时长度头读到了但内容不完整调用resetReaderIndex回到标记位置等下一次数据到达。out.add输出的就是完整的一帧字节数组业务层拿到后不再关心字节边界。TCP 设备协议千差万别常见的有 Modbus、自定义头部CRC 校验、JSON 换行符分隔。我把解码器设计成策略模式每种协议一个FrameDecoder通过工厂类注册进去。业务 handler 接收解码后的帧再按协议类型解析。这个分层能省掉后期很多改协议的痛苦。4.3 海康摄像头接入RTSP 拉流、鉴权过期与 Web 播放海康摄像头接入到 Java 平台最稳的方案是后端用 FFmpeg 拉 RTSP 流转成 HLS 分片前端用 video.js 播放。先看 FFmpeg 转流命令。ffmpeg -rtsp_transport tcp -i rtsp://admin:password192.168.1.64:554/Streaming/Channels/101 \ -c copy -f hls -hls_time 2 -hls_list_size 3 -hls_flags delete_segments \ /var/www/live/camera01/index.m3u8参数说明-rtsp_transport tcp强制走 TCP避免 UDP 在弱网下丢包花屏/Streaming/Channels/101是海康主码流102是子码流预览用子码流更流畅-hls_time 2每个分片 2 秒hls_list_size 3只保留 3 个分片降低延迟。这个命令在 Java 里用ProcessBuilder启动注意定期检查进程是否存活。摄像头鉴权有个常见坑海康摄像头空闲一段时间后会要求重新鉴权FFmpeg 进程还在但流已经不更新了。我一般在 Java 里定时比如每 30 分钟检查 FFmpeg 进程输出如果接收不到数据或者返回码非零就杀掉进程重新拉起。另外并发拉流很吃带宽如果 20 个摄像头同时推主码流服务器带宽直接打满。我的做法是预览用子码流 转码录像才用主码流。很多平台为了省资源会直接在前端用 WebRTC 播放但海康摄像头原生不支持需要ZLMediaKit或SRS做二次转封装。如果这套源码里没有包含流媒体服务器用 FFmpeg 转 HLS 是最省事的方式延迟 3-5 秒对于监控画面足够。4.4 组态与大屏把设备数据绑定到图元和图表组态画布的图元绑定数据源核心是 JSON 配置。下面是一个简单的温度计图元配置。{ type: thermometer, id: node_01, x: 120, y: 80, dataSource: { deviceId: dev001, property: temperature, aggregate: latest } }逻辑说明dataSource告诉运行时这个图元的数值从哪里来。后端收到设备数据后根据deviceId和property找到对应图元通过 WebSocket 推送新的数值。aggregate字段表示取值策略latest是最近一次值也可以写成avg_1m表示最近一分钟平均值。前端收到推送后更新图元代码结构大致如下。socket.onmessage (event) { const data JSON.parse(event.data); const node diagram.getNode(data.nodeId); if (node) { node.setValue(data.value); // 图元组件内部处理动画 node.updateStyle(); // 可触发颜色/闪烁等联动 } };参数说明diagram.getNode在画布缓存中查找图元实例避免频繁操作 DOM。setValue的方法图元内部可自行实现仪表盘转指针阀门图标变色数字直接更新。大屏图表比如 ECharts 折线图同理订阅device_point主题往series里追加数据再做时间戳窗口裁剪。组态模块最容易设计混乱的是「保存」和「运行」两条路径。编辑时前端是画布组件保存时把整个画布的 JSON 提交后端运行时画布组件进入只读模式后端只推数据。两边状态要分离否则画布一刷新编辑状态丢失。这套源码里如果发现保存后回到运行页图元位置变了多半是这两个模式的数据没有做隔离。5. 避坑与排查这套物联网平台源码在生产前最常见的 5 个坑5.1 设备连上又掉线心跳和 keep-alive 参数互相打架现象用 MQTT 测试工具连平台发一条消息后几十秒内设备就显示离线日志里能看到 MQTT 客户端不断重连。原因设备端设置了自动休眠或者心跳发送间隔大于 Broker 的keep_alive超时时间。MQTT Broker 在超过 keep_alive 时间没收到客户端心跳包就判定客户端掉线主动断开连接。很多传感器为了省电上报间隔 60 秒但 Broker 默认keep_alive只有 30 秒自然会被踢。解决排查两端参数。EMQX 里调整keep_alive到 90 秒或者修改设备端的heartbeat_interval为 20 秒。另外设备必须支持发送 MQTT 心跳包PINGREQ有些模块自带心跳但默认关闭需要打开。这个坑最折磨人因为现象是「连接不稳定」但不报错只能靠抓包确认。5.2 数据已入库但大屏不刷新WebSocket 推送与回查的时序问题现象数据库里能看到最新设备数据但大屏页面上的数值一直停在几分钟前刷新页面才恢复。原因后端写入数据库和推送 WebSocket 消息不是同一个事务。如果先推送再提交前端拿到的是未提交数据数据库回滚后前端就显示了一个不存在的值如果先提交但推送失败前端没有新数据。还有一种是用户开了两个浏览器标签其中一个页面断开了 WebSocket 但代码没有自动重连。解决用 Spring 的TransactionalEventListener(phase TransactionPhase.AFTER_COMMIT)监听事务提交事件再推送消息保证拿到的数据一定已落库。前端统一封装 WebSocket 重连逻辑断线后指数退避重连避免重连风暴。另外大屏的接口要设计成「先查一次全量再订阅增量」不要只依赖推送否则断线期间的数据就丢了。5.3 海康摄像头画面卡顿或黑屏码流参数与鉴权并发现象摄像头接入平台后预览画面每隔几分钟卡一次严重时黑屏FFmpeg 日志报错method OPTIONS failed: 401 Unauthorized。原因海康摄像头默认开主码流4K 分辨率高码率服务器带宽和转码能力扛不住另一个是 RTSP 鉴权过期FFmpeg 进程还活着但已经失效。如果多个页面同时看同一路摄像头FFmpeg 会发起多次拉流浪费资源。解决预览统一用子码流地址后缀用102分辨率降到 1280x720码率限制在 512kbps。用一条 FFmpeg 进程拉流再通过 HLS 分发给多个前端避免每个浏览器各自拉 RTSP。写一个定时任务每 5 分钟检查 FFmpeg 进程的stderr一旦出现401就杀掉进程重启。黑屏时先看 FFmpeg 日志不要盲目重启。5.4 组态图元保存后又变回原样缓存和版本号没对上现象在组态编辑器里拖动图元、修改颜色点击保存提示成功但刷新页面后又回到旧布局。原因前端在保存时把整份画布 JSON 提交给了后端但后端图元数据是缓存到了 Redis保存只更新了 MySQL刷新时前端请求先打到 Redis取到的是旧缓存。还有的源码做了一层版本号控制但编辑器的保存接口没有递增版本号导致新数据覆盖不了旧缓存。解决先看后端保存接口有没有设置CacheEvict。如果没有手动在saveDiagram方法上加上清除对应画布的 Redis key。如果源码用的是版本号方案确认前端每次保存时携带version 1后端做乐观锁比较冲突时提示用户重新加载。这个坑属于源码逻辑不严谨改起来不复杂但影响体验很严重。5.5 TCP 上报数据乱码报文定界必须放在业务解析之前现象串口和 TCP 设备上报的数据到平台后台字符串频繁出现乱码或多字节拼接错误十六进制看是两个半包拼接。原因设备端响应慢数据分多次到达 Netty 的 channelRead业务 handler 拿到每个 ByteBuf 就开始解析没等完整帧。或者粘包时没有按长度切分把两个数据帧的尾部和一个数据帧的头拼在一起。解决检查解码器是否在decode里输出了完整的数据帧。Netty 准则是解码器只负责定界业务 handler 只负责解析内容。我用的是 4.2 节的DeviceFrameDecoder先把长度头解析出来等完整数据到齐了再out.add。业务 handler 里再按照协议格式比如 JSON 或二进制结构解析。这个坑的排查手段是抓包把收到的原始字节流 dump 下来确认粘包和半包现象再改解码器。6. 进阶把协议接入层改造成适合自己业务的插件式框架6.1 抽象协议接口新增一种设备协议需要动哪几个类设备接入的终极形态是插件化。定义一个统一接口MQTT、TCP、摄像头各自实现再通过工厂注册。public interface DeviceAdapter { // 解析出的标准消息统一交给上层 void onMessage(DeviceMessage message); // 启动连接 void start(); // 停止连接 void stop(); }逻辑说明新增一种协议时只需要新建一个实现类在start()里启动 Netty 服务、MQTT 订阅或 FFmpeg 进程在onMessage()里把原始报文转成DeviceMessage。然后在工厂类里注册映射比如ProtocolType.TCP - TcpDeviceAdapter。上层业务不用改。6.2 数据存储优化时序数据按天分表别让 MySQL 扛全量设备采集数据写入 MySQL 时单表数据量超过千万后查询明显变慢。常见做法是按天分表表名带日期后缀。CREATE TABLE device_data_20260711 ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_id VARCHAR(32), property VARCHAR(32), value DECIMAL(10,2), ts DATETIME, INDEX idx_device_ts (device_id, ts) );逻辑说明写入时先算出今天的表名拼接 SQL 插入。查询时也按日期路由。配合定时任务清理 90 天前的数据MySQL 压力可控。更极端的方案是引入 TDengine 或 InfluxDB但那是后话。6.3 上线前验证用模拟器压测 MQTT 与 TCP 接入上限正式上线前我会写一个模拟器用多线程同时建立 MQTT 连接随机 topic 上报。MySQL 和 Redis 的监控看 CPU 和连接数。TCP 压测用 Netty 客户端并发连接每个连接定时发长度固定报文。压测时注意生产环境的连接数限制先测 1000 个并发再逐步加到 5000看服务端 GC 情况和消息延迟。这里有个血泪经验压测通过不代表上线稳因为模拟器数据规律性太强真实设备的抖动、断线重连、乱序报文才是真正的考验。我习惯压测时随机丢包、随机停发消息逼着系统走一遍重连和超时分支。回到开头说的问题这套 Java 全栈物联网平台源码能帮你省掉的是最基础的协议栈、组态画布和大屏框架但真正适配你的业务场景协议插件化、数据分表、压测上线还得自己动手。要是你遇到的是设备报警没推出来、组态动画不丝滑、TCP 报文结构改了一点就解不了包建议先从第 5 章的排查思路入手八成问题都在通道时序和协议定界上。希望帮到你。本文还有配套的精品资源点击获取