2. 系统总体架构设计：端侧拍照上传 → 云端OCR引擎 → 结构化字段提取 → 规则引擎校验 → 阈值联动告警 → 运维Dashboard
本章聚焦于《签收证明OCR识别与异常告警阈值联动调优工程案例》的整体技术链路。系统采用端-云-管-控四层架构，将物理签收单据的影像数据，经过OCR识别、字段提取、规则校验与阈值联动，最终在运维Dashboard上呈现可观测的告警与性能指标。以下为系统总体架构的SVG流程图，清晰展示六大核心环节的串联关系。
架构设计原则： 高内聚低耦合、异步非阻塞、可水平扩展、告警阈值可动态调优。
2.1 核心模块职责与数据流
系统共包含6个核心模块，每个模块承担独立的职责，并通过标准化的数据接口进行交互。下表详细列出各模块的输入、输出、关键技术选型与性能目标。
| 模块名称 | 输入 | 输出 | 关键技术 | 性能目标 |
|---|---|---|---|---|
| 端侧拍照上传 | 物理签收单据 | JPEG/PNG 压缩图片 | Camera2 API、图像压缩、分片上传 | 单张上传 < 3s |
| 云端OCR引擎 | 图片字节流 | OCR原始文本 + 置信度 | PaddleOCR / Tesseract / 自研模型 | 单张识别 < 2s |
| 结构化字段提取 | OCR原始文本 | JSON 结构化字段 | 正则 + NER + 规则模板 | 字段准确率 > 95% |
| 规则引擎校验 | 结构化字段 | 校验通过/失败 + 异常码 | Drools / EasyRules / 自研DSL | 单条校验 < 50ms |
| 阈值联动告警 | 校验结果 + 历史指标 | 告警事件 + 阈值调整建议 | 动态阈值算法、分级告警策略 | 告警延迟 < 5s |
| 运维Dashboard | 告警事件 + 性能指标 | 可视化面板 + 报表 | Grafana / Prometheus / 自研 | 页面加载 < 2s |
架构避坑提示： 端侧上传模块务必实现断点续传与图片自动压缩（建议压缩至 720p 以内），避免弱网环境下上传超时或云端OOM。云端OCR引擎建议采用异步任务队列（如 RabbitMQ / Kafka）削峰填谷，防止突发流量打垮识别服务。
2.2 数据流与异常处理路径
系统数据流采用串行+并行混合模式：端侧→云端→提取→校验为串行链路；校验结果同时进入告警模块与Dashboard展示模块，形成并行分支。当任意环节发生异常时，系统需具备完善的降级与重试机制。
2.3 技术选型对比与决策依据
在架构设计阶段，我们对核心模块的关键技术进行了多方案对比，最终选型基于性能、成本、可维护性、社区生态四个维度。下表展示OCR引擎与规则引擎的选型对比。
| 模块 | 候选方案 | 优势 | 劣势 | 最终选型 |
|---|---|---|---|---|
| OCR引擎 | PaddleOCR | 中文识别率高、轻量、支持端侧部署 | 复杂表格识别较弱 | PaddleOCR + 自研表格模型 |
| Tesseract 5.x | 开源成熟、多语言支持 | 中文识别精度低于PaddleOCR | ||
| 云服务（百度/阿里） | 开箱即用、准确率高 | 成本高、数据安全风险 | ||
| 规则引擎 | Drools | 功能强大、支持复杂规则 | 学习曲线陡、内存占用高 | 自研轻量DSL引擎 |
| EasyRules | 轻量、Java生态友好 | 不支持规则动态热加载 | ||
| 自研DSL引擎 | 定制化强、热加载、低延迟 | 需要自行维护解析器 |
架构决策警告： 规则引擎不建议直接使用Drools处理高并发OCR校验场景（QPS > 1000），其内存占用与规则编译开销会显著增加GC压力。本案例采用自研DSL引擎 + 预编译规则缓存方案，单条校验耗时稳定在5ms以内。
2.4 架构部署拓扑与关键指标
系统采用Kubernetes容器化部署，各模块独立微服务化，通过Service Mesh进行服务间通信。以下为部署拓扑的关键配置与性能指标基线。
- 端侧服务： Nginx + Lua 做上传网关，支持水平扩展，单节点承载 500 QPS。
- OCR引擎服务： GPU节点（NVIDIA T4），每个Pod部署1个模型实例，支持批处理（batch=4），单节点吞吐 20 QPS。
- 字段提取服务： CPU节点，无状态，单节点吞吐 200 QPS。
- 规则引擎服务： CPU节点，预编译规则缓存，单节点吞吐 1000 QPS。
- 告警服务： 基于Prometheus + AlertManager，阈值动态更新周期 30s。
- Dashboard： Grafana + 自研API，数据源为Prometheus + Elasticsearch。