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