3. 实时检测系统架构总览：端到端推理链路图、数据流、核心组件
实时可疑交易检测系统是一个典型的“流式处理 + 规则/模型混合决策”架构。本章从全局视角出发，绘制端到端推理链路，明确数据流转路径，并逐一拆解四大核心组件：采集、处理、决策、反馈。
3.1 端到端推理链路图
下图展示了从交易事件产生到最终处置动作的完整推理链路。系统采用分层解耦设计，每一层只依赖前一层输出的标准化数据，便于独立扩缩容与升级。
架构要点： 每一层通过消息队列或 RPC 解耦，采集层与处理层之间使用 Kafka 作为削峰缓冲区；决策层支持规则与模型并行评估，最终结果通过反馈层写入持久化存储并触发告警/阻断。
3.2 数据流全景
数据在系统中的流转遵循“事件入 → 特征化 → 评分 → 处置”的主线。下表按阶段列出关键数据载体与格式：
| 阶段 | 数据载体 | 典型字段（示例） | 序列化格式 |
|---|---|---|---|
| 采集 | 原始交易事件 | tx_id, user_id, amount, timestamp, merchant, device_id | Avro / Protobuf |
| 处理 | 特征向量 + 上下文 | amount_7d_sum, ip_risk_score, device_country, hour_of_day | Parquet / JSON |
| 决策 | 风险评分 + 决策标签 | risk_score (0.0~1.0), decision (approve/review/block), rule_hit_list | JSON / Thrift |
| 反馈 | 处置记录 + 审计日志 | action (alert/block/pass), operator, response_time_ms, case_id | JSON / ORC |
3.3 核心组件详解
3.3.1 采集组件（Event Collector）
- 职责： 接收来自支付网关、APP 后端、POS 终端的交易事件，完成协议适配与初步校验。
- 技术选型： 基于 Netty 的 gRPC Server + Kafka Producer；支持背压控制与重试机制。
- 关键指标： 采集吞吐量 > 50,000 TPS，P99 延迟 < 5ms。
3.3.2 处理组件（Feature Processor）
- 职责： 消费 Kafka 中的原始事件，执行实时特征计算与上下文聚合。
- 核心能力：
- 滑动窗口聚合（Flink / Kafka Streams）：计算近 1h/24h/7d 交易频次与金额。
- 外部数据关联：查询 Redis 中的用户画像、设备指纹库、IP 黑名单。
- 特征标准化与缺失值填充，输出固定维度的特征向量。
- 避坑提示： 避免在窗口内使用全局锁；优先使用状态后端（RocksDB）保证大窗口稳定性。
3.3.3 决策组件（Decision Engine）
- 职责： 接收特征向量，并行执行规则引擎与模型推理，合并输出最终决策。
- 双路决策架构：
- 规则引擎： 预置 200+ 条专家规则（如“单笔金额 > 5 万且 IP 归属高风险国家”），支持热更新。
- 模型推理： 加载 ONNX 格式的 XGBoost / LightGBM 模型，使用 GPU 或 AVX-512 指令加速。
- 合并策略： 规则命中直接输出“拦截”或“人工审核”；模型评分作为辅助排序与优先级调整。
3.3.4 反馈组件（Feedback & Audit）
- 职责： 执行决策结果（告警、阻断、放行），并将全链路日志写入数据湖用于模型迭代。
- 关键链路：
- 实时告警：通过 WebSocket 推送至风控运营平台。
- 异步回写：将特征、决策、处置结果写入 Hudi/Iceberg 表，支持 T+1 特征回溯。
- 人工标注反馈：运营人员修正误报/漏报后，触发增量训练管道。
3.4 组件协作时序与数据流图
以下 SVG 图聚焦于组件之间的数据流方向与关键交互协议，帮助理解“一条交易”在系统内部的完整旅程。
关键设计原则：
- 异步解耦： 采集与处理之间通过 Kafka 解耦，避免处理层抖动导致采集阻塞。
- 状态外置： 特征处理器依赖 Redis 存储用户画像，决策引擎无状态设计，便于水平扩展。
- 可观测性： 每个组件暴露 Prometheus 指标（吞吐量、延迟、错误率），反馈层全量日志入湖。
3.5 架构决策备忘
| 决策点 | 选型 | 理由 |
|---|---|---|
| 事件传输 | Kafka + Avro | 高吞吐、持久化、Schema 兼容演进 |
| 流处理框架 | Flink / Kafka Streams | Exactly-Once 语义、大窗口状态管理成熟 |
| 规则引擎 | 自研 DSL + Drools | 规则热更新、支持复杂条件组合 |
| 模型推理 | ONNX Runtime | 跨框架模型统一部署、GPU 加速 |
| 反馈存储 | Apache Hudi | 支持增量查询、与 Spark/Flink 集成好 |
常见陷阱：
- 采集层直接调用决策接口导致级联超时——必须引入消息队列削峰。
- 特征处理器与决策引擎共用线程池——容易互相阻塞，建议独立部署。
- 反馈层只写日志不入湖——导致模型迭代缺乏历史特征数据。