第2章：系统总体架构设计
好，咱们直接进入正题。这一章我打算聊聊整个洪水预警终端的骨架——四层架构。你想想看，一个设备要从田里采集数据，再传到云端，最后在手机上报警，这中间得经过多少环节？四层架构就是把这些环节理清楚。
2.1 感知层：最底层的“触手”
感知层说白了就是传感器那一堆东西。我习惯把它比作人的五官——你得先“看到”水位、“摸到”雨量，才能做判断。
具体到咱们这个项目，感知层包含这些硬件：
- 水位传感器：超声波或压力式，精度要求±1cm
- 雨量传感器：翻斗式，每0.5mm翻一次
- 土壤湿度传感器：电容式，防腐蚀设计
- 温湿度传感器：SHT30，用于环境补偿
嗯，这里要注意。传感器选型有个坑——功耗。我曾经在项目里用了某款进口水位计，精度确实高，但待机电流20mA，电池撑不过一周。后来换成国产的，精度差0.5mm，功耗却只有2mA。你想想看，野外部署，电池更换成本比传感器本身还贵。
2.2 网络层：数据怎么传上去？
感知层采集了数据，接下来就是网络层的事。这里的选择其实不多，主要看现场条件。
| 通信方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 4G Cat.1 | 覆盖广，速率高 | 功耗大，需SIM卡 | 有信号覆盖的农田 |
| LoRa | 低功耗，远距离 | 需自建网关 | 偏远无信号区 |
| NB-IoT | 窄带，省电 | 速率低，时延高 | 低频率上报场景 |
我个人习惯优先选4G Cat.1。为什么？因为现在运营商基站覆盖已经很好了，而且模组价格降到了20块以内。LoRa虽然省电，但你得自己搭网关，维护成本不低。我在广西一个项目里试过LoRa，结果网关被雷劈了两次，后来全换成4G了。
数据格式方面，我推荐用JSON。别用二进制协议，调试起来太痛苦。举个例子：
{
"device_id": "FL-2024-001",
"timestamp": "2024-06-15T08:30:00Z",
"sensors": {
"water_level": 2.35,
"rainfall": 12.5,
"soil_moisture": 45.2,
"temperature": 28.3,
"humidity": 72.1
},
"battery": 3.85,
"signal_strength": -78
}你看，字段名一看就懂。调试的时候用Postman发一条，后端能不能解析一目了然。
2.3 平台层：数据到了云端怎么办？
数据传上来了，平台层负责存储、处理、分析。这里我一般用物联网平台+时序数据库的组合。
物联网平台选型，我踩过不少坑。早期用某大厂的公有云，结果数据量一上来，费用吓死人。后来改用开源的ThingsBoard，自己搭服务器，成本可控。当然，如果你团队小，直接用云平台省心。
平台层核心功能：
- 设备管理：注册、认证、OTA升级
- 数据存储：时序数据库（InfluxDB或TDengine）
- 规则引擎：数据清洗、阈值判断
- 告警服务：触发条件、通知推送
2.4 应用层：用户看到什么？
应用层是面向用户的界面。说白了，就是让农民伯伯或者防汛人员能看懂、能操作。
我设计应用层时，遵循一个原则：三屏联动。
- 大屏：指挥中心的大屏幕，展示全局水位态势图
- 中屏：PC端管理后台，查看历史数据、导出报表
- 小屏：手机端微信小程序，接收告警、查看实时数据
手机端是最关键的。你想想看，防汛人员可能正在田里巡查，不可能打开电脑。所以小程序要做得极简——打开就看到当前水位，红色预警直接弹窗。
2.5 数据流与业务流设计
好，四层架构讲完了，咱们串起来看看数据怎么流动。
数据流（从下往上）：
传感器 → MCU采集 → 4G模组 → 物联网平台 → 时序数据库 → 应用展示每一步都有讲究。MCU采集时要做滤波，我一般用滑动平均滤波，取最近5次数据的平均值。4G模组上传时要做断线重连，信号不好时不能丢数据。
业务流（从上往下）：
用户设置阈值 → 平台下发配置 → MCU更新参数 → 传感器调整采样频率举个例子。用户觉得当前水位警戒线太低，在App上改成3.0米。平台收到后，通过MQTT下发指令给终端。终端收到后，把阈值存到Flash里，下次采样就用新值判断。
嗯，说到这，我想起一个项目。在湖南某地，我们部署了50台终端。一开始数据流设计没问题，但业务流出了岔子——用户想远程修改采样频率，从10分钟一次改成5分钟一次。结果因为没做OTA升级，只能派人去现场改。后来我学乖了，所有可配置参数都做成远程可调。
最后总结一下。四层架构不是死板的，你可以根据实际情况裁剪。比如小规模项目，平台层和应用层可以合并。但感知层和网络层是底线，不能省。数据流要保证不丢、不乱，业务流要灵活、可配置。做到这几点，你的洪水预警终端就成功了一半。