2. 系统总体架构设计
本方案采用四层分层架构，将数据采集、智能处理、业务融合与终端应用解耦，确保各层可独立扩展、独立部署。整体架构遵循“高内聚、低耦合”原则，支持从快递面单图像到在途轨迹数据的端到端融合。
2.1 分层架构设计
系统自下而上划分为采集层、处理层、融合层、应用层，各层职责与核心组件如下表所示：
| 层级 | 核心职责 | 关键组件 | 输入/输出 |
|---|---|---|---|
| 采集层 | 多源数据接入与原始信号预处理 | OCR扫描终端、IoT网关、GPS/北斗定位模块、手持PDA | 输入：面单图像、运单号、GPS坐标 输出：原始图像流 + 定位事件流 |
| 处理层 | OCR识别、图像增强、结构化提取 | OCR引擎集群、图像预处理管道、字段校验模块 | 输入：原始图像 输出：结构化签收信息（收件人、时间、签章） |
| 融合层 | 多源数据关联、时空对齐、置信度评估 | 数据融合引擎、ID-Mapping模块、轨迹拼接服务 | 输入：OCR结果 + 在途事件 输出：融合后的签收-轨迹记录 |
| 应用层 | 业务可视化、异常预警、开放接口 | Web管理后台、移动端看板、API网关 | 输入：融合数据 输出：签收证明、轨迹回放、预警通知 |
架构要点： 采集层与处理层之间通过消息队列（Kafka/RocketMQ）解耦，处理层与融合层之间采用事件驱动架构，确保高吞吐场景下数据不丢失、不阻塞。
2.2 技术选型原则
技术选型遵循以下五项原则，确保系统在物流场景下的稳定性与可维护性：
- 成熟优先：核心OCR引擎、消息中间件、数据库优先选用经过大规模物流场景验证的开源或商业产品，避免引入过于前沿但稳定性不足的组件。
- 横向扩展：处理层与融合层支持无状态水平扩展，通过负载均衡器分发请求，单节点故障不影响整体服务。
- 数据一致性：融合层采用最终一致性模型，配合分布式事务补偿机制，确保签收记录与轨迹数据在异常场景下仍可对齐。
- 低延迟：OCR识别单张图片处理时间 ≤ 2秒，轨迹数据从采集到融合延迟 ≤ 5秒，满足实时在途追踪要求。
- 安全合规：面单图像脱敏存储，签收数据加密传输，满足《个人信息保护法》对物流面单信息的要求。
选型参考： 推荐OCR引擎优先考虑Tesseract 5.x + 自训练物流面单模型，或百度智能云OCR物流版；消息队列推荐RocketMQ 5.x；时序数据库推荐TDengine或InfluxDB用于轨迹存储。
2.3 系统部署拓扑图
下图展示了系统在典型物流中转场与云端的混合部署拓扑：
部署说明： 采集层设备部署于物流中转场、快递站点等边缘节点；处理层与融合层部署于私有云或混合云环境；应用层支持PC端与移动端同时访问。各层之间通过专线或VPN加密通信，保障数据传输安全。
2.4 关键数据流说明
系统内部数据流转遵循以下标准化路径：
- 图像流：采集层 → 消息队列 → 处理层（OCR识别）→ 融合层（关联运单号）→ 应用层（签收证明生成）
- 轨迹流：采集层（GPS/北斗）→ 消息队列 → 处理层（坐标清洗）→ 融合层（轨迹拼接）→ 应用层（在途追踪展示）
- 融合流：融合层将OCR签收时间与轨迹到达时间进行时空对齐，输出“签收-轨迹”关联记录，供应用层查询与预警。
注意： 当OCR识别置信度低于90%时，融合层自动触发人工复核流程，避免错误签收记录进入在途追踪链路。复核期间该运单的融合状态标记为“待确认”。