第2章系统总体架构设计

二、系统总体架构设计：端-边-云三层架构、通信协议选型（MQTT/CoAP）、数据流设计

好，咱们直接进入正题。这一章讲的是整个系统的骨架——架构设计。说白了，就是决定传感器数据从哪来、经过谁、最终去哪里的问题。

我个人习惯，做物联网项目第一步不是写代码，而是画架构图。你想想看，如果连数据怎么流都搞不清楚，后面调试起来会非常痛苦。我在项目中遇到过好几次，因为前期架构没想清楚，后期不得不推翻重来，那叫一个折腾。

农业空气质量站，我把它拆成三层：端侧、边侧、云侧。每一层各司其职，缺一不可。

端侧，就是那些挂在田里、大棚里的传感器节点。它们负责采集原始数据，然后通过串口或无线方式传给边缘网关。嗯，这里要注意，端侧设备通常资源受限，MCU可能只有几十KB的RAM，所以数据格式一定要精简。

边侧，这是整个架构里我最看重的部分。为什么？因为农业场景网络不稳定是常态。我曾经在新疆的棉田里调试设备，4G信号时有时无，如果所有数据都直接上云，丢包率能让你崩溃。边缘网关的作用就是：先收数据、做本地处理、等网络好了再批量上传。

云侧，负责长期存储和复杂分析。比如历史趋势图、跨区域对比、AI预测模型，这些都得在云上跑。端侧和边侧算力有限，别指望它们做太复杂的事情。

我的经验之谈：三层架构不是死的。如果项目规模小，比如就几个大棚，你可以把边侧和云侧合并。但一旦超过50个节点，我强烈建议保留独立的边缘网关。否则云服务器压力会非常大，而且网络抖动时数据就全丢了。

这是物联网领域的老话题了。MQTT和CoAP，到底选哪个？我直接说结论：农业空气质量站，我选MQTT。原因有三。

第一，MQTT是长连接。 传感器数据需要持续上报，比如每5分钟一次。MQTT建立连接后一直保持，省去了反复握手的开销。CoAP虽然轻量，但它是基于UDP的请求-响应模式，每次通信都要重新协商，在频繁上报的场景下反而效率低。

第二，MQTT的QoS机制很实用。 农业数据虽然不像工业控制那么苛刻，但也不能丢。我一般用QoS 1，保证消息至少送达一次。CoAP虽然有确认机制，但实现起来比MQTT复杂，而且没有现成的Broker生态。

第三，生态成熟。 你随便找个云平台，阿里云、腾讯云、AWS IoT，都原生支持MQTT。CoAP的支持就差多了，很多平台需要自己搭网关转换。我当年在某个项目里硬要用CoAP，结果对接云平台时折腾了两周，后来换成MQTT，半天搞定。

避坑指南：如果你用的是NB-IoT模组，而且对功耗要求极其苛刻（比如电池供电用一年），那CoAP可能是更好的选择。因为NB-IoT本身带宽窄、流量贵，CoAP的UDP特性可以省流量。但大多数农业站都有市电或太阳能供电，MQTT完全够用。

数据怎么流？我画个简单的逻辑给你看。

传感器节点 → 串口/RS485 → 边缘网关 → MQTT Broker → 云平台 → 数据库 → 前端展示
                ↑                    ↓
           本地存储（SD卡）    本地决策（如超限告警）

具体来说，数据流分三个阶段：

第一阶段：端到边

传感器通过Modbus RTU协议把数据传给边缘网关。这里有个细节：传感器数据通常是原始值，比如电压、频率。边缘网关要做的第一件事就是解析和校准。比如PM2.5传感器输出的是电压值，你得根据厂家提供的公式换算成μg/m³。我见过有人直接把原始值上传到云平台，结果前端显示的全是乱码。

第二阶段：边到云

边缘网关把处理好的数据打包成JSON格式，通过MQTT发布到指定Topic。Topic命名我建议用层级结构，比如：

agri/{station_id}/{sensor_type}/{timestamp}

举个例子：

agri/STATION_001/pm25/2025-01-15T10:30:00Z

这样设计的好处是，云平台订阅时可以灵活过滤。比如你想看所有站点的PM2.5数据，直接订阅 agri/+/pm25/+ 就行。

第三阶段：云到端（下行）

有时候我们需要远程配置传感器，比如修改采集频率。这时候云平台会发布一条指令到特定Topic，边缘网关订阅后解析执行。注意，下行指令一定要有确认机制，否则你改了参数，设备没收到，那就尴尬了。

重要提醒：数据流设计时，一定要考虑断网续传。边缘网关本地要有一个环形缓冲区，比如存最近1000条数据。网络恢复后，按时间戳顺序补传。我当年在云南的茶园项目里，就是因为没做断网续传，雨季网络断了三天，数据全丢了，被客户骂得狗血淋头。

好了，这一章就讲到这里。架构设计是地基，地基不稳，后面全是空中楼阁。下一章我们聊聊具体的硬件选型，包括传感器、MCU和通信模组怎么搭配。到时候我会分享一些性价比很高的方案，都是我自己踩过坑后总结出来的。