簡介一套面向物聯(lián)網(wǎng)開發(fā)者的WEB設(shè)備管理與云監(jiān)控源碼項目適用于智能家居、工業(yè)自動化等場景解決設(shè)備遠(yuǎn)程接入、狀態(tài)監(jiān)測、數(shù)據(jù)管理與可視化的實際問題。壓縮包共1915個文件約27.24MB以PHP后端邏輯、HTML/JS前端頁面、CSS樣式、PNG圖片素材為主同時包含MySQL數(shù)據(jù)庫腳本、配置文件及說明文檔便于本地搭建和二次開發(fā)。已有836人學(xué)習(xí)瀏覽。源碼涵蓋設(shè)備注冊、數(shù)據(jù)上報、API接口、規(guī)則引擎、可視化界面等完整模塊并提供MQTT通信示例與C語言組件開發(fā)者可據(jù)此掌握從設(shè)備接入到前端展示的完整鏈路還可結(jié)合Excel數(shù)據(jù)表格和Markdown筆記理解項目結(jié)構(gòu)適合希望系統(tǒng)學(xué)習(xí)IoT開發(fā)和云監(jiān)控實踐的初中級工程師。1. 項目背景與整體設(shè)計思路1.1 為什么需要一套物聯(lián)網(wǎng)云監(jiān)控平臺我做過不少設(shè)備管理類項目但真正把設(shè)備接入、實時監(jiān)控、遠(yuǎn)程運(yùn)維、告警通知串成一條完整閉環(huán)的還是這套物聯(lián)網(wǎng)云監(jiān)控WEB設(shè)備管理系統(tǒng)。以前很多工廠或集成商的設(shè)備管理方式說句不好聽的靠的就是一張Excel表和老師傅的經(jīng)驗。設(shè)備掛沒掛、數(shù)據(jù)對不對、耗了多少電全憑人工去現(xiàn)場看效率低不說出了問題往往已經(jīng)是幾個小時之后了。這套項目的核心價值就是給傳統(tǒng)設(shè)備裝上物聯(lián)網(wǎng)這雙眼睛。通過傳感器和智能網(wǎng)關(guān)把設(shè)備狀態(tài)、環(huán)境參數(shù)、能耗數(shù)據(jù)實時采集上來再在WEB端用圖表、儀表盤、地圖等形式直觀展示。運(yùn)維人員不用再頻繁跑現(xiàn)場坐在電腦前甚至用手機(jī)瀏覽器就能看到設(shè)備的實時狀態(tài)。平臺內(nèi)置的告警規(guī)則還能在設(shè)備異常時第一時間推送通知把故障響應(yīng)時間從小時級壓縮到分鐘級這背后省下的人力成本和產(chǎn)能損失做過工業(yè)項目的人心里都有數(shù)。1.2 技術(shù)選型背后的真實考量做物聯(lián)網(wǎng)平臺技術(shù)棧的選擇直接決定后續(xù)的開發(fā)效率和運(yùn)維成本。這套源碼的技術(shù)路線比較主流后端采用Java Spring Boot框架前端使用Vue.js Element UI數(shù)據(jù)庫選用MySQL存儲業(yè)務(wù)數(shù)據(jù)消息通信層用的是EMQX或Mosquitto這類MQTT Broker。為什么這么選Spring Boot的生態(tài)成熟集成MyBatis、Redis、定時任務(wù)都非常順手Vue.js配合Element UI做后臺管理界面效率極高畢竟設(shè)備管理頁面的形態(tài)大家都熟悉——表格、表單、彈窗、樹形結(jié)構(gòu)這套組合閉著眼睛都能寫MQTT協(xié)議則是物聯(lián)網(wǎng)場景的事實標(biāo)準(zhǔn)帶寬占用低、QoS機(jī)制可靠非常適合大量設(shè)備的長連接場景。不少同學(xué)會糾結(jié)要不要上微服務(wù)或者直接用Netty自己寫通信層。我的建議是如果不是千萬級設(shè)備接入體量單體應(yīng)用加MQTT Broker的方案完全夠用開發(fā)成本低、排查問題方便后期真到了瓶頸階段再按模塊拆分也不遲。做物聯(lián)網(wǎng)平臺跑通業(yè)務(wù)閉環(huán)永遠(yuǎn)是第一優(yōu)先級過度設(shè)計是新手最容易犯的毛病。2. 系統(tǒng)架構(gòu)與核心模塊拆解2.1 三層架構(gòu)設(shè)備端、平臺端、WEB端整個平臺在大體上分為三層設(shè)備接入層、平臺服務(wù)層、WEB展示層。設(shè)備接入層負(fù)責(zé)各類傳感器、控制器、智能網(wǎng)關(guān)的數(shù)據(jù)采集和指令下發(fā)通過MQTT協(xié)議與平臺保持長連接平臺服務(wù)層是核心大腦負(fù)責(zé)設(shè)備認(rèn)證、數(shù)據(jù)解析、存儲、規(guī)則引擎、告警計算等WEB展示層面向運(yùn)維人員和管理員提供設(shè)備管理、實時監(jiān)控、數(shù)據(jù)報表、系統(tǒng)配置等界面。這三層之間通過HTTP和MQTT兩類協(xié)議交互。HTTP用于前后端業(yè)務(wù)接口比如登錄、設(shè)備增刪改查、歷史數(shù)據(jù)查詢MQTT用于實時數(shù)據(jù)上行和指令下行。為什么要用兩種協(xié)議因為業(yè)務(wù)操作和實時通信的訴求不一樣HTTP請求響應(yīng)模式適合低頻、可控的操作而設(shè)備數(shù)據(jù)是持續(xù)產(chǎn)生、需要主動推送的輪詢HTTP不僅浪費(fèi)帶寬延遲也不可控。這種混合架構(gòu)是當(dāng)前物聯(lián)網(wǎng)平臺的主流做法既保證交互體驗又兼顧實時性能。2.2 數(shù)據(jù)存儲時序數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)分離設(shè)備產(chǎn)生的數(shù)據(jù)有一個顯著特點寫入頻繁、更新極少、帶有時間戳。如果和業(yè)務(wù)數(shù)據(jù)混在一起存隨著時間推移表會變得非常大查詢效率也越來越差。這套項目里的做法是將兩類數(shù)據(jù)分開存儲設(shè)備基本信息、用戶信息、組織架構(gòu)、告警規(guī)則等存在MySQL業(yè)務(wù)庫溫濕度、電壓、電流這類遙測數(shù)據(jù)按天或按月分表也可以選擇存入InfluxDB、TDengine等時序數(shù)據(jù)庫。這里有個設(shè)計細(xì)節(jié)值得拓展一下很多設(shè)備數(shù)據(jù)本身對實時性要求高但對歷史精度要求沒那么苛刻所以在存儲策略上可以做降采樣。比如原始數(shù)據(jù)每5秒一條存3個月后可以聚合為每分鐘一條存1年后再降為每10分鐘一條。這樣既保證近期數(shù)據(jù)的高精度又能控制長期存儲的成本。代碼里通常用一個定時任務(wù)來完成數(shù)據(jù)清理和聚合調(diào)用時序庫的連續(xù)查詢功能就能實現(xiàn)。這套方案對于預(yù)算有限的團(tuán)隊特別實用因為服務(wù)器磁盤沒那么容易被打滿。2.3 平臺的核心能力邊界這套源碼作為中小型物聯(lián)網(wǎng)平臺覆蓋的能力包括設(shè)備管理、實時監(jiān)控、遠(yuǎn)程控制、告警中心、數(shù)據(jù)統(tǒng)計、用戶權(quán)限、操作日志等。設(shè)備管理支持批量導(dǎo)入導(dǎo)出方便初始化或者遷移遠(yuǎn)程控制支持下發(fā)指令并反饋執(zhí)行結(jié)果告警中心支持按設(shè)備分組、按規(guī)則模板批量配置閾值告警數(shù)據(jù)統(tǒng)計提供曲線圖和報表導(dǎo)出用于分析運(yùn)行趨勢。在實際落地中平臺還有幾個隱藏價值點容易被忽略一是操作日志完備誰在什么時間操作了哪臺設(shè)備全程留痕這在工廠審計中很關(guān)鍵二是開放API接口方便與第三方系統(tǒng)如ERP、MES對接三是數(shù)據(jù)看板支持大屏展示會議室墻上的大屏接上這個頁面整個產(chǎn)線狀態(tài)一目了然很適合做成果匯報。這套源碼的邊界和應(yīng)用場景基本覆蓋了中小型項目的絕大多數(shù)需求。3. 設(shè)備接入與上下行數(shù)據(jù)鏈路3.1 MQTT接入流程與設(shè)備認(rèn)證設(shè)備接入的第一步是認(rèn)證。每個設(shè)備在平臺注冊后會生成唯一的設(shè)備標(biāo)識如產(chǎn)品Key和設(shè)備序列號設(shè)備端連接MQTT Broker時使用設(shè)備證書或Token進(jìn)行認(rèn)證。最常用的做法是采用一機(jī)一密的機(jī)制平臺為每一臺設(shè)備生成專屬的ClientId和密碼設(shè)備連接時攜帶這些信息Broker通過認(rèn)證插件校驗合法性非法設(shè)備直接拒絕連接。從實操層面看設(shè)備接入流程可以拆成四步第一步在WEB端添加產(chǎn)品定義產(chǎn)品的數(shù)據(jù)模型包括屬性、事件、服務(wù)三類能力第二步為具體設(shè)備實例填寫序列號等信息獲取連接憑證第三步設(shè)備端使用MQTT客戶端庫如Eclipse Paho、MQTT.fx連接Broker訂閱指令主題第四步設(shè)備上報數(shù)據(jù)后平臺驗證數(shù)據(jù)格式、寫入數(shù)據(jù)庫并更新設(shè)備在線狀態(tài)。這套流程走順了后面接新設(shè)備就是純粹的配置工作不用改代碼。3.2 數(shù)據(jù)上行從JSON到結(jié)構(gòu)化存儲設(shè)備上報的數(shù)據(jù)格式通常有兩種一種是非標(biāo)的JSON字符串另一種是物模型定義的標(biāo)準(zhǔn)數(shù)據(jù)格式。推薦使用物模型的方式因為這樣平臺可以通過JSON Schema校驗數(shù)據(jù)合法性新設(shè)備接入也不用為每種設(shè)備寫一套解析代碼。例如一個溫濕度傳感器上報的JSON內(nèi)容大致為{temperature:25.6,humidity:60.3,deviceId:SN001}平臺收到后先做格式校驗再映射到內(nèi)部數(shù)據(jù)結(jié)構(gòu)最終寫入MySQL或時序數(shù)據(jù)庫。這個過程有幾個坑需要特別注意第一字段名的統(tǒng)一設(shè)備端上報temperature數(shù)據(jù)庫字段也叫temperature代碼里不會出歧義第二數(shù)據(jù)截斷問題浮點數(shù)精度在傳輸過程中可能丟失建議后端用BigDecimal或Decimal類型存儲避免后續(xù)統(tǒng)計對不上第三時間戳規(guī)范化設(shè)備上報的時間可能是本地時間也可能是UTC時間必須統(tǒng)一轉(zhuǎn)換為服務(wù)器時區(qū)的DateTime否則報表的時間線會亂套。這些細(xì)節(jié)看似零碎但直接影響數(shù)據(jù)質(zhì)量而數(shù)據(jù)質(zhì)量就是物聯(lián)網(wǎng)平臺的命根子。3.3 指令下發(fā)同步確認(rèn)還是異步通知遠(yuǎn)程控制是物聯(lián)網(wǎng)平臺的一個重要面。指令下發(fā)的流程是WEB端點擊控制按鈕后端服務(wù)收到請求后將控制指令發(fā)布到該設(shè)備對應(yīng)的MQTT主題設(shè)備端訂閱該主題并執(zhí)行動作執(zhí)行完畢后將結(jié)果上報。這里需要區(qū)分平臺命令送達(dá)和設(shè)備執(zhí)行成功兩個概念前者只表示消息到達(dá)Broker后者需要設(shè)備端回復(fù)確認(rèn)指令。在項目實踐中我習(xí)慣把所有下發(fā)的指令記錄到指令表并維護(hù)一個狀態(tài)字段取值是待下發(fā)、已送達(dá)、執(zhí)行中、成功、失敗、超時。后端下發(fā)消息后通過定時任務(wù)輪詢指令狀態(tài)如果超過設(shè)定閾值仍未收到設(shè)備回復(fù)就自動標(biāo)記超時。這種機(jī)制能讓W(xué)EB端界面向用戶展示準(zhǔn)確的指令執(zhí)行狀態(tài)而不是發(fā)出去就黑盒狀態(tài)排查離線場景下的假死指令非常好用。3.4 設(shè)備在線狀態(tài)與心跳機(jī)制設(shè)備在線狀態(tài)判斷是物聯(lián)網(wǎng)平臺基礎(chǔ)卻容易出問題的一環(huán)。純TCP長連接可以直接通過斷開事件判定掉線但MQTT的心跳包機(jī)制需要單獨處理。設(shè)備端按設(shè)定間隔發(fā)送心跳例如每60秒一次Broker如果在1.5倍的心跳時間內(nèi)沒有收到任何報文就判定連接斷開。平臺側(cè)通過訂閱在線狀態(tài)主題或查詢Broker的客戶端列表來感知這些變化。這里要說明一個實際經(jīng)驗單純依賴Broker連接狀態(tài)還是不夠的因為有些設(shè)備斷電前來不及發(fā)送遺囑消息主機(jī)已經(jīng)掉了Broker雖然能感知但展示層如果做了本地緩存狀態(tài)就會不一致。我建議平臺在設(shè)備狀態(tài)判斷時采用雙保險Broker連接狀態(tài)為主要依據(jù)服務(wù)端再做一層最后活躍時間校驗超過設(shè)定時間強(qiáng)制標(biāo)記為離線。這樣即使在Broker異常或數(shù)據(jù)推送延遲的場景下界面展示的在線狀態(tài)也不會失真太久。4. 云監(jiān)控核心功能實現(xiàn)4.1 實時數(shù)據(jù)大屏與監(jiān)控看板實時監(jiān)控功能是這套平臺的門面。它包含設(shè)備狀態(tài)總覽、實時數(shù)據(jù)儀表盤、地圖分布展示、告警滾動播報等模塊。WEB端通過WebSocket與后端保持長連接當(dāng)設(shè)備上報數(shù)據(jù)后后端服務(wù)將最新的點播數(shù)據(jù)推送到前端前端自動更新表格或圖表達(dá)到秒級看到現(xiàn)場變化的效果。大屏看板的實現(xiàn)需要從設(shè)計上區(qū)分實時數(shù)據(jù)和歷史數(shù)據(jù)兩種數(shù)據(jù)流。實時數(shù)據(jù)走WebSocket即時推送直接用當(dāng)前最新值刷新看板上的儀表盤指針和數(shù)字實時變化歷史趨勢曲線則通過HTTP調(diào)用查詢接口獲取按時間范圍返回聚合后的數(shù)據(jù)點。尤其需要注意的是數(shù)據(jù)頻率的適配如果設(shè)備每5秒上報一次數(shù)據(jù)而看板只需要30秒級別的刷新那就不應(yīng)該讓W(xué)ebSocket每條都推送再重繪圖表中間加一層數(shù)據(jù)緩沖和節(jié)流可以大幅降低前端開銷。這套系統(tǒng)在監(jiān)控大屏場景下的加載速度和流暢度都比我之前用輪詢方案做的第一版不知道強(qiáng)了多少。4.2 告警規(guī)則引擎與通知渠道告警是物聯(lián)網(wǎng)監(jiān)控的核心痛點需求。沒有告警光屏上看到數(shù)據(jù)異常等人工反應(yīng)過來損失已經(jīng)造大了。平臺內(nèi)置了一套規(guī)則引擎支持為每個物理量配置多個告警規(guī)則比如溫度高于80度觸發(fā)緊急告警持續(xù)5分鐘仍然高于75度觸發(fā)高溫預(yù)警。規(guī)則引擎的核心就是對流式數(shù)據(jù)進(jìn)行持續(xù)計算每條新數(shù)據(jù)進(jìn)來都要做閾值判斷同時還要處理持續(xù)時長、恢復(fù)判斷、告警去重等問題。告警消息的觸達(dá)方式也是物聯(lián)網(wǎng)平臺比較看重的一塊。除了在WEB端彈出通知和告警列表之外往往還要支持郵件、短信、企業(yè)微信/釘釘機(jī)器人等渠道。在項目里我實現(xiàn)了一個簡單的策略模式定義一個告警通知接口不同渠道各自實現(xiàn)一個發(fā)送方法告警觸發(fā)時按照規(guī)則配置的路由策略決定發(fā)哪個渠道。短信適合值班人員接收的緊急告警郵件適合常規(guī)日報企業(yè)微信群機(jī)器人適合運(yùn)維協(xié)同。花錢買短信的人都知道渠道收斂很重要不然一分鐘能給你發(fā)一兩百條告警短信誤報和重復(fù)告警能煩死人。4.3 歷史數(shù)據(jù)查詢與報表統(tǒng)計歷史數(shù)據(jù)是設(shè)備優(yōu)化和故障分析的原始依據(jù)。平臺提供兩種查詢方式原始數(shù)據(jù)明細(xì)查詢和聚合統(tǒng)計。明細(xì)查詢用于定位某個時間點的具體數(shù)據(jù)聚合統(tǒng)計用于分析趨勢、均值、峰值等。比如查詢某臺設(shè)備一周內(nèi)的溫度最大值、平均值用于判斷設(shè)備運(yùn)行環(huán)境是否穩(wěn)定。報表模塊可以導(dǎo)出Excel或生成PDF方便運(yùn)維會議匯報。在實現(xiàn)上有幾個效率點值得注意。第一查詢條件必須帶時間范圍索引否則后期數(shù)據(jù)量大了會慢到?jīng)]法用第二聚合統(tǒng)計盡量在數(shù)據(jù)庫層面完成SQL里用GROUP BY配合時間窗口函數(shù)不要把所有數(shù)據(jù)撈到Java內(nèi)存里再聚合第三緩存熱數(shù)據(jù)最近一小時的實時數(shù)據(jù)可以放在Redis里查詢時優(yōu)先走緩存緩存未命中再落庫。這些優(yōu)化做完大數(shù)據(jù)量下的報表打開速度能快一個數(shù)量級用戶體感完全不同。4.4 視頻監(jiān)控與告警聯(lián)動很多物聯(lián)網(wǎng)平臺還有接入攝像頭視頻流的場景。源碼里通過GB28181協(xié)議或RTSP拉流方式接入網(wǎng)絡(luò)攝像頭WEB端通過Flv.js或WebRTC播放實時視頻流。更實用的是告警聯(lián)動功能當(dāng)某個報警觸發(fā)后系統(tǒng)自動調(diào)取關(guān)聯(lián)攝像頭的錄像或截圖保存到告警記錄中方便事后回溯現(xiàn)場。這在養(yǎng)殖場、倉庫、配電房等場景中極其有用光看數(shù)據(jù)很難判斷現(xiàn)場是什么狀況但視頻畫面一看就明白了。不過說實話視頻監(jiān)控模塊在中小型項目里不宜做太深涉及視頻轉(zhuǎn)碼、存儲、回放的話工程量會成倍上漲。建議初期只用云臺控制、實時預(yù)覽、截圖三種基礎(chǔ)能力后續(xù)再按需擴(kuò)展錄像回放、智能識別人員闖入、煙火檢測等功能。畢竟項目核心是云監(jiān)控的云端管理能力視頻是輔助增強(qiáng)不是主菜。5. WEB端設(shè)備管理與權(quán)限設(shè)計5.1 設(shè)備全生命周期管理WEB端的設(shè)備管理模塊要做到從設(shè)備注冊到注銷的全生命周期管理。設(shè)備狀態(tài)分為未激活、在線、離線、禁用、注銷五種。設(shè)備新增后處于未激活狀態(tài)第一次成功上報數(shù)據(jù)后自動激活并上線管理員可以手動禁用某臺設(shè)備禁用后平臺忽略該設(shè)備的采集數(shù)據(jù)和指令請求注銷則是徹底移除設(shè)備并保留歷史記錄供追溯。設(shè)備詳情頁我建議至少包含四個區(qū)塊基本信息產(chǎn)品名稱、序列號、安裝位置、經(jīng)緯度等、運(yùn)行狀態(tài)當(dāng)前在線狀態(tài)、最后在線時間、連接IP、實時數(shù)據(jù)當(dāng)前最新的各屬性值、歷史操作指令下發(fā)記錄、告警記錄。很多運(yùn)維問題都是從這臺設(shè)備最后在線是什么時候這種基礎(chǔ)查詢開始的信息越全排查越省力。設(shè)備導(dǎo)入導(dǎo)出功能也建議在初期就做。工廠一次性接入幾百臺設(shè)備如果手工逐個添加半天時間就耗在這了。Excel模板批量導(dǎo)入 二維碼批量生成是部署階段最高效的手段。設(shè)備安裝時現(xiàn)場人員掃碼就能在手機(jī)上看到設(shè)備信息并綁定工單安裝效率明顯提升。5.2 組織架構(gòu)與多租戶權(quán)限模型企業(yè)使用物聯(lián)網(wǎng)平臺時往往涉及總部和多個分部或車間的組織結(jié)構(gòu)。WEB端需要支持按組織架構(gòu)管理設(shè)備也就是設(shè)備的歸屬不只是一個部門而是層層嵌套的樹形結(jié)構(gòu)。總部管理員能看到所有設(shè)備數(shù)據(jù)車間管理員只能看到自己車間內(nèi)的設(shè)備。這種基于RBAC模型的權(quán)限管理比較簡單用戶、角色、權(quán)限點、數(shù)據(jù)范圍四個維度就夠了。數(shù)據(jù)權(quán)限的控制是很多項目容易做糙的地方。簡單粗暴的做法是查詢時只做名稱過濾但真正的數(shù)據(jù)權(quán)限需要在SQL層面按組織ID進(jìn)行攔截?？蚣苌峡梢酝ㄟ^MyBatis的攔截器自動拼接數(shù)據(jù)權(quán)限條件凡是查詢設(shè)備、數(shù)據(jù)、告警等核心表的地方都自動帶上當(dāng)前用戶的可視范圍條件。這樣即使開發(fā)人員中途忘了寫權(quán)限判斷也不會出現(xiàn)越權(quán)訪問的低級漏洞。5.3 前端交互與性能體驗WEB管理端畢竟是給管理員天天用的交互體驗直接決定平臺被接受的程度。項目使用Vue.js Element UI表格支持分頁、排序、列顯隱、批量選擇操作頁面操作步驟盡量控制在2跳以內(nèi)。設(shè)備列表和實時監(jiān)控頁在數(shù)據(jù)量大時要有分頁和懶加載機(jī)制否則每3秒鐘WebSocket推一次數(shù)據(jù)前端頁面卡成幻燈片那就沒法用了。我實際測試下來前端在這幾個點上下對功夫體驗提升最明顯一是表格的虛擬滾動渲染幾千行不卡二是圖表的動畫開關(guān)實時數(shù)據(jù)刷新時關(guān)閉動畫流暢很多三是全局異常提示和加載狀態(tài)的一致性避免用戶重復(fù)點擊提交。整體的前端架構(gòu)建議采用Vuex存儲用戶信息、權(quán)限點、設(shè)備樹緩存避免每次切換頁面都要重新拉取設(shè)備列表。6. 部署上線與常見問題排查6.1 Docker Compose一鍵編排部署部署這套平臺推薦使用Docker Compose。數(shù)據(jù)庫、Redis、MQTT Broker、后端服務(wù)、前端Nginx五個容器通過一個compose文件編排起來非常省心。特別是現(xiàn)場實施的時候目標(biāo)機(jī)器上環(huán)境可能千奇百怪Docker可以把服務(wù)和依賴打包在一起部署一臺新服務(wù)器大概就是十分鐘的事情。部署時要注意幾個配置項MySQL的volume掛載路徑要持久化不然容器重建數(shù)據(jù)就丟了EMQX要開放18083端口用于Dashboard管理1883端口用于設(shè)備連接Nginx配置HTTP長連接和WebSocket升級頭否則前端實時推送連不上。生產(chǎn)環(huán)境務(wù)必開啟防火墻只放行必要端口設(shè)備接入端口、Web端口、SSH端口三個就好其他端口全關(guān)。6.2 后端服務(wù)層面常見問題與優(yōu)化在實際運(yùn)行中后端服務(wù)最常碰到的問題基本集中在三塊數(shù)據(jù)庫連接池耗盡、Netty線程阻塞、內(nèi)存溢出。連接池耗盡多半是因為慢SQL太多排查可以打開MySQL的慢查詢?nèi)罩景褕?zhí)行時間超過1秒的SQL抓出來做索引優(yōu)化線程阻塞常見于設(shè)備大量涌入時的任務(wù)隊列擠壓建議拆分線程池設(shè)備消息處理和數(shù)據(jù)落庫分開內(nèi)存溢出則需要調(diào)整JVM參數(shù)同時關(guān)注是否有集合類沒有清理導(dǎo)致對象無法回收。還有一個容易忽略的服務(wù)端優(yōu)化點是消息并發(fā)處理。全量設(shè)備長時間在線、數(shù)據(jù)流量大時單機(jī)處理能力會到瓶頸。如果單機(jī)資源還不夠必然要上集群。這一步建議后置先把單機(jī)壓到極致再做集群擴(kuò)展避免在項目初期就背上一堆分布式復(fù)雜度。6.3 設(shè)備端接入的典型異常排查這里整理了一張設(shè)備接入時的排查速查表我在多個現(xiàn)場項目實施中用過可以減少大量溝通成本現(xiàn)象可能原因快速排查思路設(shè)備連不上MQTT認(rèn)證失敗核對ClientId和密碼檢查是否一機(jī)一密機(jī)制設(shè)備連上了但數(shù)據(jù)沒入庫主題訂閱錯誤檢查設(shè)備發(fā)布主題與平臺訂閱主題是否匹配數(shù)據(jù)入庫但沒有顯示物模型字段映射錯誤檢查數(shù)據(jù)庫字段名與上報JSON字段名是否一致設(shè)備狀態(tài)一直離線心跳間隔配置過大查看平臺日志中的最后活躍時間調(diào)整心跳策略指令下發(fā)設(shè)備無響應(yīng)設(shè)備處于透傳模式確認(rèn)設(shè)備是否訂閱了指令主題查看指令狀態(tài)機(jī)每次在現(xiàn)場排查問題我第一步永遠(yuǎn)是看設(shè)備端日志和平臺端日志的時間戳對齊沒有。設(shè)備上報時間、平臺接收時間、入庫時間三個時間一對比鏈路瓶頸在哪個環(huán)節(jié)基本就清楚了。6.4 實戰(zhàn)心得從源碼部署到二次開發(fā)拿到這套源碼之后我建議先不急著改代碼按以下步驟走一遍第一步部署起基礎(chǔ)環(huán)境跑通設(shè)備模擬器上報數(shù)據(jù) - WEB端看到實時數(shù)據(jù) - 修改設(shè)備閾值觸發(fā)告警這條主鏈路第二步仔細(xì)閱讀數(shù)據(jù)庫設(shè)計文檔和核心代碼重點理解數(shù)據(jù)表之間的關(guān)系第三步針對自己的業(yè)務(wù)場景做二次開發(fā)優(yōu)先從增加一種產(chǎn)品類型這種小需求入手逐步熟悉代碼風(fēng)格第四步再進(jìn)行頁面定制化改造。二次開發(fā)時注意保持原有分層結(jié)構(gòu)不要在Controller里寫復(fù)雜業(yè)務(wù)邏輯所有數(shù)據(jù)處理都放到Service層。自定義告警規(guī)則時盡量復(fù)用原來的規(guī)則引擎接口而不是在原有代碼里加特定判斷邏輯。這樣后續(xù)升級官方源碼時改動沖突會小很多。還有一點就是在改數(shù)據(jù)庫表字段時及時同步更新前后端的數(shù)據(jù)模型代碼報錯說找不到字段的問題在二次開發(fā)階段我?guī)缀趺看味紩龅健?. 寫在最后一次完整的物聯(lián)網(wǎng)閉環(huán)實踐做這套物聯(lián)網(wǎng)云監(jiān)控平臺帶給我最大的體會是物聯(lián)網(wǎng)系統(tǒng)真正的復(fù)雜度不在通信協(xié)議也不在某個炫酷的前端圖表而是把設(shè)備接入、數(shù)據(jù)流轉(zhuǎn)、告警處理、業(yè)務(wù)展示這條鏈路完整地串起來每一環(huán)都可靠運(yùn)轉(zhuǎn)。設(shè)備端斷線重連、平臺側(cè)數(shù)據(jù)清洗、WEB端信息展示任何一個環(huán)節(jié)出紕漏整套系統(tǒng)的可信度就會打折扣。在實際落地過程中我還有一個很深的經(jīng)驗項目驗收階段展示給客戶看的永遠(yuǎn)不是代碼寫得多漂亮而是業(yè)務(wù)的完整閉環(huán)。從設(shè)備添加開始到數(shù)據(jù)上傳到異常告警到遠(yuǎn)程控制再到報表導(dǎo)出每一步都能走得通、看得見、解釋得清這個項目就成功了九成。這套源碼的價值正在于它把上述細(xì)節(jié)都做了相對規(guī)范的實現(xiàn)給二次開發(fā)提供了一套可以起步的骨架。最后再分享一下個人部署體驗如果條件允許建議在同一臺性能還行的服務(wù)器上完整部署一遍用MQTT.fx模擬10臺設(shè)備做壓力測試觀察CPU和內(nèi)存指標(biāo)調(diào)整數(shù)據(jù)庫連接數(shù)和JVM參數(shù)。這個過程走完你對這套系統(tǒng)的理解深度比單純看源碼要扎實得多。做物聯(lián)網(wǎng)這行動手永遠(yuǎn)是學(xué)習(xí)效率最高的方式。本文還有配套的精品資源點擊獲取