2. 物联网基础
一、核心原理：从传感器到云端的端-边-云架构
物联网系统的本质，是将物理世界的模拟信号转化为可计算、可传输、可分析的数字数据。理解这一过程，首先要建立端-边-云三层架构的全局视角。传感器节点（端）负责采集温度、湿度、光照、振动等物理量；边缘网关（边）承担协议转换、数据聚合与本地决策；云平台（云）则完成海量数据的存储、训练与业务闭环。
在传感器网络内部，节点之间通过自组织方式形成拓扑结构。常见的拓扑包括星型、树型和网状（Mesh）型。星型结构简单、功耗可控，适合家庭场景；网状结构可靠性高，但路由开销大，适合工业现场。无论哪种拓扑，数据上报方向始终遵循“传感器 → 汇聚节点 → 网关 → 网络”的单向流动，而控制指令则反向传播。
二、常见通信协议对比：从物理层到应用层
物联网通信协议分布在不同的协议层级。物理层与链路层决定了“信号怎么发出去”，常见的有：
- LoRa：Sub-1GHz 扩频调制，灵敏度高，单跳可达数公里，但速率极低，适合抄表、农业。
- NB-IoT：蜂窝窄带技术，依托运营商基站，覆盖深、移动性好，但模块成本与资费较高。
- ZigBee：基于 802.15.4，Mesh 组网能力强，但网关依赖重，不适合跨互联网通信。
- BLE Mesh：低功耗蓝牙的组网扩展，适合室内照明、定位，但节点规模受限。
真正与业务开发直接相关的是应用层协议。下表从实时性、可靠性、资源占用三个维度对比主流选择：
| 协议 | 传输层 | 消息模型 | 实时性 | 可靠性 | 资源占用 | 典型场景 |
|---|---|---|---|---|---|---|
| MQTT | TCP/TLS | 发布/订阅 | 高（秒级） | QoS 0/1/2 | 极低（头仅2字节） | 传感器上云、远程控制 |
| CoAP | UDP | 请求/响应 + 观察 | 中 | Confirmable消息 | 低 | 资源受限节点 |
| HTTP/REST | TCP | 请求/响应 | 中 | 依赖TCP重传 | 高（头大） | 设备管理、配置下发 |
| AMQP | TCP/TLS | 发布/订阅 + 队列 | 高 | 事务支持 | 高 | 企业级消息总线 |
三、MQTT 的核心机制与优势
MQTT（Message Queuing Telemetry Transport）专为受限网络设计，其优势体现在四个层面：
- 发布/订阅解耦：生产者与消费者互不感知，设备上线、下线不影响消息通路。新增传感器只需订阅对应主题，无需修改云端逻辑。
- QoS 分级保障：QoS 0 最多一次（适合环境监测）、QoS 1 至少一次（适合告警）、QoS 2 恰好一次（适合计费或控制指令）。开发者可按数据价值灵活选择。
- 遗嘱消息（Last Will）：设备异常断网时，Broker 自动代发遗嘱，让云端立即感知设备离线，避免“假在线”误判。
- 主题通配符：支持
+（单层）与#（多层）订阅，例如订阅factory/+/temperature即可获取所有车间的温度数据。
一个典型的 MQTT 连接报文头仅 2 字节，相比 HTTP 动辄数百字节的头部开销，在 NB-IoT 或 LoRa 这类低带宽链路上优势明显。同时 MQTT 保持长连接，避免了 HTTP 频繁建连的握手开销。
四、案例：工厂环境监测系统的协议选型
某汽车零部件工厂需要部署 200 个温湿度传感器和 50 个振动传感器，要求数据每 10 秒上报一次，并能在 5 秒内触发高温告警。技术团队最初考虑使用 HTTP 轮询，但很快发现两个问题：
- 200 个传感器每 10 秒一次 POST 请求，网关并发压力大，且大量连接处于“请求-响应-断开”的循环中，功耗高。
- HTTP 是单向请求模式，云端无法主动下发控制指令（如远程重启某个传感器），只能靠设备频繁轮询。
改用 MQTT 后，架构变为：传感器通过 RS-485 总线汇聚到边缘网关，网关运行 MQTT Client，将数据发布到主题 factory/zone1/temperature。云端订阅 factory/#，实时接收所有数据。告警规则部署在边缘网关本地，一旦温度超过阈值，立即发布到 factory/alarm 主题，同时云端通过遗嘱消息监控网关在线状态。
五、误区与复盘：MQTT 不是万能药
在实际项目中，以下三个误区最容易导致架构返工：
QoS 2 需要四次握手确认，吞吐量约为 QoS 0 的 1/3。对于周期性上报的温度数据，QoS 0 完全够用，丢失一帧下一帧会补上。只有设备控制指令、计费数据才需要 QoS 2。
如果只部署单台 Broker，一旦宕机，所有设备将无法上报。生产环境应使用支持集群的 Broker（如 EMQX、VerneMQ），并配置设备端的自动重连与本地缓存，保证断网期间数据不丢失。
主题层级就是你的数据模型。如果一开始就使用
data/001/temp 这种无意义的设备 ID 结构，后续想按区域或设备类型聚合查询会非常痛苦。建议从第一天就按 企业/工厂/产线/设备类型/指标 的层级规划。
复盘一个失败案例：某智慧农业项目使用 MQTT 传输土壤墒情数据，但设备部署在地下 30cm 处，4G 信号极差，TCP 连接频繁断开重连，导致功耗飙升。最终方案改为：传感器本地存储数据，每天定时唤醒一次，通过 LoRa 发送给地面网关，再由网关通过 MQTT 转发到云端。这个案例说明，MQTT 解决的是“网络层之上”的通信问题，不能替代物理层和链路层的选型。正确的做法是：根据传输距离和功耗需求选择 LoRa/NB-IoT/BLE，再在网关侧统一转换为 MQTT 接入云端。
总结本章核心：传感器网络架构决定了数据的采集与汇聚方式，通信协议决定了数据如何高效、可靠地流动。MQTT 凭借其轻量、解耦、QoS 分级和遗嘱机制，成为物联网设备上云的首选协议，但必须结合底层链路特性与业务场景合理使用，才能真正发挥其优势。