物联网架构全景与分层模型

引言

物联网工程的难点不在于把传感器接上网，而在于让几十万到上千万台异构设备产生的数据，稳定、低成本、可治理地流入平台并驱动业务。设备侧资源受限、网络不稳定、协议碎片化；平台侧要同时承担连接管理、设备生命周期、数据管道与应用使能四类职责。任何一层设计失误，都会在规模化时放大成事故。

分层模型是讨论物联网架构的通用语言。它规定了每层负责什么、不负责什么，从而让协议选型、组件划分与团队边界有据可依。但三层模型与四层模型之争、参考架构的落地差异、边缘层是否必要，往往在项目启动时被含糊带过，等到接入量上来才返工，返工成本随设备基数线性增长。

本文先对齐分层模型与主流参考架构，再厘清设备侧与平台侧的职责边界，随后用一条端到端数据流把各层串起来，最后给出选型、规模估算与行业落地的判断方法。协议细节只在定位层面点到，MQTT 的报文结构与 QoS 语义见 MQTT 协议与 Broker 实践 。

目录

1. 四层模型与三层模型
2. 参考架构：ITU-T Y.2060 与 oneM2M
3. 工业互联网参考架构与云厂商架构
4. 设备侧与平台侧的职责边界
5. 边缘层为何被引入
6. MQTT 与 CoAP 的定位差异
7. 一条端到端数据流的完整旅程
8. 自建与云 IoT 平台的选型
9. 规模估算方法
10. 典型行业落地差异
11. 部署形态与网络拓扑
12. 架构演进路线

1. 四层模型与三层模型

三层模型把物联网拆成感知层、网络层、应用层。感知层负责采集与执行，网络层负责传输，应用层负责业务呈现。它简单直观，适合早期概念沟通，但把「平台」隐含在应用层里，导致连接管理、设备管理、数据存储这些共性问题没有归属，每个项目各写一套。

四层模型在三层之间插入平台层，形成感知层、网络层、平台层、应用层。平台层承接设备接入、协议适配、设备影子、规则引擎、时序存储与 API 开放，应用层只面向业务逻辑。工程上四层模型更可落地，因为平台层正是投入最大、复用价值最高的部分。

实践中的划分口径是：谁维护设备连接状态，谁就在平台层。设备影子、会话状态、离线消息缓存都属于平台层职责，把它们塞进应用层会导致每个业务系统重复实现会话管理，一致性无从保证。

1.1 各层的关键能力

1.2 什么时候三层就够了

纯上报型项目（如共享单车定位）如果只有一个应用消费数据，且不需要下行控制，三层模型的简化反而减少组件数。一旦出现第二个消费方或需要下行指令，平台层就必须独立出来。

2. 参考架构：ITU-T Y.2060 与 oneM2M

ITU-T Y.2060（2012）给出了物联网的官方定义与四层参考模型，并首次明确万物互联与设备、网关、平台、应用的角色划分。它是概念框架，不规定协议，但被各国标准广泛引用，理解它的价值在于对齐术语。

oneM2M 是更工程化的标准族，定义了 Common Service Entity（CSE）与 Application Entity（AE），通过 Mca、Mcc、Mcn 三组参考点连接应用、服务与网络。oneM2M 的核心贡献是把服务能力抽象成可复用的 REST 资源树，设备、网关、平台都实现 CSE，从而实现跨厂商互通。

oneM2M 参考点
  Mca  AE  <-> CSE   应用访问服务能力（REST API）
  Mcc  CSE <-> CSE   服务能力之间互联（平台间）
  Mcn  CSE <-> NSE   服务能力访问底层网络

它的资源模型与 LwM2M 的对象模型思想相通，两者都把设备能力抽象成可寻址的资源树，只是 oneM2M 面向服务能力，LwM2M 面向受限设备管理。

3. 工业互联网参考架构与云厂商架构

IIRA（Industrial Internet Reference Architecture）用业务、使用、功能三个视角描述系统，强调跨企业的价值链协同与安全可信。工业场景的独特约束是确定性时延与功能安全，因此 IIRA 把实时控制面与信息面分开，控制回路留在现场，数据上云只做优化与追溯。

云厂商架构（AWS IoT Core、Azure IoT Hub、阿里云物联网平台、华为 IoTDA）本质是产品化的四层模型：

• 接入层：提供 MQTT、CoAP、HTTPS 端点，支持双向认证与配额限制。
• 设备管理层：设备注册、设备影子、OTA、远程配置。
• 数据层：规则引擎做过滤与转发，投递到 TSDB、对象存储或函数计算。
• 应用层：开放 API、设备管理控制台与低代码可视化。

它们的差异主要在设备数配额、消息计费口径与边缘产品线的完整度。选架构时不要把参考架构当规范逐条实现，而要把它当作检查表：确认连接管理、设备管理、数据管道、应用使能四类能力都有明确归属，缺哪块就在项目初期补上。

4. 设备侧与平台侧的职责边界

设备侧负责采集、本地决策、协议上报与固件升级；平台侧负责身份、会话、路由、存储与开放。边界模糊的典型症状是设备做了本该平台做的事，例如在 MCU 上实现复杂的重传与去重逻辑，把有限的 RAM 耗在业务无关的地方。

清晰的划分原则：

• 设备侧只保证尽力上报加幂等标识，不做全局去重与聚合。
• 平台侧承担会话状态、离线消息、消息去重与顺序保证。
• 设备侧保存最小状态（配置、密钥、时间基准），其余状态放设备影子。
• 平台侧不假设设备在线，所有下行指令都要考虑离线补发。

4.1 参数由谁定

MCU 上跑的重传参数、Keep Alive 间隔属于设备侧实现，但取值必须由平台侧约束。若平台侧把会话超时定为 60 秒，而设备侧 Keep Alive 设成 120 秒，平台会先判定离线再收到心跳，产生反复上下线抖动。

设备侧 Keep Alive < 平台侧会话超时 / 1.5
例：平台会话超时 60s -> 设备 Keep Alive 取 30s 左右

4.2 状态归属速查

5. 边缘层为何被引入

边缘层的引入有三个直接动机：带宽、时延、断网可用性。

带宽方面，以每秒 1000 点、每点 32 字节计算，单条产线一天约 2.7 GB 原始数据，全部上云在带宽与存储成本上都不划算；边缘侧先做降采样与阈值过滤，可把上行量压到十分之一。

时延方面，云端往返通常 50 到 200 ms，而产线级控制需要 1 到 10 ms，控制回路只能在边缘闭环。

断网可用性更关键：矿区、船舶、农机常年弱网，边缘节点必须缓存并续传，这要求边缘具备本地存储与断点续传能力。

5.1 边缘节点的部署形态

边缘节点通常容器化，用 K3s 或 Docker Compose 承载规则引擎与协议适配器，配合 Linux 的命名空间与 cgroup 隔离保证多租户与资源上限，隔离机制细节可参考 容器隔离机制与实现 。

services:
  edge-broker:
    image: emqx/emqx:5.8
    ports: ["1883:1883"]
    deploy:
      resources:
        limits: {cpus: "2.0", memory: 1g}
  edge-rule:
    image: registry.local/edge-rule:1.4.2
    environment:
      UPSTREAM: "mqtt://cloud-broker:8883"
      BUFFER_DIR: "/data/buffer"
    volumes: ["edge-data:/data"]
volumes:
  edge-data: {}

网关侧的分层与选型展开见 边缘计算与网关架构 。

6. MQTT 与 CoAP 的定位差异

一句话概括：MQTT 面向设备到云的可靠消息通道，CoAP 面向受限设备上的轻量 REST 交互。

MQTT 基于 TCP，长连接、发布订阅、支持 QoS 与离线消息，适合有稳定供电与网络的设备，以及需要下行指令的场景。CoAP 基于 UDP，请求响应模型加 Observe 通知，报文头部仅 4 字节，适合 NB-IoT、Thread 这类窄带与低功耗场景。

选择依据是链路质量、功耗预算与是否需要双向频繁通信，而不是团队熟悉度。判断口径可以简化为三条：

• 设备有常电且需要频繁下行：选 MQTT。
• 设备电池供电、上报稀疏、需要省电：选 CoAP。
• 设备在受限网络内且需要网关汇聚：CoAP 到网关，网关转 MQTT 上云。

两者并非互斥。设备用 CoAP 接入网关，网关再以 MQTT 上云，是常见组合。协议栈选型后面还有 LPWAN 的维度：链路带宽、功耗预算与覆盖半径共同决定底层承载，NB-IoT 重覆盖与低功耗，LoRaWAN 重自建与远距离。

7. 一条端到端数据流的完整旅程

以一个温度采集场景为例，走一遍完整链路：

传感器 DS18B20
  -> MCU（ESP32）每 10s 采样，本地滑动平均滤波
  -> 组包 {"ts":1730000000,"t":23.5}，MQTT PUBLISH QoS1
  -> 网关/Broker（EMQX）鉴权、ACL 校验、主题路由
  -> 规则引擎：SQL 过滤 t > 40 触发告警，全量转发 TSDB
  -> 时序库（TDengine/InfluxDB）按设备维度写入
  -> 可视化（Grafana）出曲线，告警通道推送

设备侧的上报报文通常带自增序号，便于平台去重：

{"did":"dev-9f3a","seq":10241,"ts":1730000000,"temp":23.5,"rssi":-67}

每一跳都有明确的失败模式：传感器总线 CRC 错误、MCU 队列溢出、Broker 鉴权拒绝、规则引擎反压、TSDB 写入放大。架构设计要做的是让每一跳可观测，而不是假设它们不会失败。

-- TDengine 建库建表：一设备一子表，按天分区
CREATE DATABASE iot KEEP 90 DAYS;
CREATE STABLE iot.metrics (ts TIMESTAMP, temp FLOAT, rssi INT)
  TAGS (did BINARY(32), model BINARY(16));
INSERT INTO iot.d_9f3a USING iot.metrics TAGS ('dev-9f3a','TH-01')
  VALUES (1730000000000, 23.5, -67);

数据上行的同时，平台侧可能还需要一份设备状态镜像供应用查询，这正是设备影子的用途：它把期望配置与上报配置分开存储，解决下行指令与设备实际状态之间的最终一致性问题。若还要做仿真与预测性维护，则进入数字孪生的范畴，见 数字孪生平台架构 。

8. 自建与云 IoT 平台的选型

自建意味着自己维护 Broker 集群、TSDB、规则引擎与 OTA 服务，优点是数据主权、可深度定制、长期单位成本低；代价是初期投入与运维复杂度，一个支撑十万连接的 EMQX 集群至少要三人维护。

云 IoT 平台的优点是开箱即用、按量付费、弹性扩容，代价是消息计费单价高、跨云迁移困难、深度定制受限。

选型的经验法则：

• 设备数小于一万且团队小于五人：优先云平台。
• 设备数超过十万或数据合规要求严格：考虑自建。
• 介于两者之间：混合方案，云平台做接入，自建 TSDB 做存储。

8.1 混合方案的边界

混合方案最容易出问题的是「设备身份由谁签发」。若云平台签发证书而自建 TSDB 又要校验设备身份，需要把身份源统一，通常做法是自建身份服务作为唯一签发方，云平台只做透传认证。

9. 规模估算方法

架构评审前必须先算清三个量，否则容量规划无从谈起。

9.1 连接数

设备总数乘以并发在线率。常电设备在线率接近 1，电池设备按上报周期估算，例如每 30 分钟上报一次的设备，保持长连接的比例通常低于 10%。

9.2 消息速率

msg/s = 设备数 × 每设备消息频率。十万台设备每 10 秒上报一次，即 10,000 msg/s 上行；若每条消息还有下行确认与影子更新，实际 Broker 负载要乘以 2 到 3。

9.3 存储量

日增数据 = 点位速率 × 单点字节 × 86400。1000 点位、每点 32 字节、每秒一次，日增约 2.7 GB，保留 90 天即 240 GB，再乘副本因子与索引开销，实际磁盘预留要放大 2 到 3 倍。

日增数据 = 点位速率(point/s) × 单点字节 × 86400
总存储   = 日增数据 × 保留天数 × 副本因子 × 索引膨胀系数
示例     = 1000 × 32 × 86400 = 2.76 GB/天
          2.76 × 90 × 2(副本) × 1.3(索引) ≈ 646 GB

9.4 成本量级

自建的成本主要是服务器与人力：十万连接量级约需 3 台 8 核 16G Broker、2 台 TSDB、1 台网关，月成本数千元，加运维人力。云平台按消息计费，需按实际报文量乘系数估算，容易低估下行与影子流量。

10. 典型行业落地差异

不同行业的架构重心差异很大，用同一套模板会踩坑。

10.1 智能家居

设备数多但单设备数据少，重在下行控制与配网体验，云平台首选，协议以 MQTT over TLS 为主，本地可选 Matter/Thread。

10.2 工业制造

确定性与可靠性优先，边缘节点必备，协议常用 OPC UA 加 MQTT 组合，数据保留与追溯要求高，TSDB 写入量最大。

10.3 车联网

单车数据量大（每秒数百信号点），移动网络切换频繁，必须做边缘预聚合与断点续传，且强合规要求数据不出境。

10.4 智慧农业

供电与网络都受限，LPWAN 为主，上报频率低但节点分布广，架构重心是低功耗与广覆盖，而非低时延。

11. 部署形态与网络拓扑

接入侧的常见拓扑有星型、树型与网状三种。星型由设备直连 Broker，简单但依赖网关覆盖；树型通过网关汇聚，适合大规模分层部署；网状（如 Thread、Zigbee Mesh）设备间可中继，抗单点故障但路由维护复杂。

平台侧通常按可用区分片：Broker 集群按设备 ID 哈希分片，会话状态放 Redis 或内置集群存储，TSDB 按时间分区。跨区容灾的关键是会话可重建，因为设备重连成本远低于跨区状态同步成本。

网络层面要预留三类通道：

• 设备上行数据通道：遥测与事件，量大，允许一定延迟。
• 下行指令通道：控制与配置，量小，要求低延迟与可确认。
• 运维管理通道：OTA、日志、诊断，突发大流量。

三者混在一条通道上会让大文件 OTA 挤占遥测带宽，实践中应做 QoS 或端口隔离。

12. 架构演进路线

架构不是一次设计完成的，建议按三阶段演进。

第一阶段（0 到 1 万设备）：单集群 Broker 加单实例 TSDB，规则引擎做过滤转发，先跑通端到端链路，把可观测性做起来。

第二阶段（1 万到 50 万设备）：Broker 集群化并分片，引入设备影子与 OTA 服务，TSDB 分片，边缘网关承担预聚合，建立容量与成本模型。

第三阶段（50 万以上）：多地域接入、跨区容灾、数据分级存储（热数据 TSDB、冷数据对象存储），引入数字孪生与预测性维护，把平台能力 API 化对外开放。

每一阶段都要回答同一个问题：当前架构的下一个瓶颈在哪一层，是连接、消息、存储还是成本。

权衡取舍

• 分层粒度：层数越多职责越清晰，但跨层调用开销与运维面也越大，中小项目四层已足够。
• 边缘与云端：边缘降低带宽与时延，但增加部署与升级复杂度，弱网场景收益最大。
• 自建与云平台：自建长期便宜但前期贵，云平台前期便宜但规模大后单位成本高。
• 协议统一：全站统一 MQTT 便于运维，但受限设备上 CoAP 更省电，强行统一会牺牲功耗。
• 数据保留：保留越久追溯越强，但存储成本线性增长，建议热冷分层。
• 状态归属：状态尽量上收平台便于统一治理，但会增加断网时的不可用面。

常见坑清单

• 把会话状态放应用层：现象是每个业务重复实现在线判定，原因是平台层缺失设备管理，规避方法是设备影子统一托管状态。
• 忽略离线消息容量：现象是设备重连瞬间 Broker 内存暴涨，原因是持久会话无限堆积，规避方法是设置 Session Expiry 与队列上限。
• 用消息数估算成本：现象是账单远超预期，原因是只算了上行没算下行与影子更新，规避方法是按实际报文量乘系数。
• 边缘节点无本地缓存：现象是断网即丢数据，原因是假设网络永远在线，规避方法是边缘落盘加断点续传。
• 单集群无分片：现象是连接数到阈值后雪崩，原因是 Broker 单点承载，规避方法是按设备 ID 哈希分片。
• 遥测与 OTA 共用通道：现象是升级期间遥测延迟飙升，原因是带宽争抢，规避方法是通道隔离或限速。
• 直接暴露 Broker 端口：现象是被扫描后出现异常订阅，原因是缺少 ACL 与 TLS，规避方法是强制双向认证并最小权限。
• 过早引入数字孪生：现象是投入大收益小，原因是基础数据管道未稳定，规避方法是先跑通采集存储再建模。
• 忽略时钟同步：现象是时序数据乱序，原因是设备无 NTP，规避方法是设备侧校时并在平台侧做乱序容忍。
• 心跳与会话超时不匹配：现象是设备反复上下线，原因是 Keep Alive 大于平台会话超时，规避方法是按 1.5 倍关系取值。

小结

物联网架构的本质是把连接、设备、数据、应用四类职责分层归位。四层模型比三层模型更适合工程落地，参考架构的价值在于当检查表而不是当规范。设备侧与平台侧的边界、边缘层的取舍、自建与云的权衡，都需要结合设备规模、网络条件与合规要求具体判断，而不是套用模板。

规模估算是所有架构决策的前提：先算清连接数、消息速率与存储量，再决定分片、缓存与保留策略。行业差异决定了架构重心，工业重确定性与边缘，车联网重移动性与合规，农业重功耗与覆盖，家居重下行与体验。

下一步建议从协议细节入手：先搞清设备接入侧的报文与 QoS 语义，再理解受限设备侧的对象模型与注册流程，最后结合边缘网关的部署形态把架构落到具体机房与现场。