物聯網項目，采集設備測點過多有什么架構設計方案？

萬點以上物聯網采集架構設計：從“能采”到“穩采”的四個關鍵技術抉擇

上周和某水務集團的技術負責人交流，他們一個30萬噸水廠改造項目，規劃測點從最初設計的3000點一路追加到近2萬點。原以為網關配置夠高就能搞定，結果POC測試時系統直接卡死——不是采不上來，而是采上來之后數據根本跑不動。

測點過萬在工業物聯網項目中已經不是極端場景，而是新常態。慕尼黑機場的建筑自動化系統有28萬個數據點需要接入，某車企車聯網平臺要處理億級測點、千萬級每秒寫入。當測點數量從“千”跨越到“萬”，架構設計邏輯需要徹底重構。以下是我跟蹤多個大型項目后梳理的四條核心設計原則。

一、邊緣層必須做“減法”：不要試圖采集所有原始數據

很多項目失敗的第一原因：把所有點位數據原封不動往平臺上送。一條產線振動傳感器1kHz采樣率，一天就是86GB數據，云端再強大的時序數據庫也扛不住這種流量。

正確做法是在邊緣網關側做三道預處理：

第一，批量讀取替代單點輪詢。某工廠改造項目中，采用Modbus批量寄存器讀取，一個節點一次性讀取一整塊連續地址，在網關內部做拆分映射，采集效率提升5倍以上。

第二，變化上報替代周期上報。溫度穩定在25℃±0.1時，沒必要每秒上報。設置死區閾值，只有數值變化超過設定范圍才上傳。華為云一個2000臺設備的項目，通過這個策略讓整體流量降低60%。

第三，邊緣計算提取特征值。振動數據1kHz原始采樣在邊緣做FFT變換，只上傳頻譜特征值，數據量減少99%，而且更有分析價值。

二、協議層必須做“兼容”：Modbus采底層，MQTT傳上層

萬點采集必然面臨協議碎片化：智能電表用Modbus RTU，PLC用OPC UA，新型傳感器可能走MQTT。讓平臺直接處理多協議接入是架構災難。

成熟的架構是分層處理：邊緣層以Modbus為主，覆蓋現場95%以上的傳統工業設備，通過輪詢方式“拉取”數據。傳輸層以MQTT為主，邊緣節點將處理后的數據通過MQTT“推送”到中心平臺。

這種“Modbus采上來，MQTT傳出去”的組合，實現了從現場總線到物聯網協議的無縫轉換。美國某中游管道運營商管理350個遠程站點、50萬測點，采用的就是這套模式：邊緣網關采集PLC數據(Modbus/DNP3)，通過MQTT Sparkplug B協議發布到中心Broker，即使衛星網絡中斷也能本地緩存續傳。

三、傳輸層必須做“分級”：不是所有數據都走同一條路

萬點采集的另一個坑：重要告警和例行數據搶帶寬，結果關鍵事件被堵在路上。

合理做法是建立分級傳輸機制：

??QoS 0級：周期性溫度、濕度、壓力數據，丟了不可惜，走普通通道

??QoS 1級：設備狀態變更、告警事件，確保至少一次送達

??QoS 2級：遠程控制指令、參數下發，嚴格保證不重不漏

同時要在邊緣做本地緩存和斷網續傳。衛星鏈路中斷是常態，網關必須支持磁盤隊列緩存，網絡恢復后自動續傳。慕尼黑機場的28萬點采集項目，核心考量之一就是通信可靠性和低功耗。

四、存儲層必須做“壓縮”：時序數據庫是唯一選擇

萬點采集產生的時序數據，用傳統關系型數據庫存儲是自殺行為。必須采用原生時序數據庫。

國產IoTDB在某鋼廠智能運維平臺中，接入數百萬設備、千萬級時間序列，通過列式存儲和復合壓縮算法，數據壓縮比達到10倍以上。阿里Lindorm時序引擎采用LSM-Tree結構和Zstandard壓縮，存儲空間壓縮至原始數據的1/5~1/10.

更關鍵的是冷熱數據分層：熱數據(最近7天)保留在高性能SSD，冷數據自動壓縮遷移到對象存儲，查詢性能不受影響，存儲成本降低30%~50%。

五、實戰配置建議

基于上述原則，給出不同規模項目的參考配置：

1-5萬點中型項目(如中型工廠、園區)：

??邊緣層：4-8臺工業網關(如BL118級)，每臺支持4路RS485+2路網口，掛載20-30臺設備

??傳輸層：本地MQTT Broker集群

??存儲層：單節點時序數據庫，SSD存儲熱數據

5-20萬點大型項目(如機場、鋼鐵廠)：

??邊緣層：分布式邊緣節點，按車間/區域部署

??傳輸層：分級Broker架構(邊緣Broker+工廠Broker+云端Broker)

??存儲層：時序數據庫集群，支持分布式查詢和冷熱分層

20萬點以上超大規模(如車聯網、城市級物聯)：

??參考慕尼黑機場28萬點方案：mioty LPWAN無線采集+自動化主數據遷移+智能數據庫自配置

??或參考某車企千萬級寫入架構：Kafka+Flink+時序數據庫實時處理鏈路

萬點采集的技術核心不是“采得上”，而是“采得穩、傳得快、存得省”。如果您手頭有具體項目正在規劃，或現有系統遇到性能瓶頸，歡迎帶測點規模和數據頻率交流。