物联网项目，采集设备测点过多有什么架构设计方案？

万点以上物联网采集架构设计：从“能采”到“稳采”的四个关键技术抉择

上周和某水务集团的技术负责人交流，他们一个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+时序数据库实时处理链路

万点采集的技术核心不是“采得上”，而是“采得稳、传得快、存得省”。如果您手头有具体项目正在规划，或现有系统遇到性能瓶颈，欢迎带测点规模和数据频率交流。