1.2 四层架构与数据流动路径

1.2 四层架构与数据流动路径

本节摘要：把"感知层、网络层、平台层、应用层"四层压实，并沿一条温度采集数据从传感器走到看板的完整路径，逐一指出每一层上发生的事故点与协议接口。承接 1.1 的演进脉络，通往 1.3 的四大约束，以及第 2 章的协议选型。

架构图纸画得再漂亮，不如让一条真实数据走一遍。本节的思路很直白：不看层的定义背了多久，要看数据在层与层之间流经哪些检查点。我们把四个层当成四道闸口，跟着一枚贴在冷链车厢里的温度计走吧。

一、四层各自负责什么

老话说分层是为了"各管一段、出了问题知道怪谁"。物联网的四层各有明确分工：

• 感知层：物理世界与数字世界的翻译官。温度计、湿度计、霍尔开关、步进电机都在这层，它只负责"量得准、动得对"，不关心数据怎么长途跋涉。
• 网络层：数据的运输队。它决定用 WiFi、蓝牙、LoRaWAN 还是蜂窝，把感知层的数据搬上公网或专网，也负责把云端指令搬回设备。这一层是后面所有协议争夺的主战场。
• 平台层：数据的集散地。消息中间件（如 MQTT Broker）、时序数据库、规则引擎都在这里，负责去重、转发、存储与轻加工。这里也是 MQTT、CoAP 这些"应用层协议"落脚的码头。
• 应用层：数据的消费端。业务看板、告警推送、下发控制台在这里，离用户最近，也最不关心底层用了几颗螺丝。

二、跟一条温度数据走完全程

下面这张接力图把"采集、承载、加工、呈现"四棒串起来，并标注了每一棒的典型协议接口：

第一步，采集（感知层）。温度计内部做模数转换，攒齐一个窗口的数据再统一上报，既省射频唤醒次数，也降低丢包后的重传成本。第二步，承载（网络层）。冷藏车厢在移动中，用 LoRaWAN 上报占比过高会挤占链路——数据帧很克制，仅仅携带设备号、读数、时间戳三要素，头部比 HTTP 动不动几百字节的报文省太多。第三步，加工（平台层）。消息中间件先查时间戳是不是旧的、同一条数据有没有重复投递，去重后落进时序库。第四步，消费（应用层）。看板订阅了对应主题，数据一到就刷新曲线，超过阈值马上推告警，并把"加压升温"指令经下行窗口送回车厢。

三、把层画成图，坑也跟着露出来

下面这张分层透视把每一层可能埋雷的位置标出来：

每层都有一个"最容易出事的检测点"：感知层怕读错单位（把华氏当摄氏），网络层怕丢帧，平台层怕重复与乱序，应用层怕丢了设备标识导致数据对不上号。架构设计的意义，就是把每个检查点都纳入协议约定。

四、一次真实演练：把错位读数拉回正轨

纸上谈兵不如排一次雷。假设看板上突然冒出一串 32 摄氏度的"异常高温"，排查顺序应当遵沿途检测点：

1. 先查应用层：单位标注是不是华氏？换算后再看是否真异常。
2. 再查平台层：同一时刻有没有两条重复记录？时间戳是不是被桥接层回拨了？
3. 后查网络层：LoRaWAN 或蓝牙传输有没有连续丢帧，导致断档被插值？
4. 最后查感知层：量程配置错没、ADC 是不是进过饱和区。

⚠️ 常见坑：多数"数据异常"并非故障，而是握手两端的单位、量纲、时区约定不一致。先把 1.2 的检测点过一遍，比急着推倒重连链路高效得多。

五、把"中间层走了什么协议"这一行填满

很多初学者把四层背成四个名词，却在"数据上一层时到底靠什么交接"上卡壳。这一行的答案恰恰是后三章的主角。我们把一条温度上报的路再拆细一点，标出每一棒交接时用到的具体协议与它的职责：

看这张交接表你会发现一个关键事实：同一套 MQTT / CoAP 往往同时承担上行汇报与下行指令两条链路，区别只在主题归属与 QoS 等级的设置上。架构设计的第一反应不该是"换一套协议跑下行"，而是"在现有协议里把下行主题与确认机制补全"。这个判断能帮你省下大量无谓的适配工作。

六、一套实操：用测试工具替四层的每一棒建桩

只看图会有"好像懂了"的错觉。要真正把四层走顺，值得动手用测试命令把每一棒单独验一遍。下面是一套不涉及具体业务、纯验证"路是否通"的探针方式（以常见的 mosquitto 为例，Windows/Linux 均有对应安装）：

# 感知层交付到网关（以 LoRaWAN 网关为例，通过串口/回传脚本落一条记录）
# 假设网关把上行帧解析后写入本地文件
echo 'sensor_12 25.6 1720000000' >> /data/inbound.log

# 网络层桥接到平台：由网关侧把记录发布到 MQTT 主题
mosquitto_pub -h broker.internal -t factory_a/temperature/sensor_12/k3 \
  -m '{"metric":"temp","value":25.6,"unit":"celsius"}'

# 平台层消费：订阅同一主题，确认一条数据到达
mosquitto_sub -h broker.internal -t 'factory_a/#'
​

按"先网关本地文件有记录 → 再主题被发布 → 最后订阅端能收到"的顺序逐步建桩，哪一步没通就聚焦在哪一层排查，把"四层协作"抽象成一个可逐步验证的过程。这样即使你不会写完整业务代码，也能配齐一套手工冒烟路径，为第 6 章讲网关桥接打下实操基础。

本节要点回顾

• 要点一：四层各管一段——感知负责采、网络负责运、平台负责集、应用负责用。
• 要点二：网络层是协议争夺的主战场，平台层是 MQTT、CoAP 之类应用层协议的落脚点。
• 要点三：数据在层间转弯处容易损耗，每层都有一个最典型的检测点。
• 要点四：排障按"应用→平台→网络→感知"逐层收敛，往往最快。
• 要点五：给数据统一单位、量纲与时间基准，是跨层协作的第一前提。

下一节把这里点到的四个检测点升级为"连接、安全、互操作、能耗"四大约束，讨论它们如何反向塑造协议设计。