物联网概述：从概念到落地的全景图
大家好，我是你们的老朋友。今天咱们正式开讲物联网的第一课。
说实话，我做了十几年嵌入式开发，刚入行那会儿，物联网这个词还没火起来。那时候我们管这叫「嵌入式系统 + 网络通信」。后来突然有一天，老板开会说：「我们要做物联网产品了！」我心想，这不就是我们一直在干的事吗？
嗯，其实本质没变，但架构更清晰了。今天我就带你把物联网的底裤看穿。
什么是物联网？
物联网，英文叫 Internet of Things，简称 IoT。说白了，就是把物理世界里的「物」——传感器、设备、家电、机器——连到互联网上，让它们能说话、能听话、能干活。
你想想看，一个温度传感器，原来只能本地显示。连上网之后，你在手机上就能看到家里温度。再进一步，温度高了自动开空调。这就是物联网。
我个人习惯把物联网理解成「物理世界的数字化镜像」。每个设备都在产生数据，这些数据汇聚到云端，经过分析，再反过来控制设备。闭环，就这么简单。
核心三要素：
- 感知：采集数据（温度、湿度、位置、图像...）
- 传输：把数据发出去（Wi-Fi、4G、LoRa...）
- 处理：分析数据并做出决策（本地或云端）
我在项目中遇到过不少客户，上来就说「我要做个物联网系统」。我问：「具体做什么？」他说：「就是物联网啊。」——嗯，这种需求最让人头疼。所以咱们先把概念理清楚，后面才好干活。
物联网四层架构
物联网系统怎么搭？业界公认的是四层架构。我当年第一次画这个架构图的时候，是在一个智能农业项目里。客户要求监控大棚温湿度，还要自动灌溉。当时我就按这四层来拆解，思路一下子就清晰了。
1. 感知层
这是物联网的「五官」。负责采集数据和执行动作。
- 传感器：温度、湿度、光照、气压、加速度...
- 执行器：继电器、电机、阀门、蜂鸣器...
- 终端设备：MCU + 传感器 + 通信模块
说白了，感知层就是那些「长在物理世界里的触手」。我建议你在选型时，重点关注功耗和精度。尤其是电池供电的设备，功耗就是命根子。
2. 网络层
这一层负责把感知层的数据传出去。你可以把它理解成「物联网的血管」。
- 短距离通信：Wi-Fi、蓝牙、ZigBee、Z-Wave
- 长距离通信：4G/5G、NB-IoT、LoRa、Sigfox
- 有线通信：以太网、RS-485、CAN
这里有个坑，我踩过。曾经在一个项目中，我选了Wi-Fi做数据传输，结果设备部署在室外，Wi-Fi信号不稳定，数据经常丢包。后来换成了LoRa，问题才解决。所以选通信方式时，一定要考虑现场环境。
3. 平台层
平台层是物联网的「大脑」。它负责数据存储、设备管理、规则引擎。
- 设备管理：注册、认证、OTA升级
- 数据存储：时序数据库（如InfluxDB）、关系型数据库
- 规则引擎：条件触发、告警、自动化
我个人习惯用云平台来搭建这一层。阿里云IoT、华为云IoT、AWS IoT，都挺好用。如果你做小项目，也可以用开源的ThingsBoard或者Node-RED。
4. 应用层
这是用户直接看到的部分。手机App、网页仪表盘、大屏展示。
- 可视化：实时数据展示、历史曲线
- 控制：远程开关、参数设置
- 分析：数据报表、趋势预测
应用层其实是最容易出彩的。我见过一个做智能水表的项目，应用层做得特别漂亮，用户直接在手机上就能看到用水量、漏水告警，甚至还能预测下个月水费。客户满意度直接拉满。
我的建议：初学者做物联网项目时，先从感知层和网络层入手。买一块ESP32开发板，接个DHT11温湿度传感器，数据通过Wi-Fi传到云平台，再用手机App查看。这一套走下来，四层架构你就全体验到了。
常见物联网协议对比
协议这东西，说白了就是设备之间「怎么说话」。我刚开始做物联网时，面对一堆协议头都大了。后来发现，其实常用的就三个：MQTT、CoAP、HTTP。
咱们直接上表格对比，一目了然。
| 特性 | MQTT | CoAP | HTTP |
|---|---|---|---|
| 传输层 | TCP | UDP | TCP |
| 通信模型 | 发布/订阅 | 请求/响应 | 请求/响应 |
| 报文大小 | 小（2字节最小头） | 极小（4字节） | 大（通常几百字节） |
| 功耗 | 低 | 极低 | 高 |
| 可靠性 | 高（QoS 0/1/2） | 低（可配置确认） | 高 |
| 适用场景 | 传感器数据上报、远程控制 | 资源受限设备、低功耗场景 | Web应用、RESTful API |
| 典型端口 | 1883（非加密）/ 8883（加密） | 5683 | 80 / 443 |
MQTT：物联网的「老大哥」
MQTT是我用得最多的协议。为什么？因为它简单、可靠、省流量。
它的核心是「发布/订阅」模式。设备发布消息到某个主题，其他设备订阅这个主题就能收到消息。有点像微信群——你发一条消息，群里所有人都能看到。
举个例子，一个温度传感器每隔5秒发布一次温度到 sensor/temperature 这个主题。你的手机App订阅了这个主题，就能实时收到温度数据。反过来，你想控制一个灯，就发布一条消息到 device/light/control，灯那边订阅了这个主题，收到消息就执行开关动作。
MQTT的三个服务质量等级：
- QoS 0：最多发一次，丢了不管。适合温度上报这种丢了也无所谓的场景。
- QoS 1：至少发一次，可能重复。适合控制指令，丢了不行，重复了也没事。
- QoS 2：恰好发一次，最可靠。适合计费、告警这种必须精确的场景。
我在项目中一般用QoS 1做控制，QoS 0做数据上报。QoS 2很少用，因为开销大，而且大部分场景不需要那么精确。
CoAP：为「省电」而生
CoAP是基于UDP的协议，报文非常小。它专门为资源受限的设备设计——比如一个用纽扣电池供电的传感器，几年不换电池那种。
CoAP的通信模型和HTTP很像，也是请求/响应。但它做了很多优化：
- 报文头只有4字节
- 支持观察模式（类似订阅）
- 内置资源发现
我曾经在一个智能路灯项目里用过CoAP。每个路灯上有一个低功耗MCU，通过CoAP上报状态。因为报文小，电池撑了两年多。如果用HTTP，估计半年就得换电池。
注意：CoAP基于UDP，所以可靠性不如MQTT。如果你的网络环境很差，丢包率高，CoAP可能不太合适。我建议在局域网或者信号稳定的场景下使用CoAP。
HTTP：老熟人，但不适合物联网
HTTP大家都很熟悉了，Web开发的基础。但说实话，HTTP在物联网里不太吃香。
为什么？
- 报文太大，一个请求头就几百字节
- 基于TCP，三次握手四次挥手，功耗高
- 只能请求/响应，不能主动推送
不过HTTP也有它的用武之地。比如设备配置页面、固件下载、与第三方API对接。我一般只在设备初始化或者需要和Web服务交互时才用HTTP。
选型建议：
- 如果你做智能家居、工业监控、车联网 → 选MQTT
- 如果你做低功耗传感器、电池供电设备 → 选CoAP
- 如果你做设备配置页面、与Web服务对接 → 选HTTP
小结
今天咱们把物联网的底子打了一遍。从概念到四层架构，再到三个核心协议。你想想看，这些东西其实都不复杂，关键是要理解它们「为什么存在」。
物联网的本质，就是让物理世界和数字世界对话。感知层负责「听」和「说」，网络层负责「传话」，平台层负责「记」和「想」，应用层负责「展示」和「控制」。而协议，就是它们之间约定的「语言」。
下一章，咱们会深入MCU选型。我会告诉你，面对市面上几百种MCU，到底该怎么选。嗯，这里先卖个关子——选错了MCU，项目可能直接废掉。我当年就吃过这个亏。
好了，今天就到这儿。有什么问题，欢迎在评论区留言。咱们下期见。
公众号：蓝海资料掘金营，微信 deep3321