读写器和 ERP 之间有一层没人愿意认领的东西：中间件。它每分钟接收成千上万条原始读取事件，其中大多是重复的，却必须产出少数几条财务与运营都能采信的业务事实。
架构做错，症状会伪装成硬件故障——重复的库存移动、过期的数量、乱序到达的事件，或者「平时好好的，网络一抖就崩」的通道门。
中间件到底该干什么？
五件事，其中只有第一件跟读写器通信有关。
- 设备抽象：跨厂商管理读写器、天线、功率、Session 与固件。
- 事件规范化：把厂商私有读数转成统一结构，含读写器、天线、时间戳、RSSI 与 EPC。
- 过滤与去重：把同一区域同一标签的重复读取合并成一个逻辑事件。
- 业务增强：附加库位、方向、单据或托盘上下文。
- 可靠投递：缓冲、重试、回放，让 ERP 永远看不到残缺画面。
不属于这五件事的，都是业务逻辑，属于应用层，不属于中间件。
四个层次怎么分？
可行的划分是设备层、边缘层、业务层、集成层。名字不重要，边界才重要。
- 设备层：LLRP 或厂商 SDK、读写器配置、天线清单、固件状态。
- 边缘层：部署在现场，本地缓冲，执行区域规则，扛住断网。
- 业务层：去重窗口、会话逻辑、方向推断、异常规则。
- 集成层：ERP/WMS 适配器、幂等 API、映射表、审计日志。
最常见的架构错误是把去重放在集成层。它因此跑在缓冲之后，一次回放就会产生重复的业务单据。
LLRP 在哪里有用，在哪里反而碍事？
LLRP 是读写器配置与标签上报的标准协议，多厂商环境下是正确的抽象：一个驱动、一套数据模型、一条配置路径。
但它不是万能答案。某些厂商特性——高级天线切换、读写器端过滤、自定义标签数据——只通过私有 SDK 暴露。混合设计很正常：用 LLRP 覆盖标准的那 80%，用厂商 SDK 处理特定的 20%，两者藏在同一内部接口之后。
- 配置、盘存控制与标准标签上报走 LLRP。
- LLRP 表达不了的能力走厂商 SDK。
- 绝不能让厂商 SDK 泄进业务层，必须包起来。
缓冲与离线该怎么设计？
网络会断。一个断连 30 秒的通道门，不能丢掉 500 条读取。
边缘层需要带持久化的本地队列，容量至少覆盖一个班次，并明确写清「队列满时怎么办」：丢最旧、丢最新，还是阻塞产线。阻塞产线通常不可接受，所以要显式定义，而不是等它发生。
- 持久化本地队列，静态加密。
- 容量规划：峰值每小时读取数 × 自治小时数。
- 溢出策略显式化，并有文档、有测试。
- 回放时用幂等键，避免重复创建单据。
实际用到哪些过滤与去重规则？
三条规则覆盖多数现场，而且应当可配置，而不是写死在代码里。
时间窗去重：同一 EPC 在同一区域 N 秒内只算一次。方向去重：一个 EPC 在窗口内先出现在入口天线、后出现在出口天线，就合并为一次移动，而不是两条独立读取。状态抑制：如果 ERP 中该物品已在目标库位，这条读取就是空操作。
- 窗口长度取决于流程：通道门 2–5 秒，货架扫读 30–60 秒。
- 方向推断需要天线级 RSSI 或时序，不能只看时间戳。
- 被抑制的事件要留审计，不要静默丢弃。
中间件需要哪些监控？
中间件是你最早能看到真相的地方，所以要埋点。
追踪每支天线的读取率、从读取到 ERP 落账的事件延迟、队列深度、重试次数与去重抑制比。按趋势告警，而不只是按故障告警：队列深度缓慢上升，往往是磁盘将坏或积压在增长，比宕机早好几个月。
- 每支天线的读取率与漏读率时间序列。
- 端到端延迟 p95，不是平均值。
- 队列深度与回放次数。
- 读写器固件与配置漂移。
结论
中间件存在的意义是把噪声变成事实：抽象设备、规范化事件、过滤去重、业务增强、可靠投递。把去重放在缓冲之前，把厂商代码关进接口之后，在网络来考验你之前就定义好离线行为，并把这一层埋好点——让劣化在「修起来还便宜」的时候就被看见。
