1. 项目背景与整体设计思路拆解1.1 项目代号“rea”从哪来到底解决了什么问题先说结论这个代号在我这边是Real-time Edge Analytics的缩写中文可以叫“实时边缘分析”。最初立项的时候它其实是某物联网数据平台项目里的一个子模块目标很具体——把设备端产生的数据在靠近数据源的地方直接完成处理而不是全部推到云端之后再做分析。为什么会有这个需求得从当时的业务痛点说起。当时我们手头有一套分布式的传感器网络部署在好几个现场每一路都有几十个采集点每秒都在产生时序数据。最初的架构很朴素设备上报、云端存储、云端计算听起来没什么问题。但真正跑起来之后就发现延迟和带宽这两条直接被压垮了。设备数量上去之后每秒几千条消息涌进消息队列云端要实时计算、实时告警网络稍有波动积压的数据就会让整个链路进入雪崩状态。更尴尬的是很多业务场景根本不需要把原始数据全部传到云端。比如温度突变告警、振动异常检测这些判断完全可以在边缘端完成只有异常事件才需要上报。rea 的核心思路就是这样在边缘侧完成数据的采集、清洗、规则判定和轻量级分析云端只接收浓缩后的结果和少量原始采样。你可以把它理解成一个“前置大脑”把以前集中在后台的思考能力下沉到了每一个采集节点所在的位置。这个方案适合谁来参考我的答案是凡是遇到设备数据量大、实时性要求高、网络环境不稳定这三件事里任意两件的团队都可以从 rea 这类边缘分析架构里找到答案。尤其是手上有几十台甚至几百台边缘设备、又不想给云端加一堆昂贵算力的朋友这套思路的性价比非常可观。1.2 为什么不是“全部上云”边缘端到底承担什么角色很多人一听到边缘分析第一反应是“是不是为了蹭物联网概念”。我在实际做过之后看法非常明确边缘端不是云端计算的替代品而是过滤器、前置判断器和应急兜底者。这三重身份决定了它的职责边界。先说过滤器。一套传感器网络里真正值得长期保存的数据可能不到总量的百分之五。温度曲线在正常情况下几乎是一条直线振动信号在设备健康时也只是一段低频噪声。边缘节点要做的事情就是把这些“没有信息量”的数据原地消化掉只保留变化趋势的摘要和发生异常的片段。举个例子一个采集点每秒钟上报 100 个数据点如果全部上传一天就是 864 万条记录但如果在边缘端用滑动窗口做特征提取每 10 秒只上报窗口内的均值、方差、最大值和最小值一天的数据量骤降到 86400 条而且关键信息一点没丢。再说前置判断器。很多业务告警比如温度超过阈值、压力异常跳变、设备离线心跳丢失根本不需要复杂的机器学习模型几条规则加几个阈值就能覆盖百分之八十的场景。把这些规则直接写在边缘端就可以做到从数据产生到告警触发全程不需要经过网络链路。我实测过同一套规则在云端执行的话端到端延迟在 1.2 秒到 3 秒之间波动放到边缘端执行后延迟直接降到 80 毫秒以内。这个差距在产线停工、设备保护这类场景里就是天壤之别。最后是应急兜底者。网络总会抖链路总会断。如果设备的数据采集逻辑完全依赖云端下发指令一旦断网整个节点就变成瞎子。rea 的边缘端内置了一套本地缓存和降级策略断网期间所有数据先落盘网络恢复后按照时间戳补齐上传同时在断网期间仍然持续执行本地规则判定该告警告警该记录记录。等到云端恢复通信时它看到的不是一片空白而是完整的时间线。三个角色合在一起你会发现边缘端并不是在抢云端的饭碗而是在帮云端挡掉 95% 的无用功。云端可以把算力集中在真正需要深度学习模型、全局数据关联分析的场景上比如跨站点趋势预测、设备生命周期建模。这套分工在成本上的收益也很直接带宽费用下降、云端存储量下降、消息队列压力下降而边缘端只需要一块性能很普通的 ARM 开发板就能扛住。2. 核心技术原理与关键参数设计2.1 实时数据流水线的“采集-判断-上报”三层结构rea 在边缘端的数据处理逻辑被我设计成了三条流水线采集层、判断层、上报层。每一层各干各的事互不阻塞这也是整个项目延迟能压得住的根本原因。采集层是入口负责从传感器硬件上读数据。这里有个关键选择轮询还是中断。传统单片机上习惯用定时器轮询每隔固定时间去读一次寄存器。但传感器数量多、采样频率高的时候轮询会让 CPU 忙得团团转。rea 实际采用的是“中断 DMA”的组合方式传感器数据就绪后主动触发中断DMA 直接把数据搬到内存缓冲区CPU 只在缓冲区满的时候才介入处理。这样 CPU 的大部分时间都留给判断层去跑逻辑而不是浪费在等待数据上。判断层是整个 rea 的灵魂。它由两块组成一块是基于规则的快速通道另一块是基于轻量模型的慢速通道。快速通道处理的是那种明确到不需要思考的判断比如“温度大于 85 度就告警”“连续三次采集值变化率超过 20% 就触发突变标记”。这些规则用 C 语言实现执行一次只需要几十微秒一个普通的四核处理器能轻松扛住每秒数千次触发。慢速通道是给异常检测用的跑一个极简的一维卷积神经网络输入最近 64 个采样点的归一化数值输出一个异常分数。这个模型经过压缩后只有 8KB在 ARM Cortex-A53 上推理一次约 12 毫秒不会阻塞快速通道的执行。上报层负责决定“什么数据值得让云端知道”。默认策略是三种数据必须上报触发告警的事件数据、慢速通道判定为异常的时间窗数据、以及每个统计周期的摘要数据。其余原始数据只在本地环形缓冲区里保留最近 5 分钟超时自动覆盖。这个设计非常关键因为它保证了边缘端的存储占用是固定的不会因为长期运行把磁盘撑爆。我特意把三层设计成互相解耦的独立模块每层之间通过无锁环形队列传递数据。这样做的好处是如果判断层的某个模型推理卡住了采集层不会跟着停摆数据照样进缓冲区上报层也不会因为网络阻塞而拖慢判断层的执行。整个系统的吞吐量取决于最慢的那一层但在实际压测中三层之间几乎没有互相拖累的情况。2.2 边缘端轻量模型的选择为什么不用现成的深度学习框架这个项目里最折腾的部分其实是边缘端那个异常检测模型。一开始我试过直接在设备上跑一个常规的深度学习框架毕竟训练好的模型文件喂进去就能推理省事。结果一跑起来傻眼了框架本身的依赖库就得占用上百兆内存启动时间三四秒推理一张数据窗口需要几百毫秒。这种表现在开发板上跑一个还行跑十个节点就卡得没法看而且每次更新模型都要重新配一轮依赖环境。rea 最终走的路子是在开发机用常规框架训练模型导出为通用格式之后部署到边缘端时用一个自研的极简推理器加载执行。推理器只有两个文件一个负责读模型结构一个负责执行张量运算全部代码加起来不到 1000 行静态编译后体积只有 300KB。它不支持训练只支持前向推理算子也只实现了卷积、池化、全连接、ReLU 这几个最常用的但对我们这种场景完全够用。这个选择背后的逻辑说白了就是“杀鸡不用牛刀”。边缘端设备的运算能力本来就有限跑一个 Python 解释器都是负担再去拖一个完整框架简直是灾难。推理器想明白之后我把模型量化成 int8 精度参数量从浮点版的 32KB 压到 8KB推理速度反而比浮点版还快了将近三倍。量化的代价是精度有轻微损失但我们在异常检测场景里用召回率指标算了一下从 0.96 掉到 0.94完全在容忍范围内。如果你也要做类似的边缘推理我的建议是能用规则解决的不要上模型能用简单模型解决的不要上复杂框架。边缘端的每一字节资源都是宝贵的为了省事引入冗重的依赖后面每次升级、迭代、部署都会让你想把当时的自己打一顿。2.3 断网续传、时钟同步和数据压缩的细节处理分布式系统最容易被忽视的三件小事在 rea 里反而花了很多精力断网续传、时钟同步和数据压缩。断网续传的核心是“本地可靠存储 增量游标”。边缘端每产生一条待上报的数据先写入本地的 SQLite 数据库写入成功后才算“数据已生成”。上报线程从一个游标位置开始往外发数据每发成功一批就更新游标。网络断开的时候上报线程进入等待状态但采集和判断不会停数据继续落库。网络恢复后上报线程从游标位置继续发直到追平最新数据。这套机制实现起来不难难在游标更新和数据库事务的一致性——我踩过的坑是如果先更新游标再删数据库记录一旦进程在两步之间崩溃重启后游标往前跳了一段中间的数据就永久丢了。正确做法是先标记后删除或者干脆保留所有已上报记录并定期清理确保任何时候都能从已知位置重新推送。时钟同步的问题在于边缘节点分布在不同现场各自系统时间可能有几十秒的偏差。如果数据都要带到云端做时间对齐那么偏差会直接导致时序分析结果失真。rea 的解决方式很土但很有效——所有边缘节点以一个基准时间服务器为准每隔 1 小时做一次时钟校准偏移量超过 500 毫秒就触发一次立即校准。同时每条数据上报时带上本地时间戳云端根据设备 ID 对应的时间偏移再做一次补偿。实测下来各节点之间的时间偏差可以控制在 20 毫秒以内完全满足聚合分析的精度需求。数据压缩反而是最简单的一环。时序数据本身有很强的时间相关性相邻采样点的差值通常很小。rea 用了一个非常基础的差分编码加 Varint 压缩原始数据压缩比大约能到 12:1也就是说本来要传 1MB 的数据压缩后只有 80KB 左右。这个方案比上无损压缩算法库更轻量解码时边缘端做一层还原就直接交给云端了耗时几乎可以忽略。3. 实操过程与核心环节实现3.1 开发环境搭建与边缘端工程结构规划正式开始写代码之前先讲一下我这边最终敲定的开发环境边缘端程序跑在一款基于 ARM Cortex-A53 的开发板上操作系统用的精简版 Linux没有显示环境一切通过 SSH 远程操作。开发过程中交叉编译链用的是标准 ARM GCC 工具链。为什么不用在板子上直接编译原因很简单板子的 CPU 性能太弱了编译一个稍微大点的工程可能要等三五分钟而交叉编译在开发机上几秒钟就搞定了开发体验完全不同。云端程序这边是跑在一台普通的虚拟机上的用的技术栈是 Python FastAPI SQLite只负责接收边缘端上报的数据、提供查询接口和展示仪表盘。用什么框架其实不重要重要的是接口协议要提前设计好避免后面边缘端和云端各自改需求导致联调痛苦。工程结构我建议这样规划edge/边缘端主程序包含 main.c、sensor_reader.c、rule_engine.c、network_uploader.c 等模块edge/model/存放量化后的模型文件和模型结构描述文件cloud/云端接收服务包含接收接口、数据入库模块、查询 APIweb/基于一个轻量级前端框架写的仪表盘页面tools/开发期用的模型量化工具、模拟传感器数据生成器、压测脚本这套结构的好处是边界清晰边缘端和云端是同步独立开发的联调时只需要按接口规范对接。下一节我会把边缘端主程序里几个核心的代码片段直接贴出来加上环境变量配置细节。3.2 边缘端数据采集与判断模块的代码实现先看采集模块的核心。在 rea 里采集层和判断层之间通过一个环形缓冲区通信采集线程不停地往缓冲区里写数据判断线程从缓冲区里取数据做规则判定和模型推理。// ring_buffer.h typedef struct { float *buffer; size_t head; size_t tail; size_t capacity; pthread_mutex_t lock; } ring_buffer_t; int rb_init(ring_buffer_t *rb, size_t capacity); int rb_write(ring_buffer_t *rb, float value); int rb_read(ring_buffer_t *rb, float *out);// sensor_reader.c void *sensor_reader_thread(void *arg) { ring_buffer_t *rb (ring_buffer_t *)arg; int fd open(/dev/sensor0, O_RDWR); if (fd 0) { log_error(cannot open sensor device); return NULL; } struct sensor_data sample; while (run_flag) { read(fd, sample, sizeof(sample)); rb_write(rb, sample.value); usleep(10000); // 100Hz采样 } close(fd); return NULL; }这段代码里的关键在于采样频率和缓冲区大小的匹配。假设采样频率是 100Hz判断线程每 100 毫秒处理一次数据那么缓冲区至少要能容纳 1 秒的数据才能避免丢点。在我的配置里缓冲区容量设成了 512 个点相当于 5 秒的数据量这样即使判断线程偶尔卡了一下采集线程也能继续写而不会覆盖掉还没处理的数据。如果缓冲区容量设置得太小在模型推理偶尔超时的时候就会出现数据丢失排查起来非常头疼。接下来是规则引擎的代码逻辑。规则引擎接收一个数据点根据内置的规则集决定是否触发事件。这里的一个核心设计是规则集支持热更新——边缘端从云端拉取最新规则解析后替换内存里的规则表不需要重启进程。// rule_engine.c typedef struct { char name[32]; enum { RULE_LT, RULE_GT, RULE_DIFF, RULE_CHANGE_RATE } type; float threshold; float prev_value; } rule_t; int rule_check(rule_t *rule, float value) { switch (rule-type) { case RULE_GT: return value rule-threshold; case RULE_LT: return value rule-threshold; case RULE_DIFF: return fabs(value - rule-prev_value) rule-threshold; case RULE_CHANGE_RATE: return fabs(value - rule-prev_value) / rule-prev_value rule-threshold; } return 0; }这个规则引擎本身很简单但实践中有几个细节需要特别注意。第一个是“prev_value”的更新时机我这边是在每次执行判定之后立即更新否则连续触发同一规则时会一直用旧值做对比。第二个是阈值设置不能只设一个固定值最好支持“迟滞区间”——也就是触发告警的阈值和解除告警的阈值不同避免温度在临界点上下波动时告警不停地开关。第三是规则的优先级多条规则同时命中时需要有明确的先后顺序比如设备保护动作的规则必须优先于普通的超限告警。3.3 上报模块与云端接收接口的联调实录上报模块承担的任务是把判定层产出的数据可靠地送到云端。这里我用了 HTTP 作为传输层协议每个批次打包 32 条数据POST 到一个固定的接收端点。为什么用 HTTP 而不是 MQTT 这类物联网协议主要原因是部署简单云端不需要搭建额外的消息中间件而且 HTTP 的响应码天然承载了成功/失败的语义方便做主从确认和重试逻辑。上报模块的核心代码// edge/network_uploader.py (边缘端的上报线程实际是 C 实现这里用 Python 示意) import json import sqlite3 import requests UPLOAD_URL http://cloud.example.internal:8080/api/batch def upload_batch(): conn sqlite3.connect(/var/lib/rea/edge_store.db) cursor conn.cursor() cursor.execute(SELECT seq, payload FROM pending_uploads ORDER BY seq LIMIT 32) rows cursor.fetchall() if not rows: return payload [json.loads(r[1]) for r in rows] try: resp requests.post(UPLOAD_URL, jsonpayload, timeout5) if resp.status_code 200: for seq, _ in rows: cursor.execute(DELETE FROM pending_uploads WHERE seq?, (seq,)) elif resp.status_code 400: # 数据格式错误直接丢弃并记录日志避免死循环 for seq, _ in rows: cursor.execute(DELETE FROM pending_uploads WHERE seq?, (seq,)) log_error(payload rejected by server) except requests.exceptions.RequestException: # 网络异常保留数据等待下次重试 log_warning(network error, batch retained) finally: conn.commit() conn.close()这段逻辑里有几个值得说的点。删除已上报数据必须放在收到 200 响应之后这是保证不丢数据的底线。收到 400 响应时说明数据本身有问题继续重试只会让日志被刷爆所以选择直接丢弃并记录日志。网络异常时不删除本地记录让下一轮循环重新尝试。云端接收接口的实现就比较简单了核心是把上报的批次数据写入数据库同时返回当前云端时间边缘端可以用它做时间偏移校正。这个接口设计成了幂等的也就是同一批数据重复提交不会产生重复记录靠的是前端生成的一个批次 ID云端据此去重。这在边缘端网络抖动导致的重试场景里非常重要否则一个批次因为超时被重发云端就会收到两条一样的记录。3.4 模型训练、量化与边缘部署的完整流程这一节说说 rea 里最关键也最容易出错的部分把训练好的模型从开发机搬到边缘板子上的完整链路。训练阶段我用的是一个常规的开源深度学习框架数据集来自边缘端本地采集的历史数据按 7:2:1 划分训练集、验证集和测试集。模型结构选了一维卷积加全连接大概长这样import torch.nn as nn class AnomalyDetector(nn.Module): def __init__(self): super().__init__() self.conv1 nn.Conv1d(1, 8, kernel_size3, stride1, padding1) self.conv2 nn.Conv1d(8, 16, kernel_size3, stride2, padding1) self.fc nn.Linear(16 * 16, 32) self.out nn.Linear(32, 1) def forward(self, x): x torch.relu(self.conv1(x)) x torch.relu(self.conv2(x)) x x.view(-1, 16 * 16) x torch.relu(self.fc(x)) return torch.sigmoid(self.out(x))输入是 64 个连续采样点的窗口输出是异常概率大于 0.5 就判定为异常。训练过程没什么特殊技巧就是普通的监督分类正负样本比例拉平到 1:1防止模型全都预测成正常。训练完成后模型导出为通用格式然后做两件事第一件是算子融合把卷积层与激活函数合并成一个算子这样可以减少边缘端推理时的函数调用开销第二件是 int8 量化把权重和激活值从浮点数映射到 8 位整数模型体积缩小到原来的四分之一推理速度提高近三倍。量化的关键参数是校准数据集我从训练集里随机抽了 1000 个样本统计每层激活值的分布区间把这个区间作为量化的缩放因子。如果校准数据选得太少或者分布和真实分布差距大量化后的精度会明显恶化。部署时把量化后的模型文件和自研推理器的静态编译产物一起放到边缘板子上用一份配置文件指定模型路径、输入张量格式和输出张量格式。实测下来模型加载耗时约 30 毫秒单次推理约 12 毫秒完全满足每 200 毫秒一次的异常检测频率。4. 常见问题与排查技巧实录4.1 边缘端 CPU 莫名飙高最后发现是缓冲区锁竞争第一次把 rea 完整跑起来的时候我发现边缘板的 CPU 占用率一直居高不下四个核里有一个始终在 99% 左右。一开始怀疑是模型推理太慢但单独测了一下推理耗时只有十几毫秒不应该造成这种持续占用。后来用性能分析工具一看问题出在环形缓冲区的锁竞争上。采集线程每写一个点就要加锁解锁一次判断线程每读一个点也要加锁解锁一次两块锁在来回切换中把 CPU 时间全消耗掉了。缓冲区在绝大多数情况下不会真正冲突用锁完全是过度设计。解决方式是换成无锁环形缓冲区利用原子操作来协调生产者消费者的指针移动。改动很小但性能提升非常明显CPU 占用率直接从 99% 降到了 8% 以内。这个教训告诉我们在边缘端这种每毫秒都要计较算力的环境中锁的粒度设计要非常谨慎能用无锁结构的就不要偷懒上锁。4.2 数据重复和乱序来自云端幂等设计缺失与本地游标管理失误数据重复的问题是在联调阶段被发现的。当时云端数据库里出现了大量主键冲突的记录排查下来发现是两个原因叠加导致的。第一个原因是边缘端的重试机制。网络超时之后上报线程会重新发送同一个批次的数据如果第一批次其实已经到达云端只是响应在回程途中丢了云端就会收到重复数据。这个问题的解法我在前面已经提到就是给每个批次分配一个唯一 ID云端这个 ID 去重。但如果云端表结构一开始没设计唯一索引去重逻辑写得再优雅也没用。第二个原因是本地的游标管理。我的初版上传逻辑是“先更新游标再删除已上报记录”后来发现进程崩溃后游标位置跳变导致部分记录永远不会被重新上传而另一部分记录因为删除语句执行不完整而重复上传。正确做法是先标记后删除或者干脆只在内存中维护游标位置数据库里保留所有记录定期清理已被确认的数据确保任何时刻都能从已知位置重新推送。乱序问题则是另一个维度。早期我在边缘端本地上报时按时间戳排序但网络传输存在乱序的可能导致云端收到的数据时间戳序列是不连续的。后来我在云端入库时增加了一个“乱序缓冲区”按设备 ID 和时间戳做排序后再批量写入。缓冲区的大小设置为 2 倍最大网络延迟时间实测下来排序后的数据完全可以满足后续时序分析的需求。4.3 断网恢复后大量数据积压导致云端缓冲溢出这个坑是在一次网络故障演练中暴露的。当时我手动把某一路边缘节点的网络断开了一个小时断网期间本地 SQLite 正常搜集数据大概攒了几万条记录。恢复联网后上报线程立刻全速往外推数据云端接收接口被瞬间打满消息积压到处理不过来最后反而触发了云端的自我保护机制把部分请求直接拒掉了。问题的本质是断网积累的数据是一大块“波峰”瞬间冲击力远远超过任何时间点的平均流量。解决方式是为上报线程加入限速控制恢复联网时先以一个较低的速率发送比如每秒 200 条随后按一个逐步递增的斜率爬升到正常速率。这样做的代价是追平积压数据需要更长的时间但换来的好处是云端始终在可承受的压力范围内运行不会因为一次性大量数据冲击而崩溃。另一个辅助措施是在云端接收接口和数据库之间加一层内存队列让接收接口只负责把数据快速写入队列即可返回实际入库动作由后端消费者线程慢慢消化。这样即使边缘端突发流量接收接口也不会被拖垮压力会被削峰填谷地分散到更长的时间窗口里。4.4 常见问题速查表症状、原因与处理症状常见原因处理方式边缘端 CPU 持续 100%采集与判断模块锁竞争严重用无锁环形缓冲替代互斥锁云端收到重复数据上报重试机制与云端幂等设计缺失批次唯一 ID 云端唯一索引去重断网恢复后云端被打爆积压数据集中冲击接收接口上报限速 云端内存队列削峰数据时间戳乱序网络传输乱序无乱序缓冲区云端按设备 ID 和时间戳缓冲排序进程崩溃后丢失部分数据游标更新和记录删除顺序错误先标记后删除或维护独立游标表模型量化后精度下降明显校准数据集太少或分布偏差大扩大校准集尽量贴近真实分布设备离线时无法本地告警判断逻辑依赖云端下发指令规则引擎完全跑在边缘端这张表是我在实际项目排障中总结出来的很多问题在开发环境根本不复现只有到了现场、网络一抖、设备一多才会冒出来。排障的核心原则是先看数据链路哪一环断了再去看对应模块的日志最后才是改代码。绝大多数分布式问题都不是逻辑写错了而是边界条件没处理好。5. 性能调优思路与项目扩展方向5.1 实测压测数据什么样的配置扛住了什么样的压力项目跑稳定之后我做了一轮完整的压测拿到的数据挺能说明问题。边缘板子的配置是四核 ARM Cortex-A53、内存 1GB、存储 16GB 的入门级开发板采集频率 100Hz规则引擎 20 条规则模型推理每 200 毫秒一次。在这种配置下单板处理能力大约能覆盖 50 个传感器采集点CPU 占用率稳定在 30% 以下内存占用约 180MB绝大部分被本地缓冲区、规则引擎和推理器瓜分。网络上报部分云端虚拟机的配置是 4 核 8GB接收接口单机实测能扛住每秒 2000 个上报批次也就是每秒约 64000 条数据记录。如果再往上压数据库写入就会成为瓶颈这时需要把 SQLite 换成真正支持并发写入的数据库系统或者用批量写入加异步刷盘来缓解压力。压测中我发现一个有意思的规律边缘端的性能瓶颈从来不在 CPU 算力上而是在 I/O 和锁竞争上。把传感器读取改为 DMA 模式、把数据读写改为无锁队列之后性能直接翻倍。如果你也在做类似的边缘系统我强烈建议先把这两块优化到位再考虑要不要换更强的处理器。5.2 从 rea 延伸出去这套架构还能用到哪些场景rea 虽然是为传感器数据分析设计的但核心思路“边缘预处理 云端深度分析”在很多领域都能复用。一个是视频接入场景。现在很多摄像头都在做本地运动检测和人形识别目的就是只上传有异常的片段而不是把 7x24 小时的视频流全部推回服务器。这和 rea 的做法如出一辙——本地先判断再把有价值的结果传到云端。另一个是车间设备预测性维护。振动传感器、电流传感器、温度传感器组成的数据采集网络完全可以把 rea 的规则引擎换成故障特征提取逻辑把边缘端变成设备健康状态的“随身医生”只有在指标异常时才唤醒云端做深度诊断。还有智能楼宇的能耗管理场景。每个楼层部署一个 rea 边缘节点采集电表、水表、温湿度数据本地做能耗基线统计超过阈值才触发告警。云端只负责汇总各个楼层的摘要数据做跨楼宇的对比分析。这种架构部署灵活、成本低而且不依赖专线网络。如果你手里有类似的分布式数据采集需求我的建议是先把边缘端的职责边界划清楚哪些数据要在本地处理、哪些必须上传再做技术选型和开发。rea 的实际经验证明想清楚这个问题比一开始就纠结用哪个框架、哪块开发板重要得多。这个项目后续如果要继续演进我比较看好三个方向一是把规则引擎做成配置化界面让现场维护人员不用改代码就能调整阈值二是把边缘端模型更新做成在线热更新不需要人工到现场刷固件三是给云端加一套完整的监控告警体系自动发现边缘节点离线、数据断流等异常状态。每个方向改造起来都不难但实际价值都很直接。
