1. 先弄清楚這件“第二種方式”要解決什么問(wèn)題干工業(yè)數(shù)據(jù)對(duì)接這幾年我越來(lái)越覺(jué)得把數(shù)據(jù)從現(xiàn)場(chǎng)設(shè)備里采上來(lái)不算本事真正麻煩的是怎么把數(shù)據(jù)干凈利落地交到別人手里。前陣子接了個(gè)水質(zhì)監(jiān)測(cè)項(xiàng)目客戶點(diǎn)名要用繁易平臺(tái)現(xiàn)場(chǎng)監(jiān)測(cè)點(diǎn)分布在廠區(qū)四個(gè)位置pH、濁度、溶解氧、流量這些點(diǎn)位都得實(shí)時(shí)上送。最初方案全是按MQTT寫的設(shè)備側(cè)配置、報(bào)文結(jié)構(gòu)、訂閱鏈路都定了結(jié)果對(duì)接方綜合管理平臺(tái)只給了一個(gè)HTTP推送接口消息隊(duì)列一概不通。方案當(dāng)場(chǎng)就得改——繁易平臺(tái)對(duì)接監(jiān)測(cè)點(diǎn)數(shù)據(jù)除了MQTT還得走第二種方式也就是HTTP主動(dòng)上報(bào)。這篇把這次實(shí)踐從選型到落地的完整過(guò)程寫出來(lái)適合正在用繁易平臺(tái)接數(shù)、或者準(zhǔn)備接數(shù)但下游系統(tǒng)不支持MQTT的朋友。內(nèi)容覆蓋方案對(duì)比、網(wǎng)關(guān)配置、服務(wù)端接收接口設(shè)計(jì)還有我實(shí)際踩過(guò)的一些坑。讀完后你至少能回答三個(gè)問(wèn)題第二種方式到底怎么搭、報(bào)文該長(zhǎng)什么樣、壞了怎么查。我盡量按項(xiàng)目推進(jìn)的順序講而不是堆名詞。1.1 監(jiān)測(cè)點(diǎn)數(shù)據(jù)對(duì)接的經(jīng)典鏈路先對(duì)齊一下術(shù)語(yǔ)。這里說(shuō)的“監(jiān)測(cè)點(diǎn)”不單指某個(gè)傳感器而是指一個(gè)可以產(chǎn)出數(shù)值的數(shù)據(jù)采集位置。比如某個(gè)水泵的壓力變送器、某個(gè)水池旁的液位計(jì)、一套水質(zhì)多參數(shù)儀表甚至一個(gè)電表回路都可以算一個(gè)監(jiān)測(cè)點(diǎn)。繁易平臺(tái)要“直接對(duì)接監(jiān)測(cè)點(diǎn)數(shù)據(jù)”核心鏈路其實(shí)分成三段第一段是采集由繁易網(wǎng)關(guān)通過(guò)串口、網(wǎng)口或者模擬量通道把現(xiàn)場(chǎng)設(shè)備里的寄存器值、模擬量信號(hào)讀上來(lái)。第二段是處理網(wǎng)關(guān)內(nèi)部把原始數(shù)值按點(diǎn)位映射關(guān)系轉(zhuǎn)化成標(biāo)準(zhǔn)工程值比如把16位整型碼值換算成實(shí)際的pH數(shù)值加上時(shí)間戳和點(diǎn)位號(hào)。第三段是上行把處理好的數(shù)據(jù)封裝成消息通過(guò)某種協(xié)議投遞到目標(biāo)平臺(tái)。監(jiān)控大屏、數(shù)據(jù)大屏、報(bào)表系統(tǒng)全部依賴這最后一跳。大多數(shù)人第一次接觸繁易對(duì)接方案第一反應(yīng)就是MQTT。為什么因?yàn)镸QTT在工業(yè)領(lǐng)域確實(shí)普及輕量、實(shí)時(shí)性好、斷線自動(dòng)重連幾乎成了設(shè)備上云的事實(shí)標(biāo)準(zhǔn)。繁易網(wǎng)關(guān)對(duì)MQTT的支持也很成熟配置里填一下Broker地址、訂閱主題、QoS級(jí)別數(shù)據(jù)就源源不斷發(fā)出去。這個(gè)方案本身沒(méi)毛病但有一個(gè)隱藏前提你的數(shù)據(jù)接收方必須能跑MQTT客戶端而且網(wǎng)絡(luò)環(huán)境允許1883端口出站。現(xiàn)實(shí)里這個(gè)前提經(jīng)常不成立。很多環(huán)保、水務(wù)、園區(qū)綜合平臺(tái)的對(duì)外接口只有HTTP有些甚至只提供一個(gè)帶鑒權(quán)的POST地址。還有些內(nèi)網(wǎng)環(huán)境把非標(biāo)準(zhǔn)端口封得死死的MQTT根本出不去。這時(shí)候第二種方式的價(jià)值就體現(xiàn)出來(lái)了——不依賴消息中間件直接用HTTP請(qǐng)求把數(shù)據(jù)報(bào)到處。1.2 為什么好多項(xiàng)目被MQTT卡脖子MQTT被卡脖子通常不是技術(shù)問(wèn)題而是對(duì)接協(xié)調(diào)問(wèn)題。比如某次對(duì)接對(duì)方技術(shù)負(fù)責(zé)人說(shuō)得很明白我們系統(tǒng)只支持HTTP所有外部數(shù)據(jù)都走統(tǒng)一API網(wǎng)關(guān)已經(jīng)建好的鑒權(quán)體系就是OAuth2那套不可能為了一路監(jiān)測(cè)數(shù)據(jù)專門部署B(yǎng)roker。這種場(chǎng)景你做多少技術(shù)論證都沒(méi)用接入規(guī)范是對(duì)方定的。另一類情況是網(wǎng)絡(luò)鏈路問(wèn)題。MQTT默認(rèn)走1883端口很多專網(wǎng)環(huán)境或者政企內(nèi)網(wǎng)策略嚴(yán)格非443端口根本不通。對(duì)比之下HTTPS走443是任何防火墻都不會(huì)輕易攔的路徑。你甚至不用額外申請(qǐng)白名單只要對(duì)方提供一個(gè)公網(wǎng)或?qū)＞W(wǎng)可達(dá)的HTTPS接口數(shù)據(jù)就能送達(dá)。還有一類情況是開(kāi)發(fā)資源問(wèn)題。接收端如果是自建Web系統(tǒng)維護(hù)一個(gè)MQTT訂閱服務(wù)對(duì)團(tuán)隊(duì)來(lái)說(shuō)就是長(zhǎng)期負(fù)擔(dān)。連接狀態(tài)監(jiān)聽(tīng)、掉線告警、消息積壓、持久化這些事情做起來(lái)都不輕松。但HTTP接口就簡(jiǎn)單多了——一個(gè)Controller一個(gè)函數(shù)收到JSON解析入庫(kù)調(diào)完即走。對(duì)非物聯(lián)網(wǎng)專業(yè)團(tuán)隊(duì)來(lái)說(shuō)第二種方式的學(xué)習(xí)和維護(hù)成本低得多。理解了這個(gè)背景就能明白標(biāo)題里那句“除MQTT方式外第二種方式”的真實(shí)含義它不是MQTT的替代品而是當(dāng)MQTT不可用或不合適時(shí)一種更貼近Web生態(tài)的對(duì)接通道。接下來(lái)我詳細(xì)拆解這種方式怎么落地。2. 方案拆解繁易平臺(tái)第二種對(duì)接方式怎么做先說(shuō)結(jié)論繁易平臺(tái)上除MQTT外最常用的第二種方式就是把監(jiān)測(cè)點(diǎn)數(shù)據(jù)封裝成JSON報(bào)文通過(guò)HTTP協(xié)議主動(dòng)POST到指定服務(wù)器。整個(gè)方案分兩半網(wǎng)關(guān)負(fù)責(zé)采集和上行服務(wù)端負(fù)責(zé)接收和入庫(kù)。我先講整體設(shè)計(jì)思路再講為什么這樣取舍。2.1 第二種方式的核心邏輯HTTP主動(dòng)上報(bào)這名字聽(tīng)起來(lái)很直白但在工業(yè)對(duì)接里它和普通網(wǎng)頁(yè)前端發(fā)個(gè)Ajax請(qǐng)求完全是兩碼事。工業(yè)場(chǎng)景的HTTP上報(bào)有幾個(gè)固定特征讓你必須認(rèn)真對(duì)待。第一數(shù)據(jù)是主動(dòng)推送不是被動(dòng)拉取。網(wǎng)關(guān)按照設(shè)定周期比如每分鐘一次主動(dòng)把當(dāng)前所有點(diǎn)位的最新值組裝成報(bào)文POST到服務(wù)器。服務(wù)器不需要管網(wǎng)關(guān)在哪也不需要主動(dòng)連接現(xiàn)場(chǎng)設(shè)備它只負(fù)責(zé)被動(dòng)收。這種模式的好處是穿透性好網(wǎng)關(guān)只要能訪問(wèn)到目標(biāo)URL就能上報(bào)服務(wù)器甚至可以在云上不需要公網(wǎng)IP回連現(xiàn)場(chǎng)。第二報(bào)文內(nèi)容是結(jié)構(gòu)化、自描述的。因?yàn)閷?duì)接方系統(tǒng)很可能會(huì)把這份JSON直接消費(fèi)入庫(kù)字段命名、類型、時(shí)間格式都必須在對(duì)接文檔里寫死。你不要想當(dāng)然地只發(fā)一個(gè)數(shù)值過(guò)去點(diǎn)位標(biāo)識(shí)、采集時(shí)間、數(shù)據(jù)質(zhì)量碼這些元信息一個(gè)都不能少。否則下游系統(tǒng)無(wú)法區(qū)分這個(gè)值是哪個(gè)監(jiān)測(cè)點(diǎn)的也無(wú)法判斷數(shù)據(jù)可信度。第三上報(bào)是冪等可重試的。網(wǎng)絡(luò)抖動(dòng)、服務(wù)器重啟、接口超時(shí)這些在工業(yè)現(xiàn)場(chǎng)都是家常便飯。網(wǎng)關(guān)一側(cè)要具備失敗緩存和重試機(jī)制服務(wù)器一側(cè)最好能按設(shè)備ID加時(shí)間戳去重保證一條數(shù)據(jù)即便被重復(fù)投遞也不會(huì)重復(fù)計(jì)算或者重復(fù)入庫(kù)。這兩端設(shè)計(jì)思路我會(huì)在第四章專門展開(kāi)。2.2 網(wǎng)關(guān)側(cè)采集與上行的職責(zé)分工很多第一次接觸繁易的人有個(gè)誤區(qū)以為“平臺(tái)對(duì)接監(jiān)測(cè)點(diǎn)”就是把云端平臺(tái)的API地址配置一下就行現(xiàn)場(chǎng)采集自然就通了。實(shí)際完全不是這樣。監(jiān)測(cè)點(diǎn)在車間里、在管廊下、在水池邊數(shù)據(jù)是物理世界里的電信號(hào)必須有一層硬件把它數(shù)字化。繁易網(wǎng)關(guān)就是這層硬件。所以完整方案里網(wǎng)關(guān)承擔(dān)兩個(gè)職責(zé)。采集職責(zé)通過(guò)Modbus RTU、Modbus TCP、DL/T 645、模擬量通道等協(xié)議從傳感器或儀表讀取原始數(shù)據(jù)。這里有一個(gè)關(guān)鍵動(dòng)作叫點(diǎn)位映射比如Modbus寄存器地址40001對(duì)應(yīng)“進(jìn)水pH”40002對(duì)應(yīng)“進(jìn)水濁度”數(shù)據(jù)類型是16位無(wú)符號(hào)整數(shù)縮放系數(shù)是0.01。網(wǎng)關(guān)完成后原始數(shù)值就變成了帶工程單位的真實(shí)值。上行職責(zé)把采集到的最新值組合成標(biāo)準(zhǔn)報(bào)文推送到目標(biāo)服務(wù)器。繁易網(wǎng)關(guān)的上行通道配置里除了MQTT一般都有HTTP相關(guān)選項(xiàng)。你需要指定目標(biāo)URL、請(qǐng)求方式通常是POST、Content-Type統(tǒng)一application/json、超時(shí)時(shí)間和失敗重試次數(shù)。高版本的網(wǎng)關(guān)固件還支持自定義Header字段方便帶Token或API Key鑒權(quán)。這里要特別強(qiáng)調(diào)一個(gè)邊界問(wèn)題網(wǎng)關(guān)負(fù)責(zé)的是“把數(shù)據(jù)送出去”至于數(shù)據(jù)到服務(wù)器之后怎么解析、怎么存儲(chǔ)、怎么上圖那是接收端的事。不要指望一臺(tái)幾百塊或幾千塊的計(jì)算設(shè)備去替你完成數(shù)據(jù)清洗和業(yè)務(wù)邏輯。保持邊界簡(jiǎn)單清晰系統(tǒng)才穩(wěn)定。2.3 方案對(duì)比HTTP上報(bào)和MQTT到底差在哪把兩種方式放在一張表里看選型邏輯就清楚了。對(duì)比項(xiàng)MQTT方式HTTP上報(bào)方式協(xié)議特性長(zhǎng)連接、雙向?qū)崟r(shí)短連接、請(qǐng)求-響應(yīng)端口要求通常1883特殊環(huán)境受限通常80/443穿透性好接收端復(fù)雜度需要維護(hù)訂閱客戶端普通接口即可網(wǎng)絡(luò)中斷表現(xiàn)自動(dòng)重連、離線消息需Broker配合靠本地緩存和重試機(jī)制實(shí)時(shí)性極高適合毫秒級(jí)取決于上報(bào)周期分鐘級(jí)也常見(jiàn)生態(tài)對(duì)接難度需要MQTT客戶端與Web系統(tǒng)天然親和調(diào)試手段需MQTT客戶端工具curl、Postman即可模擬從這張表能看出HTTP上報(bào)犧牲了一定的實(shí)時(shí)性但換來(lái)了極大的對(duì)接便利性。在監(jiān)測(cè)場(chǎng)景里點(diǎn)位數(shù)據(jù)大多數(shù)是秒級(jí)或分鐘級(jí)變化用60秒甚至300秒的上報(bào)周期都?jí)蛴脤?shí)時(shí)性損失完全可接受。于是這個(gè)方案的核心技術(shù)要點(diǎn)就變成了三件事報(bào)文結(jié)構(gòu)怎么定、網(wǎng)關(guān)怎么配、服務(wù)端怎么寫。下面一一細(xì)講。3. 實(shí)操?gòu)牧闩渫℉TTP上報(bào)通道這一章我按現(xiàn)場(chǎng)實(shí)施的順序來(lái)寫你照著做可以少走彎路。我用的網(wǎng)關(guān)以繁易常見(jiàn)型號(hào)為例不同固件版本菜單名稱可能略有差異但邏輯一致。3.1 上游采集先確認(rèn)監(jiān)測(cè)點(diǎn)能讀到數(shù)別急著配HTTP。無(wú)論上行用什么協(xié)議先保證數(shù)據(jù)能從傳感器讀到網(wǎng)關(guān)。我一般按三步確認(rèn)。第一步確認(rèn)設(shè)備物理鏈路。比如Modbus RTU設(shè)備必須確認(rèn)串口參數(shù)波特率常見(jiàn)9600或19200、數(shù)據(jù)位8、校驗(yàn)位無(wú)校驗(yàn)或偶校驗(yàn)看設(shè)備手冊(cè)、停止位1。串口接錯(cuò)后面全白搭。繁易網(wǎng)關(guān)的采集界面里新建一個(gè)設(shè)備通道把從站地址、功能碼通常03讀保持寄存器、寄存器起始地址、寄存器數(shù)量填進(jìn)去系統(tǒng)會(huì)嘗試讀取。第二步建立點(diǎn)位映射。在網(wǎng)關(guān)里給這臺(tái)設(shè)備添加變量每個(gè)變量對(duì)應(yīng)一個(gè)監(jiān)測(cè)點(diǎn)。要填清楚寄存器地址、數(shù)據(jù)類型16位/32位、整型/浮點(diǎn)、字節(jié)序大端/小端、縮放系數(shù)和偏移量。比如某些水位計(jì)以0.1米為單位讀數(shù)100代表10.0米那縮放系數(shù)就是0.1偏移量為0。第三步在線調(diào)試。大多數(shù)繁易網(wǎng)關(guān)的配置軟件支持模擬運(yùn)行或在線調(diào)試模式你可以直接看到某個(gè)點(diǎn)位當(dāng)前讀到的原始值和換算后的工程值。如果這里讀不到數(shù)據(jù)或讀數(shù)明顯異常先別碰HTTP回頭查物理連接和點(diǎn)位配置。我見(jiàn)過(guò)不少項(xiàng)目花了一個(gè)星期排查HTTP不上報(bào)最后發(fā)現(xiàn)是Modbus寄存器地址填錯(cuò)數(shù)據(jù)壓根沒(méi)采上來(lái)。注意地理位置上采集不到和上行推不出去是兩個(gè)完全不同的問(wèn)題。排查時(shí)必須先分清楚是采集段還是推送段出了問(wèn)題否則會(huì)浪費(fèi)大量時(shí)間。3.2 下行配置在網(wǎng)關(guān)里加一條HTTP上行通道采集段確認(rèn)無(wú)誤后開(kāi)始配置上行通道。繁易平臺(tái)上配置HTTP上報(bào)一般涉及下面幾個(gè)關(guān)鍵項(xiàng)。請(qǐng)求地址。填對(duì)方提供的完整URL注意區(qū)分http和https帶不帶路徑。如果對(duì)方要求帶端口也要一并寫全。曾遇到過(guò)接口地址里包含大寫的API路徑網(wǎng)關(guān)配置里我下意識(shí)改成了小寫結(jié)果直接404這種低級(jí)錯(cuò)誤值得警惕。請(qǐng)求方式。無(wú)特殊說(shuō)明都用POST。如果對(duì)方接口定義了GET之類的特殊要求那基本可以判斷對(duì)方對(duì)接經(jīng)驗(yàn)不足你需要主動(dòng)提醒對(duì)方監(jiān)測(cè)數(shù)據(jù)推送場(chǎng)景應(yīng)該用POST攜帶請(qǐng)求體而不是把一堆點(diǎn)位數(shù)據(jù)塞進(jìn)URL參數(shù)里。請(qǐng)求頭。Content-Type固定為application/json; charsetUTF-8。如果對(duì)方有鑒權(quán)要求通常會(huì)給一個(gè)AccessToken或者要求固定Header字段比如Authorization或者X-Api-Key。繁易網(wǎng)關(guān)的HTTP通道配置里一般支持自定義若干Header字段把這些靜態(tài)Token填進(jìn)去即可。動(dòng)態(tài)Token沿用場(chǎng)景網(wǎng)關(guān)支持腳本字段計(jì)算的話可以做但會(huì)增加復(fù)雜度我建議能靜態(tài)就靜態(tài)。上報(bào)周期。根據(jù)監(jiān)測(cè)需求和服務(wù)器承受能力均衡設(shè)置。環(huán)境監(jiān)測(cè)沒(méi)特殊要求時(shí)60秒一輪很合適既保證了數(shù)據(jù)密度又不至于給服務(wù)器造成太大壓力。有些平臺(tái)要求300秒一個(gè)點(diǎn)也照配就是了。失敗重試。建議打開(kāi)失敗緩存設(shè)置重試間隔。網(wǎng)關(guān)本地會(huì)暫存發(fā)送失敗的數(shù)據(jù)待網(wǎng)絡(luò)恢復(fù)后按時(shí)間順序補(bǔ)傳。這個(gè)功能極其重要現(xiàn)場(chǎng)網(wǎng)絡(luò)閃斷幾十分鐘數(shù)據(jù)不會(huì)丟全靠它。注意不要為了圖省事關(guān)掉失敗緩存。這是第二種方式相對(duì)于MQTT最容易被詬病的地方——短連接場(chǎng)景一旦斷網(wǎng)就等于丟數(shù)。開(kāi)啟本地緩存后這個(gè)弱點(diǎn)基本被彌補(bǔ)了。3.3 報(bào)文設(shè)計(jì)JSON怎么組織才不返工報(bào)文格式是這里頭的靈魂。格式?jīng)]定好服務(wù)端解析要返工下游系統(tǒng)對(duì)接更麻煩。我建議按“設(shè)備批次點(diǎn)位數(shù)組”的結(jié)構(gòu)來(lái)組織這也是工業(yè)數(shù)據(jù)接入最常見(jiàn)的范式。{ deviceId: FE-TEST-0001, timestamp: 1713000000, dataPoints: [ { pointId: PH_INLET, pointName: 進(jìn)水pH, value: 7.35, quality: 0, timestamp: 1713000060 }, { pointId: TURB_INLET, pointName: 進(jìn)水濁度, value: 12.6, quality: 0, timestamp: 1713000060 } ] }逐一說(shuō)明關(guān)鍵字段deviceId設(shè)備ID。對(duì)接方用來(lái)識(shí)別數(shù)據(jù)來(lái)源必須全局唯一且固定不變。建議用網(wǎng)關(guān)SN或者對(duì)接文檔里分配的編號(hào)。timestamp報(bào)文生成時(shí)間。我建議統(tǒng)一用Unix時(shí)間戳單位秒避免“2025-04-14 10:00:00”這種帶時(shí)區(qū)歧義和格式歧義的字符串。如果對(duì)方系統(tǒng)已經(jīng)定了字符串格式那就按對(duì)方的來(lái)但溝通時(shí)最好提一句時(shí)區(qū)問(wèn)題避免服務(wù)器和現(xiàn)場(chǎng)時(shí)區(qū)不一致導(dǎo)致時(shí)間漂移。dataPoints點(diǎn)位數(shù)組。數(shù)組內(nèi)每個(gè)元素代表一個(gè)監(jiān)測(cè)點(diǎn)。pointId是點(diǎn)位標(biāo)識(shí)的字符串value是工程值quality是質(zhì)量碼。質(zhì)量碼0表示正常1表示超限2表示故障3表示無(wú)效。這一項(xiàng)常常被忽視但很重要——現(xiàn)場(chǎng)儀表維護(hù)時(shí)輸出無(wú)效數(shù)據(jù)質(zhì)量碼能直接告訴下游“這條數(shù)據(jù)別用于統(tǒng)計(jì)”。關(guān)于要不要在每一跳里都重復(fù)帶timestamp我的做法是報(bào)文級(jí)timestamp表示“這一批數(shù)據(jù)是什么時(shí)候組包的”點(diǎn)位級(jí)timestamp表示“這個(gè)點(diǎn)是什么時(shí)候采集到的”。若網(wǎng)關(guān)的采集和上報(bào)之間沒(méi)有明顯延遲點(diǎn)位級(jí)時(shí)間戳大多相同。但網(wǎng)絡(luò)異常后補(bǔ)傳時(shí)兩者差異會(huì)很大。下游看到點(diǎn)位時(shí)間戳是兩小時(shí)前就知道這是補(bǔ)傳數(shù)據(jù)處理邏輯上可以做區(qū)分。這個(gè)細(xì)節(jié)在多級(jí)轉(zhuǎn)發(fā)場(chǎng)景里尤其重要。4. 服務(wù)端對(duì)接與關(guān)鍵實(shí)現(xiàn)網(wǎng)關(guān)配好了報(bào)文格式也定了接下來(lái)是服務(wù)端。大多數(shù)對(duì)接方系統(tǒng)不會(huì)是全新的但接收監(jiān)測(cè)數(shù)據(jù)這部分往往就是在一套已有的業(yè)務(wù)系統(tǒng)里加一個(gè)接口。這里我給出一個(gè)最小可用的接收服務(wù)示例以及我認(rèn)為必須做對(duì)的三個(gè)關(guān)鍵點(diǎn)。4.1 用Python快速搭一個(gè)接收接口假設(shè)目標(biāo)是接收J(rèn)SON報(bào)文校驗(yàn)后寫入數(shù)據(jù)庫(kù)。用Flask簡(jiǎn)單實(shí)現(xiàn)。from flask import Flask, request, jsonify import json import time app Flask(__name__) # 模擬白名單設(shè)備 DEVICE_WHITELIST {FE-TEST-0001, FE-TEST-0002} app.route(/api/monitor/push, methods[POST]) def receive_push(): # 基本條件判斷 if not request.is_json: return jsonify({code: 400, msg: Content-Type must be application/json}), 400 body request.get_json() device_id body.get(deviceId) if device_id not in DEVICE_WHITELIST: return jsonify({code: 401, msg: device not allowed}), 401 incoming_ts body.get(timestamp, 0) current_ts int(time.time()) if abs(current_ts - incoming_ts) 300: return jsonify({code: 400, msg: timestamp out of range}), 400 points body.get(dataPoints, []) if not points: return jsonify({code: 400, msg: empty dataPoints}), 400 # 到此視為校驗(yàn)通過(guò)進(jìn)入實(shí)際業(yè)務(wù)處理 process_points(device_id, incoming_ts, points) return jsonify({code: 0, msg: ok}) def process_points(device_id, ts, points): for point in points: # 實(shí)際項(xiàng)目中這里執(zhí)行數(shù)據(jù)庫(kù)插入操作 save_to_db(device_id, point[pointId], point[value], point[quality], point.get(timestamp, ts)) def save_to_db(device_id, point_id, value, quality, p_ts): # 演示用替換為真實(shí)數(shù)據(jù)庫(kù)寫入邏輯 print(f{device_id} {point_id} {value} qual{quality} ts{p_ts})這段代碼做了四件事限制請(qǐng)求類型、校驗(yàn)設(shè)備ID白名單、校驗(yàn)時(shí)間戳新鮮度、校驗(yàn)點(diǎn)位非空。這些只是最基礎(chǔ)的防護(hù)但已經(jīng)能擋掉大半異常請(qǐng)求。生產(chǎn)環(huán)境建議再補(bǔ)一層鑒權(quán)比如校驗(yàn)Header中的Token是否有效。提示不要把業(yè)務(wù)處理放在接收接口里阻塞執(zhí)行。對(duì)接場(chǎng)景中網(wǎng)關(guān)重試邏輯很常見(jiàn)如果接口處理超過(guò)幾秒網(wǎng)關(guān)可能因超時(shí)重復(fù)投遞反而加重服務(wù)器負(fù)擔(dān)。接收到合法數(shù)據(jù)后先返回成功再異步落庫(kù)這種模式更穩(wěn)。4.2 數(shù)據(jù)校驗(yàn)、去重與斷點(diǎn)補(bǔ)傳服務(wù)端真正容易出問(wèn)題的不是接口框架而是數(shù)據(jù)鏈路的一致性。我重點(diǎn)說(shuō)三個(gè)容易被忽略的設(shè)計(jì)。按設(shè)備ID加點(diǎn)位ID加采集時(shí)間戳去重。網(wǎng)關(guān)緩存補(bǔ)傳機(jī)制打開(kāi)后可能出現(xiàn)同一批數(shù)據(jù)投遞兩次的情況比如第一次請(qǐng)求超時(shí)了實(shí)際對(duì)方已收到網(wǎng)關(guān)重試又成功投遞了一次。如果不去重?cái)?shù)據(jù)庫(kù)里就會(huì)多出重復(fù)記錄。在表結(jié)構(gòu)上給deviceId、pointId、timestamp三列建唯一索引插入時(shí)用INSERT IGNORE或者ON DUPLICATE KEY UPDATE這個(gè)問(wèn)題就解決了。時(shí)間戳統(tǒng)一成UTC存儲(chǔ)。我見(jiàn)過(guò)最頭疼的對(duì)接問(wèn)題就是時(shí)區(qū)混用。服務(wù)器在北京、網(wǎng)關(guān)在東八區(qū)、數(shù)據(jù)庫(kù)用的UTC、前端展示又轉(zhuǎn)一次一套下來(lái)字段含義全亂。我的建議是傳輸層用Unix秒存儲(chǔ)層統(tǒng)一用UTC展示層按業(yè)務(wù)時(shí)區(qū)轉(zhuǎn)換。各層職責(zé)單一才能避免越轉(zhuǎn)越亂。補(bǔ)傳數(shù)據(jù)的標(biāo)記要保留。網(wǎng)關(guān)補(bǔ)傳的數(shù)據(jù)點(diǎn)位級(jí)timestamp會(huì)明顯早于接收時(shí)間。服務(wù)端落庫(kù)時(shí)可以額外記錄receive_time字段用于后續(xù)排查數(shù)據(jù)延遲問(wèn)題。這也能幫助判斷網(wǎng)絡(luò)穩(wěn)定性——如果經(jīng)常出現(xiàn)大批補(bǔ)傳記錄說(shuō)明現(xiàn)場(chǎng)到服務(wù)器的網(wǎng)絡(luò)鏈路并不理想需要協(xié)調(diào)網(wǎng)絡(luò)排查了。4.3 壓力不大也要做對(duì)的三件事監(jiān)測(cè)點(diǎn)數(shù)量有限、上報(bào)周期分鐘級(jí)服務(wù)端的并發(fā)壓力通常不會(huì)很大。但有三件事就算壓力不大我也強(qiáng)烈建議做對(duì)。第一件日志要夠用。至少記錄接收時(shí)間、設(shè)備ID、報(bào)文長(zhǎng)度、處理耗時(shí)、返回狀態(tài)。不需要把整個(gè)報(bào)文都打進(jìn)去報(bào)文太大刷日志也挺麻煩但關(guān)鍵字段必須有。否則線上出問(wèn)題你拿什么復(fù)盤第二件接口要有健康檢查。對(duì)接方或者你自己運(yùn)維時(shí)需要一個(gè)簡(jiǎn)單的HEAD或GET接口確認(rèn)服務(wù)存活比如 /health 返回200。這不算對(duì)接必需但遇到網(wǎng)關(guān)配置了上報(bào)卻一直沒(méi)數(shù)據(jù)時(shí)你能先確認(rèn)服務(wù)本身活著而不是對(duì)著空氣查半天。第三件異常要分級(jí)告警。接口返回5xx、設(shè)備連續(xù)N個(gè)周期沒(méi)有上報(bào)、單批次點(diǎn)位數(shù)量與預(yù)期明顯不符這三類情況分別給出不同級(jí)別的告警策略。連續(xù)N周期無(wú)上報(bào)通常意味著現(xiàn)場(chǎng)采集鏈路出了大問(wèn)題早點(diǎn)發(fā)現(xiàn)比什么都強(qiáng)。5. 常見(jiàn)問(wèn)題與排查實(shí)錄這章把我實(shí)際遇到過(guò)的問(wèn)題按“表現(xiàn)現(xiàn)象-可能原因-解決方法”的方式整理成速查表再挑三個(gè)典型案例細(xì)說(shuō)。很多坑不實(shí)際踩一遍光看文檔是看不出來(lái)的。表現(xiàn)現(xiàn)象可能原因解決方案服務(wù)器一直收不到數(shù)據(jù)網(wǎng)關(guān)填的URL地址錯(cuò)誤或不可達(dá)先用curl在服務(wù)器本地模擬POST確認(rèn)接口通收到了但返回401Token或Header鑒權(quán)字段錯(cuò)誤核對(duì)對(duì)方文檔注意Header名大小寫數(shù)據(jù)到了但是亂碼編碼格式不一致統(tǒng)一使用UTF-8檢查網(wǎng)關(guān)側(cè)編碼設(shè)置時(shí)間差了8小時(shí)時(shí)區(qū)未統(tǒng)一或字符串時(shí)間無(wú)時(shí)區(qū)改成Unix秒傳輸入庫(kù)用UTC高頻重復(fù)數(shù)據(jù)網(wǎng)關(guān)重試與服務(wù)器超時(shí)沖突唯一索引去重確認(rèn)處理超時(shí)閾值是否合理部分點(diǎn)位一直缺失點(diǎn)位上報(bào)配置或采集映射不全核對(duì)點(diǎn)位表確認(rèn)是否漏配變量5.1 上報(bào)失敗最常見(jiàn)的五個(gè)原因第一個(gè)URL配錯(cuò)或基礎(chǔ)設(shè)施不通。排查方法是繞過(guò)網(wǎng)關(guān)直接在服務(wù)器上用curl帶同樣報(bào)文發(fā)一次。如果curl也失敗先查網(wǎng)絡(luò)和防火墻。這個(gè)動(dòng)作應(yīng)該作為所有排查的第一步它能把“網(wǎng)關(guān)問(wèn)題”和“接口問(wèn)題”快速切分。第二個(gè)鑒權(quán)字段沒(méi)對(duì)上。對(duì)方文檔說(shuō)Header里加“Authorization: Bearer xxx”你在網(wǎng)關(guān)配置里卻把整個(gè)“Bearer xxx”當(dāng)成Token。網(wǎng)關(guān)可能把自定義Header當(dāng)成固定字面量原樣發(fā)送那這樣就對(duì)了但有些網(wǎng)關(guān)配置會(huì)區(qū)分“Header名”和“Header值”一旦填錯(cuò)位置對(duì)方就收到一個(gè)沒(méi)有鑒權(quán)頭的請(qǐng)求。我的經(jīng)驗(yàn)是把對(duì)方給的鑒權(quán)示例原樣抓包看一遍比用肉眼看配置更靠譜。第三個(gè)內(nèi)容類型不匹配。對(duì)方接口只認(rèn)application/json網(wǎng)關(guān)卻默認(rèn)發(fā)了text/plain。很多網(wǎng)關(guān)的HTTP通道允許自定義Content-Type但默認(rèn)值未必是你要的。這個(gè)配置項(xiàng)總藏在不起眼的地方排查時(shí)專門去看一眼。第四個(gè)請(qǐng)求超時(shí)時(shí)間太短。網(wǎng)關(guān)默認(rèn)超時(shí)可能只有5秒而接收接口因?yàn)闃I(yè)務(wù)處理慢響應(yīng)超過(guò)5秒。網(wǎng)關(guān)判定失敗觸發(fā)重試。數(shù)據(jù)正式入庫(kù)了重復(fù)請(qǐng)求又來(lái)了。這種問(wèn)題如果沒(méi)有去重機(jī)制數(shù)據(jù)庫(kù)會(huì)被大量重復(fù)數(shù)據(jù)淹沒(méi)。第五個(gè)網(wǎng)關(guān)本地緩存滿導(dǎo)致舊數(shù)據(jù)被覆蓋。斷網(wǎng)太久緩存寫滿之后要么阻塞新數(shù)據(jù)寫入要么丟棄最舊的數(shù)據(jù)。無(wú)論哪種監(jiān)控曲線都會(huì)出現(xiàn)斷檔。定期查看網(wǎng)關(guān)緩存占用及時(shí)發(fā)現(xiàn)網(wǎng)絡(luò)異常是運(yùn)維側(cè)要做的事。5.2 數(shù)據(jù)到了但入庫(kù)不對(duì)的排查思路數(shù)據(jù)成功到達(dá)接口卻不代表入庫(kù)結(jié)果正確。有一次現(xiàn)場(chǎng)排查接口日志顯示每批報(bào)文都正常返回成功數(shù)據(jù)庫(kù)里value值卻始終不變。查到最后發(fā)現(xiàn)是數(shù)據(jù)庫(kù)連接池滿了save_to_db實(shí)際拋異常被吞掉數(shù)據(jù)全被丟進(jìn)了異常分支。這是一個(gè)典型教訓(xùn)接口返回成功只代表業(yè)務(wù)邏輯被接收了不代表持久化成功。打印日志時(shí)一定要區(qū)分兩個(gè)節(jié)點(diǎn)接收成功和入庫(kù)成功。另一個(gè)常見(jiàn)情況是值對(duì)不上。比如現(xiàn)場(chǎng)讀數(shù)7.35數(shù)據(jù)庫(kù)里存成7。這大概率是數(shù)據(jù)類型定義問(wèn)題。網(wǎng)關(guān)上傳的value如果是浮點(diǎn)數(shù)JSON解析時(shí)被轉(zhuǎn)成整型小數(shù)點(diǎn)直接被截?cái)?。服?wù)端定義字段時(shí)要用float或decimal不要用int接收。這個(gè)坑在數(shù)據(jù)量大的表里尤其隱蔽因?yàn)椴皇敲織l都丟只是丟失小數(shù)部分。還有一類是點(diǎn)位錯(cuò)位。網(wǎng)關(guān)點(diǎn)位映射順序改了之后報(bào)文里的dataPoints數(shù)組順序可能也隨之變化而服務(wù)端如果按數(shù)組下標(biāo)而不是pointId去關(guān)聯(lián)業(yè)務(wù)字段就會(huì)把pH誤存成濁度。這也是我堅(jiān)持報(bào)文里必須帶pointId的原因?qū)幙蓤?bào)文長(zhǎng)一點(diǎn)也不要在消費(fèi)端用隱式順序。5.3 高頻上報(bào)與存儲(chǔ)方案的取舍有些人擔(dān)心HTTP上報(bào)太頻繁服務(wù)器吃不消。實(shí)際監(jiān)測(cè)場(chǎng)景一分鐘一包也就幾十個(gè)點(diǎn)位算下來(lái)也就每秒一兩筆寫入普通關(guān)系型數(shù)據(jù)庫(kù)毫無(wú)壓力。真正要操心的是歷史數(shù)據(jù)膨脹。比如一個(gè)監(jiān)測(cè)點(diǎn)一分鐘一條一天1440條一年52萬(wàn)條如果50個(gè)監(jiān)測(cè)點(diǎn)就是2600萬(wàn)條。這種量級(jí)如果還按業(yè)務(wù)主表存儲(chǔ)查詢會(huì)越來(lái)越慢。我的建議是默認(rèn)分成兩張表實(shí)時(shí)數(shù)據(jù)表和歷史歸檔表。實(shí)時(shí)表只保留最近一天或一周按時(shí)間清理。歷史表定期做降采樣聚合比如把秒級(jí)數(shù)據(jù)聚合成分鐘平均值、小時(shí)平均值。報(bào)表展示走歷史聚合表實(shí)時(shí)曲線走實(shí)時(shí)表。這個(gè)設(shè)計(jì)雖然不是這次對(duì)接的必選項(xiàng)但數(shù)據(jù)跑半年之后你會(huì)感謝當(dāng)初做了拆分。另外寫入策略上不要實(shí)時(shí)一條條插入。網(wǎng)關(guān)每批報(bào)文本身就是一批點(diǎn)位服務(wù)端接收后批量插入一次插幾十行。批量插入比單行逐條插入性能好一個(gè)量級(jí)而且對(duì)數(shù)據(jù)庫(kù)事務(wù)也友好。這個(gè)小動(dòng)作成本極低后患極少值得每一個(gè)對(duì)接方案里都帶上。我的實(shí)操體會(huì)這套方案上線后跑了幾個(gè)月最大的感受是HTTP上報(bào)這第二種方式看著樸素但在對(duì)接場(chǎng)景里其實(shí)是“最不容易吵架”的方案。對(duì)方系統(tǒng)給個(gè)URL你這邊配好網(wǎng)關(guān)聯(lián)調(diào)用curl模擬幾組報(bào)文通了就完事。不需要對(duì)方懂MQTT不需要額外部署消息中間件更不用協(xié)調(diào)1883端口放行很多界面上的溝通成本直接消失。最后分享一個(gè)我積累的習(xí)慣新對(duì)接一個(gè)平臺(tái)永遠(yuǎn)先脫離網(wǎng)關(guān)做一次純接口聯(lián)調(diào)。用curl手動(dòng)構(gòu)造一份固定報(bào)文POST到對(duì)方接口確認(rèn)字段、鑒權(quán)、返回碼都對(duì)再讓網(wǎng)關(guān)去推真實(shí)數(shù)據(jù)。這樣可以區(qū)分開(kāi)“對(duì)方接口問(wèn)題”和“網(wǎng)關(guān)配置問(wèn)題”。如果一上來(lái)就讓網(wǎng)關(guān)推數(shù)據(jù)兩邊同時(shí)出問(wèn)題時(shí)排查起來(lái)相當(dāng)痛苦。另外報(bào)文字段的定義文檔哪怕是兩三頁(yè)看似多余的說(shuō)明也一定要在聯(lián)調(diào)前發(fā)對(duì)方確認(rèn)字段單位、時(shí)間格式、質(zhì)量碼規(guī)則都逐字核對(duì)這一步省下的返工時(shí)間往往比寫整個(gè)接收接口還多。