簡介基于 Java 主流技術棧SpringMVC、Spring、MyBatis與 MySQL 構建的物聯(lián)網(wǎng)監(jiān)控平臺源碼界面由 HTML、jQuery、CSS 實現(xiàn)適用于工業(yè)設備監(jiān)控、智能家居環(huán)境監(jiān)測等場景面向需要快速搭建數(shù)據(jù)采集與遠程控制系統(tǒng)的開發(fā)者或運維人員。系統(tǒng)集成 TCP/IP、HTTP、MQTT 等通訊協(xié)議可無縫對接海康攝像頭并具備報警信息管理、自動控制觸發(fā)、歷史數(shù)據(jù)查詢與報表導出、子賬戶與場景授權等完善功能。壓縮包約 832.96MB共 2000 個文件以 jsp、java、js、css 前后端代碼為主附帶 sql 數(shù)據(jù)庫腳本、xml 及 properties 配置、pdf 與 doc 文檔方便二次開發(fā)和部署維護。目前已有 245 人學習下載文檔齊全、目錄結構清晰可幫助讀者節(jié)省大量自研時間是一套值得參考的成熟物聯(lián)網(wǎng)監(jiān)控解決方案。1. 一套 Java 全棧物聯(lián)網(wǎng)平臺源碼能替你省掉的是協(xié)議棧和組態(tài)這兩件難事做物聯(lián)網(wǎng)平臺的人都有個共同感受設備接入和組態(tài)畫布這兩件事比想象中耗時得多。一臺 Modbus 設備、一個 MQTT 傳感器、一路?？禂z像頭協(xié)議各不相同每接一種就要寫一遍解析、斷線重連、數(shù)據(jù)入庫組態(tài)更是從零開始畫圖元、做屬性綁定、調實時刷新。這套基于 Java 全棧技術的物聯(lián)網(wǎng)平臺源碼把組態(tài)、大屏可視化和通訊協(xié)議集成MQTT、TCP、海康攝像頭打包在一起意味著你拿到的不是一套空殼代碼而是一條從設備數(shù)據(jù)到瀏覽器頁面的完整鏈路。如果你正在評估是自研還是基于源碼二次開發(fā)這篇文章會告訴你這套源碼怎么拆、怎么跑、坑在哪。2. 先拆解這套源碼組態(tài)、大屏、協(xié)議接入各自想解決什么問題2.1 Web 組態(tài)把傳統(tǒng)組態(tài)軟件的能力搬進瀏覽器到底少了什么傳統(tǒng)組態(tài)軟件像 WinCC、KingSCADA裝在 Windows 上拖拽圖元、配置采集驅動功能很全但二次開發(fā)基本走封閉接口。Web 組態(tài)的思路不同前端用 SVG 或 Canvas 畫圖元把圖元的位置、顏色、數(shù)據(jù)源保存成 JSON后端只負責存儲和推送實時值。運行時瀏覽器拿著 JSON 渲染畫面再通過 WebSocket 接收數(shù)據(jù)刷新。這套 Java 全棧源碼里的組態(tài)模塊常見做法是前端 Vue SVG后端存組態(tài)模板和設備綁定關系。好處是部署簡單客戶打開瀏覽器就能看省掉插件安裝。代價是復雜動畫、歷史曲線回放、報警聯(lián)動這些傳統(tǒng)組態(tài)自帶的能力在 Web 組態(tài)里往往需要自己補。源碼里一般內(nèi)置了基礎圖元庫比如管道、閥門、儀表、傳感器圖標夠畫流程工藝圖。你要是想把它做成類似 WinCC 那種重型畫面就得往圖元腳本和動畫編輯器里加代碼。組態(tài)的核心不是畫布渲染而是圖元和數(shù)據(jù)源的綁定。一個溫度計圖元綁定設備的 temperature 屬性運行時后臺把最新值推到前端圖元指針跟著轉。這個綁定關系的數(shù)據(jù)結構設計決定了組態(tài)好不好擴展。源碼里通常會有類似dataSource: { deviceId: dev001, property: temperature }的 JSON 配置圖元組件統(tǒng)一讀取這個字段再訂閱對應的實時通道。理解了這條鏈路你看組態(tài)模塊的源碼就有主線了。2.2 可視化大屏從設備數(shù)據(jù)到頁面像素的完整鏈路可視化大屏是物聯(lián)網(wǎng)平臺的招牌功能。工廠產(chǎn)值、設備在線率、報警數(shù)量、環(huán)境溫濕度全堆一個屏上。大屏的數(shù)據(jù)鏈路比組態(tài)更長設備上報 → 協(xié)議網(wǎng)關解析 → 后端業(yè)務處理 → 寫入數(shù)據(jù)庫 → 推送通道 → 前端圖表渲染。任何一環(huán)慢了大屏就出現(xiàn)數(shù)據(jù)斷層。源碼里大屏常見的數(shù)據(jù)推送方式有兩種一種是大屏頁面直接訂閱 MQTT繞過后端業(yè)務層另一種是后端轉發(fā)到 WebSocket前端再訂閱。我更推薦后者。因為大屏需要展示的不只是原始測量值還有聚合結果比如最近一小時的平均溫度、設備故障率。這些計算放在后端做前端拿現(xiàn)成數(shù)據(jù)渲染鏈路更穩(wěn)。直接訂閱 MQTT 雖然實時性高但長時間大流量下前端很容易被消息淹沒也不方便做權限控制。大屏和歷史數(shù)據(jù)是綁在一起的。常見方案是后端定時把設備數(shù)據(jù)從 Redis 或 MySQL 聚合到一張大屏統(tǒng)計表前端展示時先查一次歷史數(shù)據(jù)再訂閱實時增量。這套源碼里的大屏模塊一般會提供設備總數(shù)、今日報警數(shù)、實時曲線這幾個基礎組件你可以照著擴展。做二次開發(fā)時先摸清大屏接口返回的字段和推送消息的格式再動手改圖表。2.3 協(xié)議接入層MQTT、TCP、海康攝像頭在源碼里的位置協(xié)議接入層是物聯(lián)網(wǎng)平臺的地基。源碼里這一層通常分三個入口MQTT 客戶端、TCP 服務端、攝像頭拉流服務。MQTT 負責傳感器、DTU、智能儀表這類小數(shù)據(jù)量設備按主題訂閱消息體多用 JSON。TCP 服務端負責 PLC、控制器、防火墻一類走自定義幀協(xié)議的設備需要做報文解析。?？禂z像頭則走獨立通道用 RTSP 拉流再轉成 HLS 或 WebRTC 供前端播放。三層接進來后數(shù)據(jù)必須統(tǒng)一收口。源碼里一般設計一個DeviceMessage內(nèi)部模型包含設備標識、屬性名、數(shù)值、時間戳。MQTT 回調、TCP 解碼器、攝像頭告警事件最終都轉成這個模型再交給消息隊列和業(yè)務層。統(tǒng)一模型的好處是上層做告警、存儲、大屏不用關心底層是什么協(xié)議。你接新設備時只需要把新協(xié)議解析成DeviceMessage其余鏈路不用動。選型和架構說完了下面進入實際操作。把源碼跑起來你會遇到第一個問題環(huán)境版本不匹配啟動直接翻車。3. 把源碼跑起來環(huán)境版本、數(shù)據(jù)庫初始化和最小啟動流程3.1 環(huán)境搭配JDK 17、MySQL 8、Redis 與 MQTT Broker 怎么選拿到源碼第一件事是看pom.xml里的 Spring Boot 版本。如果是 Spring Boot 2.x配套 JDK 8 最穩(wěn)如果是 Spring Boot 3.x必須 JDK 17 起。我習慣先看pom.xml再定 JDK省得啟動時碰到UnsupportedClassVersionError。數(shù)據(jù)庫這塊MySQL 8 是主流注意驅動要配套pom.xml里用的是mysql-connector-j那版本就得兼容 MySQL 8。Redis 用于緩存和實時數(shù)據(jù)臨時存儲版本 6 以上就行。MQTT Broker 是獨立軟件平臺本身不實現(xiàn) Broker。源碼里如果配置的是本地端口 1883那你需要先啟動一個 EMQX 或其他 Broker。有的源碼在pom.xml內(nèi)嵌了 Moquette 這類輕量 Broker但生產(chǎn)不建議用。用 EMQX 的好處是管理界面能直接看連接數(shù)、訂閱關系出了問題好排查。部署時我把 EMQX 裝在獨立服務器避免和業(yè)務應用搶資源。環(huán)境版本搭配參考下表避免頭疼組件推薦版本備注JDK8 或 17看 Spring Boot 主版本MySQL8.0必須 utf8mb4 字符集Redis6.x/7.x用于緩存和實時數(shù)據(jù)MQTT BrokerEMQX 4.x/5.x或 MosquittoNode.js16/18前端構建按 package.json 要求3.2 初始化數(shù)據(jù)庫建庫腳本、時區(qū)和 utf8mb4 一個都不能少數(shù)據(jù)庫是源碼跑起來的第一道坎。源碼目錄里一般有個sql/文件夾里面放iot_platform.sql。我習慣先手動建庫指定字符集和排序規(guī)則再導入數(shù)據(jù)避免 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 和生僻字第二條命令導入建表語句和初始化數(shù)據(jù)。如果導入報Unknown database說明第一條命令沒執(zhí)行成功先確認 MySQL 登錄權限。導入完成后用show tables;檢查是否有設備表、規(guī)則表、組態(tài)表、報警表。接下來改application.yml里的數(shù)據(jù)源配置。這里的坑多是時區(qū)和參數(shù)拼寫。spring: datasource: url: jdbc:mysql://localhost:3306/iot_platform?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root redis: host: localhost port: 6379 password:參數(shù)說明characterEncodingutf8是給 JDBC 驅動用的和數(shù)據(jù)庫字符集無關但業(yè)內(nèi)習慣寫上serverTimezoneAsia/Shanghai防止 MySQL 8 的時區(qū)報錯。Redis 密碼如果沒有留空。還有人會漏掉web端口配置確認server.port是你要的端口默認 8080。3.3 按順序啟動后端、協(xié)議網(wǎng)關、前端以及驗證標準啟動順序有講究。先啟動 Redis 和 MQTT Broker再啟動 Java 后端最后啟動前端。后端啟動時需要連接 Redis 和數(shù)據(jù)庫如果 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指定生產(chǎn)配置如果你的源碼里沒有prod配置就用default。nohup讓進程在后臺運行日志重定向到logs/app.log。前端npm install第一次可能很慢掛代理也常見耐心等。驗證標準后端日志出現(xiàn)Netty server started或Tomcat started on port(s): 8080說明啟動成功。然后訪問http://localhost:8080/api/health返回{status:UP}。前端頁面能登錄、能看到默認的組態(tài)畫面和大屏模板說明源碼環(huán)境跑通了。這個健康檢查接口如果 404就看日志里有沒有DispatcherServlet報錯。4. 設備接入與組態(tài)綁定實操MQTT、TCP、海康攝像頭怎么打通4.1 MQTT 接入訂閱設備消息、解析 payload 并寫入業(yè)務表大多數(shù) IoT 源碼都會用 Eclipse Paho 或 Spring Integration MQTT 做客戶端。核心是訂閱設備上報主題把payload轉成業(yè)務數(shù)據(jù)。先看一個典型的訂閱回調代碼。Component public class MqttMessageHandler { Autowired private DeviceDataService deviceDataService; public void handleMessage(String topic, byte[] payload) { // 過濾非設備主題避免處理系統(tǒng)消息 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(); // 統(tǒng)一走設備數(shù)據(jù)服務落庫并推送到實時通道 deviceDataService.savePoint(deviceId, temperature, temperature); } }邏輯說明這個方法只關心device/開頭的主題防止 MQTT 系統(tǒng)消息混入業(yè)務線程。解析 JSON 后把設備 ID、屬性名、數(shù)值傳給savePoint這一步就是統(tǒng)一收口。你接新設備時只需要改 payload 解析這一段后面的入庫、推送、告警邏輯不用動。參數(shù)說明QoS 建議用 1保證消息至少送達一次同時避免 QoS 2 的性能開銷。Broker 端配置max_message_rate等參數(shù)前先壓測再調不要盲改。clientId必須唯一否則 Broker 會先踢掉舊連接出現(xiàn)反復斷連。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 個字節(jié)的長度頭 if (in.readableBytes() 4) { return; } in.markReaderIndex(); int length in.readUnsignedShort(); if (length MAX_FRAME_LENGTH) { ctx.close(); // 非法長度直接斷開 } if (in.readableBytes() length) { in.resetReaderIndex(); // 半包等待更多數(shù)據(jù) } byte[] body new byte[length]; in.readBytes(body); out.add(Unpooled.wrappedBuffer(body)); } }邏輯說明這段代碼解決兩個問題。粘包時readableBytes大于 length第一次只讀出完整的一幀剩下的留在ByteBuf里下次再處理。半包時長度頭讀到了但內(nèi)容不完整調用resetReaderIndex回到標記位置等下一次數(shù)據(jù)到達。out.add輸出的就是完整的一幀字節(jié)數(shù)組業(yè)務層拿到后不再關心字節(jié)邊界。TCP 設備協(xié)議千差萬別常見的有 Modbus、自定義頭部CRC 校驗、JSON 換行符分隔。我把解碼器設計成策略模式每種協(xié)議一個FrameDecoder通過工廠類注冊進去。業(yè)務 handler 接收解碼后的幀再按協(xié)議類型解析。這個分層能省掉后期很多改協(xié)議的痛苦。4.3 ?？禂z像頭接入RTSP 拉流、鑒權過期與 Web 播放?？禂z像頭接入到 Java 平臺最穩(wěn)的方案是后端用 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參數(shù)說明-rtsp_transport tcp強制走 TCP避免 UDP 在弱網(wǎng)下丟包花屏/Streaming/Channels/101是海康主碼流102是子碼流預覽用子碼流更流暢-hls_time 2每個分片 2 秒hls_list_size 3只保留 3 個分片降低延遲。這個命令在 Java 里用ProcessBuilder啟動注意定期檢查進程是否存活。攝像頭鑒權有個常見坑?？禂z像頭空閑一段時間后會要求重新鑒權FFmpeg 進程還在但流已經(jīng)不更新了。我一般在 Java 里定時比如每 30 分鐘檢查 FFmpeg 進程輸出如果接收不到數(shù)據(jù)或者返回碼非零就殺掉進程重新拉起。另外并發(fā)拉流很吃帶寬如果 20 個攝像頭同時推主碼流服務器帶寬直接打滿。我的做法是預覽用子碼流 轉碼錄像才用主碼流。很多平臺為了省資源會直接在前端用 WebRTC 播放但?？禂z像頭原生不支持需要ZLMediaKit或SRS做二次轉封裝。如果這套源碼里沒有包含流媒體服務器用 FFmpeg 轉 HLS 是最省事的方式延遲 3-5 秒對于監(jiān)控畫面足夠。4.4 組態(tài)與大屏把設備數(shù)據(jù)綁定到圖元和圖表組態(tài)畫布的圖元綁定數(shù)據(jù)源核心是 JSON 配置。下面是一個簡單的溫度計圖元配置。{ type: thermometer, id: node_01, x: 120, y: 80, dataSource: { deviceId: dev001, property: temperature, aggregate: latest } }邏輯說明dataSource告訴運行時這個圖元的數(shù)值從哪里來。后端收到設備數(shù)據(jù)后根據(jù)deviceId和property找到對應圖元通過 WebSocket 推送新的數(shù)值。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); // 圖元組件內(nèi)部處理動畫 node.updateStyle(); // 可觸發(fā)顏色/閃爍等聯(lián)動 } };參數(shù)說明diagram.getNode在畫布緩存中查找圖元實例避免頻繁操作 DOM。setValue的方法圖元內(nèi)部可自行實現(xiàn)儀表盤轉指針閥門圖標變色數(shù)字直接更新。大屏圖表比如 ECharts 折線圖同理訂閱device_point主題往series里追加數(shù)據(jù)再做時間戳窗口裁剪。組態(tài)模塊最容易設計混亂的是「保存」和「運行」兩條路徑。編輯時前端是畫布組件保存時把整個畫布的 JSON 提交后端運行時畫布組件進入只讀模式后端只推數(shù)據(jù)。兩邊狀態(tài)要分離否則畫布一刷新編輯狀態(tài)丟失。這套源碼里如果發(fā)現(xiàn)保存后回到運行頁圖元位置變了多半是這兩個模式的數(shù)據(jù)沒有做隔離。5. 避坑與排查這套物聯(lián)網(wǎng)平臺源碼在生產(chǎn)前最常見的 5 個坑5.1 設備連上又掉線心跳和 keep-alive 參數(shù)互相打架現(xiàn)象用 MQTT 測試工具連平臺發(fā)一條消息后幾十秒內(nèi)設備就顯示離線日志里能看到 MQTT 客戶端不斷重連。原因設備端設置了自動休眠或者心跳發(fā)送間隔大于 Broker 的keep_alive超時時間。MQTT Broker 在超過 keep_alive 時間沒收到客戶端心跳包就判定客戶端掉線主動斷開連接。很多傳感器為了省電上報間隔 60 秒但 Broker 默認keep_alive只有 30 秒自然會被踢。解決排查兩端參數(shù)。EMQX 里調整keep_alive到 90 秒或者修改設備端的heartbeat_interval為 20 秒。另外設備必須支持發(fā)送 MQTT 心跳包PINGREQ有些模塊自帶心跳但默認關閉需要打開。這個坑最折磨人因為現(xiàn)象是「連接不穩(wěn)定」但不報錯只能靠抓包確認。5.2 數(shù)據(jù)已入庫但大屏不刷新WebSocket 推送與回查的時序問題現(xiàn)象數(shù)據(jù)庫里能看到最新設備數(shù)據(jù)但大屏頁面上的數(shù)值一直停在幾分鐘前刷新頁面才恢復。原因后端寫入數(shù)據(jù)庫和推送 WebSocket 消息不是同一個事務。如果先推送再提交前端拿到的是未提交數(shù)據(jù)數(shù)據(jù)庫回滾后前端就顯示了一個不存在的值如果先提交但推送失敗前端沒有新數(shù)據(jù)。還有一種是用戶開了兩個瀏覽器標簽其中一個頁面斷開了 WebSocket 但代碼沒有自動重連。解決用 Spring 的TransactionalEventListener(phase TransactionPhase.AFTER_COMMIT)監(jiān)聽事務提交事件再推送消息保證拿到的數(shù)據(jù)一定已落庫。前端統(tǒng)一封裝 WebSocket 重連邏輯斷線后指數(shù)退避重連避免重連風暴。另外大屏的接口要設計成「先查一次全量再訂閱增量」不要只依賴推送否則斷線期間的數(shù)據(jù)就丟了。5.3 ?？禂z像頭畫面卡頓或黑屏碼流參數(shù)與鑒權并發(fā)現(xiàn)象攝像頭接入平臺后預覽畫面每隔幾分鐘卡一次嚴重時黑屏FFmpeg 日志報錯method OPTIONS failed: 401 Unauthorized。原因?？禂z像頭默認開主碼流4K 分辨率高碼率服務器帶寬和轉碼能力扛不住另一個是 RTSP 鑒權過期FFmpeg 進程還活著但已經(jīng)失效。如果多個頁面同時看同一路攝像頭FFmpeg 會發(fā)起多次拉流浪費資源。解決預覽統(tǒng)一用子碼流地址后綴用102分辨率降到 1280x720碼率限制在 512kbps。用一條 FFmpeg 進程拉流再通過 HLS 分發(fā)給多個前端避免每個瀏覽器各自拉 RTSP。寫一個定時任務每 5 分鐘檢查 FFmpeg 進程的stderr一旦出現(xiàn)401就殺掉進程重啟。黑屏時先看 FFmpeg 日志不要盲目重啟。5.4 組態(tài)圖元保存后又變回原樣緩存和版本號沒對上現(xiàn)象在組態(tài)編輯器里拖動圖元、修改顏色點擊保存提示成功但刷新頁面后又回到舊布局。原因前端在保存時把整份畫布 JSON 提交給了后端但后端圖元數(shù)據(jù)是緩存到了 Redis保存只更新了 MySQL刷新時前端請求先打到 Redis取到的是舊緩存。還有的源碼做了一層版本號控制但編輯器的保存接口沒有遞增版本號導致新數(shù)據(jù)覆蓋不了舊緩存。解決先看后端保存接口有沒有設置CacheEvict。如果沒有手動在saveDiagram方法上加上清除對應畫布的 Redis key。如果源碼用的是版本號方案確認前端每次保存時攜帶version 1后端做樂觀鎖比較沖突時提示用戶重新加載。這個坑屬于源碼邏輯不嚴謹改起來不復雜但影響體驗很嚴重。5.5 TCP 上報數(shù)據(jù)亂碼報文定界必須放在業(yè)務解析之前現(xiàn)象串口和 TCP 設備上報的數(shù)據(jù)到平臺后臺字符串頻繁出現(xiàn)亂碼或多字節(jié)拼接錯誤十六進制看是兩個半包拼接。原因設備端響應慢數(shù)據(jù)分多次到達 Netty 的 channelRead業(yè)務 handler 拿到每個 ByteBuf 就開始解析沒等完整幀?；蛘哒嘲鼤r沒有按長度切分把兩個數(shù)據(jù)幀的尾部和一個數(shù)據(jù)幀的頭拼在一起。解決檢查解碼器是否在decode里輸出了完整的數(shù)據(jù)幀。Netty 準則是解碼器只負責定界業(yè)務 handler 只負責解析內(nèi)容。我用的是 4.2 節(jié)的DeviceFrameDecoder先把長度頭解析出來等完整數(shù)據(jù)到齊了再out.add。業(yè)務 handler 里再按照協(xié)議格式比如 JSON 或二進制結構解析。這個坑的排查手段是抓包把收到的原始字節(jié)流 dump 下來確認粘包和半包現(xiàn)象再改解碼器。6. 進階把協(xié)議接入層改造成適合自己業(yè)務的插件式框架6.1 抽象協(xié)議接口新增一種設備協(xié)議需要動哪幾個類設備接入的終極形態(tài)是插件化。定義一個統(tǒng)一接口MQTT、TCP、攝像頭各自實現(xiàn)再通過工廠注冊。public interface DeviceAdapter { // 解析出的標準消息統(tǒng)一交給上層 void onMessage(DeviceMessage message); // 啟動連接 void start(); // 停止連接 void stop(); }邏輯說明新增一種協(xié)議時只需要新建一個實現(xiàn)類在start()里啟動 Netty 服務、MQTT 訂閱或 FFmpeg 進程在onMessage()里把原始報文轉成DeviceMessage。然后在工廠類里注冊映射比如ProtocolType.TCP - TcpDeviceAdapter。上層業(yè)務不用改。6.2 數(shù)據(jù)存儲優(yōu)化時序數(shù)據(jù)按天分表別讓 MySQL 扛全量設備采集數(shù)據(jù)寫入 MySQL 時單表數(shù)據(jù)量超過千萬后查詢明顯變慢。常見做法是按天分表表名帶日期后綴。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 天前的數(shù)據(jù)MySQL 壓力可控。更極端的方案是引入 TDengine 或 InfluxDB但那是后話。6.3 上線前驗證用模擬器壓測 MQTT 與 TCP 接入上限正式上線前我會寫一個模擬器用多線程同時建立 MQTT 連接隨機 topic 上報。MySQL 和 Redis 的監(jiān)控看 CPU 和連接數(shù)。TCP 壓測用 Netty 客戶端并發(fā)連接每個連接定時發(fā)長度固定報文。壓測時注意生產(chǎn)環(huán)境的連接數(shù)限制先測 1000 個并發(fā)再逐步加到 5000看服務端 GC 情況和消息延遲。這里有個血淚經(jīng)驗壓測通過不代表上線穩(wěn)因為模擬器數(shù)據(jù)規(guī)律性太強真實設備的抖動、斷線重連、亂序報文才是真正的考驗。我習慣壓測時隨機丟包、隨機停發(fā)消息逼著系統(tǒng)走一遍重連和超時分支。回到開頭說的問題這套 Java 全棧物聯(lián)網(wǎng)平臺源碼能幫你省掉的是最基礎的協(xié)議棧、組態(tài)畫布和大屏框架但真正適配你的業(yè)務場景協(xié)議插件化、數(shù)據(jù)分表、壓測上線還得自己動手。要是你遇到的是設備報警沒推出來、組態(tài)動畫不絲滑、TCP 報文結構改了一點就解不了包建議先從第 5 章的排查思路入手八成問題都在通道時序和協(xié)議定界上。希望幫到你。本文還有配套的精品資源點擊獲取