2. 物联网基础架构
物联网系统设计的第一课，不是选型，而是建立分层思维。许多项目失败，并非硬件不行或云端不稳，而是将感知、传输、平台、应用混为一谈，导致接口混乱、协议错配、数据链路失控。本章从经典的四层模型出发，厘清每一层的职责边界，再深入设备接入的三种通信模式，最后给出MQTT、CoAP、HTTP三大协议的选型决策框架。理解这些内容，是后续进行设备接入开发、平台对接和运维排障的基石。
上图展示了物联网四层架构的完整视图。感知层负责物理世界的数字化，网络层解决数据如何传输，平台层提供设备管理与数据服务，应用层面向最终用户交付价值。右侧标注的三种协议贯穿网络层与平台层之间，是设备接入的核心技术选型。下面逐一展开。
2.1 四层模型的核心原理与职责边界
核心原理：物联网分层模型并非简单的功能堆叠，而是为了解耦。每一层只关注自己的职责，通过标准接口与相邻层交互。感知层不关心数据如何到达云端，平台层不关心传感器具体型号。这种解耦带来的直接好处是：更换传感器不影响平台逻辑，升级通信协议不影响应用层代码。
| 层次 | 核心职责 | 典型技术 | 关键接口 | 常见误区 |
|---|---|---|---|---|
| 感知层 | 数据采集与执行控制 | 传感器、MCU、RTOS | I2C/SPI/UART/GPIO | 忽略信号调理与电源噪声 |
| 网络层 | 数据传输与路由 | Wi-Fi、4G、NB-IoT、LoRa | IP/非IP、网关协议转换 | 盲目追求高带宽，忽视功耗 |
| 平台层 | 设备管理、数据存储、规则引擎 | MQTT Broker、时序数据库 | MQTT/CoAP/HTTP API | 设备影子与真实状态不同步 |
| 应用层 | 业务逻辑与用户交互 | Web/APP、可视化、报表 | RESTful API、WebSocket | 直接访问设备，绕过平台 |
判断方法：在实际项目中，判断一个组件属于哪一层，可以问三个问题：它是否直接与物理世界交互？它是否负责数据格式转换？它是否为上层提供API服务？例如，一个温湿度传感器属于感知层，但一个带有协议转换功能的DTU（数据传输单元）则横跨感知层与网络层。
2.2 设备接入的三种通信模式：直连、网关、边缘
核心原理：设备接入模式取决于三个约束：网络环境（是否有公网IP）、功耗预算（电池供电还是市电）、实时性要求（毫秒级还是秒级）。三种模式各有适用场景，并非越先进越好。
- 直连模式：设备内置Wi-Fi/4G模块，直接与云平台建立连接。适用于网络条件好、设备数量少、需要独立工作的场景。优点是架构简单、时延低；缺点是每台设备都要消耗一张SIM卡或Wi-Fi配置，大规模部署成本高。
- 网关模式：设备通过短距通信（Zigbee、BLE、RS485）连接网关，网关再通过以太网/4G上行到平台。适用于设备密集、通信协议异构的场景。网关承担协议转换、数据汇聚、本地缓存等职责。
- 边缘模式：在网关基础上增加本地计算能力，如规则引擎、AI推理、数据清洗。适用于对实时性要求高、网络不稳定、数据量大的场景。边缘节点可以独立运行，断网时业务不中断。
操作流程（网关模式为例）：
- 设备侧：传感器通过RS485总线以Modbus-RTU协议上报数据。
- 网关侧：网关轮询RS485总线，解析Modbus帧，转换为JSON格式。
- 上行：网关通过MQTT over TLS将JSON数据发布到平台Topic。
- 平台侧：平台订阅Topic，解析JSON，写入时序数据库。
- 反向控制：平台下发指令到网关，网关转换为Modbus写寄存器命令。
背景：工厂有200个电表、50个水表，分布在3个车间，现场无Wi-Fi覆盖，但有工业以太网。
初始方案：每个表计加装4G DTU直连云平台。评估后发现：250张SIM卡月租费用高，且4G模块功耗大，电表内部空间不足。
调整方案：采用网关模式。每个车间部署1台边缘网关，通过RS485总线连接所有表计，网关通过以太网上行到平台。网关内置Modbus主站功能，每5秒轮询一次所有表计。
关键参数：网关轮询周期5秒，单次采集数据量约200字节，上行MQTT QoS=1，心跳间隔60秒。
结果：SIM卡费用降为0，网关功耗远低于250个4G模块，且断网时网关本地缓存2小时数据，网络恢复后补传。
复盘：网关模式不仅降低了成本，还提升了系统的可维护性——更换表计时只需在网关侧修改配置，无需动平台。
2.3 MQTT、CoAP、HTTP协议选型
核心原理：三种协议的设计哲学完全不同。HTTP是请求-响应模型，适合客户端主动拉取数据；MQTT是发布-订阅模型，适合设备主动上报和平台主动下发；CoAP是面向受限设备的轻量级请求-响应协议，基于UDP，适合低功耗、低带宽场景。
| 维度 | MQTT | CoAP | HTTP |
|---|---|---|---|
| 传输层 | TCP（默认） | UDP | TCP |
| 模型 | 发布/订阅 | 请求/响应 | 请求/响应 |
| 报文开销 | 2字节固定头 | 4字节基础头 | 较大（含Header） |
| QoS支持 | 0/1/2 | Confirmable/Non-confirmable | 无原生QoS |
| 适用场景 | 频繁上报、双向通信、长连接 | 受限节点、低功耗、少量数据 | Web管理、API调用、一次性查询 |
| 典型端口 | 1883/8883 | 5683/5684 | 80/443 |
判断方法：选型时按以下顺序决策：
- 设备是否支持TCP/IP协议栈？如果不支持，只能选CoAP或网关转换。
- 是否需要平台主动下发指令？如果需要，MQTT的发布/订阅模型最合适。
- 数据上报频率如何？高频（每秒多次）选MQTT，低频（每小时一次）选CoAP或HTTP。
- 网络是否稳定？弱网环境选MQTT QoS=1，配合持久会话。
- 是否需要Web端直接访问设备？如果需要，HTTP RESTful API最直接。
需求：每盏路灯内置控制器，每30秒上报电流、电压、功率因数；平台可远程控制开关和调光；路灯数量5000盏。
分析：上报频率中等，需要双向通信，设备数量大。HTTP每30秒一次请求，5000盏灯意味着每秒约167个请求，服务器压力大且无法主动下发。CoAP虽然轻量，但平台侧需要额外适配。最终选择MQTT：每盏灯维持一个长连接，上报Topic为
streetlight/{id}/telemetry，控制Topic为streetlight/{id}/cmd。关键配置：QoS=1，KeepAlive=60秒，CleanSession=false（断线重连后不丢失离线消息）。
结果：单台EMQX Broker轻松支撑5000连接，消息延迟小于100ms。
代价：需要维护MQTT Broker集群，且设备端需要实现MQTT客户端库，开发量比HTTP略大。
总结复盘：本章的核心在于建立“分层+模式+协议”的三维决策框架。分层解决系统边界问题，模式解决设备如何接入的问题，协议解决数据如何传输的问题。在实际项目中，建议先确定分层架构，再根据设备分布和网络条件选择接入模式，最后根据通信需求选择协议。三者相互关联：例如，选择网关模式后，网关与平台之间通常用MQTT，而网关与设备之间可能用Modbus或CoAP。理解这种嵌套关系，是物联网架构设计的基本功。