4. 边缘计算节点：边缘网关架构、树莓派/ESP32选型、边缘数据处理策略、本地缓存机制
好，咱们进入第四章。这一章聊的是边缘计算节点，说白了就是「在设备旁边干活的那个小盒子」。我在很多项目里都发现，大家容易把重心全放在云平台上，结果边缘这边一掉链子，整个系统就崩了。嗯，今天咱们就把这块掰开揉碎了讲清楚。
4.1 边缘网关架构：不只是个「转发器」
很多人觉得边缘网关就是个数据中转站，收上来数据，打包发给云端。其实远不止这么简单。我个人习惯把边缘网关看作一个「微型数据中心」，它要承担三件事：
- 协议转换：现场设备用 Modbus、CAN、MQTT、HTTP 各种协议，网关得把它们统一成内部标准格式。我在一个工厂项目里遇到过，PLC 走的是 Profinet，传感器走的是 Zigbee，网关不做好协议转换，云端根本没法处理。
- 数据预处理：原始数据又脏又乱，有缺失值、有异常跳变。网关得先做一轮清洗，比如去掉明显超出量程的数值，或者用中位数填充短暂的空缺。
- 本地决策：这是最关键的一点。当网络断了，网关能不能自己判断「温度超过 85 度就关阀门」？能的话，这就是真正的边缘智能。
核心架构图（文字版）
设备层 → 协议适配层 → 数据处理层 → 本地缓存层 → 云端同步层
每一层都有独立的模块，方便后期替换或升级。
4.2 树莓派 vs ESP32：选型不是拍脑袋
选边缘计算硬件，我见过太多人「哪个便宜用哪个」或者「哪个性能强用哪个」。其实关键看场景。我列个对比表，你一看就明白：
| 对比项 | 树莓派 4B/5 | ESP32 |
|---|---|---|
| CPU 架构 | ARM Cortex-A72（四核 1.5GHz+） | Xtensa LX6（双核 240MHz） |
| 内存 | 2GB~8GB LPDDR4 | 520KB SRAM |
| 操作系统 | Linux（Raspbian、Ubuntu） | FreeRTOS、Arduino、ESP-IDF |
| 典型功耗 | 5V/3A（约 15W） | 3.3V/0.5A（约 1.65W） |
| 适用场景 | 视频分析、复杂算法、多协议网关 | 传感器采集、简单控制、低功耗节点 |
| 成本 | 约 300~800 元 | 约 15~50 元 |
我的建议：如果你需要跑 Python 脚本、做图像识别、或者挂载多个 USB 设备，直接上树莓派。如果只是采集温度、控制继电器、跑个简单的 MQTT 客户端，ESP32 完全够用，而且省电省心。
为什么会这样？你想想看，树莓派跑的是完整 Linux，你可以装 Docker、装 Node-RED、甚至跑个轻量级数据库。但代价是功耗高、启动慢。ESP32 呢，上电 0.5 秒就开始干活了，但你要在上面跑个 OpenCV？别想了。
4.3 边缘数据处理策略：别把垃圾数据往云端送
我记得刚入行那会儿，有个项目把传感器每秒采集的数据全部上传到云端，一个月下来流量费比设备本身还贵。后来我学乖了，边缘端必须做数据筛选。常用的策略有这三种：
- 阈值过滤：数据变化不超过设定阈值，直接丢弃。比如温度波动在 ±0.5°C 以内，不记录也不上传。
- 变化率检测：如果数据变化率超过正常范围，比如温度 1 秒内跳了 10 度，那大概率是传感器故障，直接标记为异常并触发本地报警。
- 聚合计算：把 1 分钟内的 60 个数据点聚合成一个平均值、最大值、最小值。云端只需要看趋势，不需要看每个原始点。
代码示例：ESP32 上的简单阈值过滤
float last_temp = 0.0;
float threshold = 0.5;
void loop() {
float current_temp = readTemperature();
if (abs(current_temp - last_temp) > threshold) {
// 变化超过阈值，上传
mqtt_publish("sensor/temp", current_temp);
last_temp = current_temp;
}
// 否则直接忽略
delay(1000);
}嗯，这里要注意：阈值不能设得太小，否则过滤效果差；也不能设得太大，否则会漏掉重要变化。我一般建议先跑一周数据做统计分析，找到正常波动范围，再设定阈值。
4.4 本地缓存机制：断网了怎么办？
这是边缘计算里最容易被忽视的问题。网络不可能永远稳定，一旦断网，数据不能丢。本地缓存就是干这个的。我曾经在一个偏远风电场的项目里，网络经常中断 2~3 小时，如果没有本地缓存，那段时间的数据全白费了。
常用的本地缓存方案：
- SQLite：适合树莓派，轻量级关系数据库，支持 SQL 查询。断网时数据写入本地库，网络恢复后批量同步。
- 环形缓冲区（Ring Buffer）：适合 ESP32，内存有限，用固定大小的数组循环覆盖旧数据。比如保留最近 1000 条记录，满了就覆盖最旧的。
- 文件缓存：把数据按时间戳写入 CSV 或 JSON 文件，网络恢复后逐行读取上传。简单粗暴，但要注意文件大小，避免撑爆存储。
避坑指南：我曾经犯过一个错——本地缓存没有做「去重」机制。网络恢复后，缓存数据和实时数据一起上传，导致云端出现大量重复记录。后来我在每条数据里加了一个唯一 ID（UUID），云端根据 ID 做幂等处理，才彻底解决。
最后说一句，本地缓存的大小要根据你的网络中断时长来估算。如果平均断网 30 分钟，每秒产生 10 条数据，那缓存至少需要能存 18000 条记录。留出 50% 的余量，会更稳妥。
小技巧：在 ESP32 上，可以用 SPIFFS 或 LittleFS 文件系统来存储缓存数据。掉电不丢失，而且读写速度比 SD 卡快。树莓派上则推荐用 SQLite + WAL 模式，并发写入性能更好。
好了，这一章的内容就这些。边缘计算节点是整个物联网系统的「腰部」，腰杆子硬了，上面云端和下面设备才能配合好。下一章咱们聊聊更具体的——如何用 MQTT 把边缘和云端连起来。