2、智能货架系统架构：感知层、网络层、边缘层、应用层详解
好，咱们直接进入正题。智能货架这东西，听起来好像就是「货架上装个传感器」那么简单。但真正落地的时候，你会发现它其实是一个典型的物联网四层架构。我习惯把这四层拆开来看：感知层、网络层、边缘层、应用层。每一层都有它自己的脾气，也有它自己的坑。
今天我就把这四层掰开了揉碎了，跟你聊聊每层到底在干什么，以及我在实际项目中踩过的那些雷。
2.1 感知层：货架的「五官」
感知层，说白了就是货架的眼睛、耳朵和鼻子。它负责采集最原始的数据。你想想看，一个货架要感知什么？
- 重量变化：商品被拿走或放回，重量会变。
- 位置状态：商品有没有被放错位置。
- 环境参数：比如温度、湿度，生鲜货架特别需要这个。
- 用户行为：有人伸手拿了什么，停留了多久。
我在项目中遇到过最头疼的事，就是传感器选型。你以为随便买个称重传感器就行？太天真了。
感知层的核心设备包括：
- 称重传感器：建议用HX711或ADS1232这类ADC芯片，精度够用，成本可控。
- 红外/激光对射：检测商品是否在位，比称重更直接，但容易受遮挡。
- RFID读取器：适合高价值商品，但标签成本是个问题。
- 温湿度传感器：SHT30或DHT22，便宜又好用。
嗯，这里要注意：感知层的数据质量，直接决定了上层分析的准确性。如果传感器数据都是脏的，后面再怎么算也是白搭。
2.2 网络层：数据怎么「跑」出去
感知层采集了数据，接下来就得想办法传出去。网络层就是干这个的。但问题来了——货架通常部署在商场、仓库、便利店，这些地方的网络环境千差万别。
我个人习惯把网络层分成两类：
- 有线网络：稳定、可靠，但布线成本高，适合固定货架。
- 无线网络：灵活、部署快，但干扰多、功耗要控制。
无线方案里，我推荐这么选：
| 协议 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| Wi-Fi | 带宽大，通用性强 | 功耗高，连接数有限 | 大型商超，有稳定电源 |
| BLE（蓝牙低功耗） | 功耗极低，手机直连 | 传输距离短，带宽小 | 小型货架，电池供电 |
| LoRa | 距离远，穿墙能力强 | 速率低，延迟高 | 仓库、冷链等大面积场景 |
| Zigbee | 自组网，低功耗 | 生态封闭，调试麻烦 | 工业级货架系统 |
我曾经在一个连锁药店的智能货架项目中，一开始全用Wi-Fi。结果一个门店部署了50个货架，每个货架3个传感器，AP直接扛不住，丢包率飙升。后来改成了BLE Mesh组网，每个货架作为一个节点，数据汇聚到网关再走Wi-Fi上传，问题才解决。
2.3 边缘层：真正的「大脑」在这里
很多人以为智能货架的「智能」在云端。其实不然。真正的实时决策，必须发生在边缘层。
为什么？你想想看：
- 一个顾客拿起商品，系统要在毫秒级内判断「这是拿走了还是只是碰了一下」。
- 如果所有数据都上传云端，网络延迟加上处理时间，黄花菜都凉了。
- 而且，每天几万个货架产生的数据量，全传云端？带宽和存储成本你扛不住。
所以，边缘层的作用就是：在本地完成数据清洗、特征提取、甚至初步决策。
我常用的边缘计算节点配置是这样的：
硬件选型（以树莓派4B为例）：
- CPU：BCM2711，四核Cortex-A72，1.5GHz
- 内存：4GB LPDDR4
- 存储：32GB microSD（建议用工业级）
- 接口：GPIO、I2C、SPI、UART、USB、HDMI
软件栈：
- 操作系统：Raspberry Pi OS Lite（无桌面环境，省资源）
- 边缘框架：Node-RED 或 Kuiper（轻量级流处理）
- 数据存储：SQLite（本地缓存，断网不丢数据）
- 通信协议：MQTT（发布/订阅模式，省带宽）边缘层要处理的核心任务：
- 数据过滤：去掉明显异常的传感器值（比如重量突然变成负数）。
- 事件检测：判断「商品被拿走」「商品被放回」「货架空了」等事件。
- 本地缓存：网络断了怎么办？数据先存本地，等网络恢复再补传。
- 模型推理：如果部署了AI模型（比如识别商品摆放是否正确），就在边缘端跑推理。
核心观点： 边缘层不是云端的「小弟」，而是货架系统的「现场指挥官」。它要能独立运行，哪怕断网也能正常工作。
我记得有一次在客户现场调试，网络突然中断了整整两个小时。但货架系统依然正常运行，所有数据都缓存在边缘节点上。网络恢复后，数据自动补传，客户完全没察觉。这就是边缘层的价值。
2.4 应用层：数据最终「变现」的地方
前面三层都是铺垫，应用层才是真正给业务创造价值的地方。应用层通常部署在云端或本地服务器上，负责：
- 数据汇聚与存储：把所有边缘节点的数据汇总起来，形成全局视图。
- 数据分析与可视化：哪些商品卖得快？哪个货架需要补货？顾客在哪个区域停留最久？
- 业务规则引擎：比如「当货架库存低于阈值时，自动生成补货工单」。
- 远程管理与OTA升级：批量更新边缘节点的固件或算法模型。
应用层的技术选型，我一般这么搭：
后端服务：
- 微服务框架：Spring Boot 或 Go Gin（轻量、高性能）
- 消息队列：EMQX 或 RabbitMQ（处理海量设备上报）
- 数据库：时序数据库 InfluxDB（存储传感器数据）
- 业务数据库：PostgreSQL（存储商品、订单等结构化数据）
前端展示：
- 实时看板：Grafana（可视化传感器数据）
- 管理后台：Vue.js + Element UI（操作界面）这里有个容易忽略的点：应用层一定要考虑多租户隔离。如果你同时服务多个客户（比如多个连锁超市），每个客户的数据必须严格隔离。我曾经见过一个项目，因为数据库表设计时没加租户ID，结果A超市的补货数据推到了B超市的系统里，差点造成重大事故。
2.5 四层架构的协同工作
最后，我用一个实际场景把这四层串起来：
- 感知层：顾客从货架上拿走一瓶可乐，称重传感器检测到重量减少了350克。
- 网络层：传感器通过BLE将数据发送到货架上的边缘节点。
- 边缘层：边缘节点收到数据，结合历史记录，判断「这是一次正常的商品取走事件」。然后生成一条消息：
{"event": "item_taken", "sku": "COLA_350", "timestamp": 1690000000}，通过MQTT上传到云端。 - 应用层：云端收到消息后，更新库存数据库，触发补货规则引擎。如果库存低于阈值，自动生成补货任务，推送到店长的手机APP上。
整个过程，从顾客拿走可乐到店长收到补货通知，延迟不超过2秒。这就是四层架构协同工作的威力。
嗯，这一章的内容就到这里。下一章我会带你手把手搭建一个边缘计算节点的原型，从硬件接线到代码部署，咱们一步步来。