2. AML监测系统架构总览：分层架构、核心组件与数据流
实时反洗钱（AML）监测系统需要处理海量交易数据、执行复杂规则与模型推理，并在秒级内输出告警。为满足高吞吐、低延迟与可扩展性要求，生产级系统普遍采用分层解耦架构。本章从分层视角拆解系统全貌，明确各层职责、核心组件与数据流转路径。
架构设计原则： 每一层仅依赖其下层提供的抽象接口，层内组件可独立扩缩容；数据流单向向下游传递，避免循环依赖。
2.1 四层架构总览
系统自底向上划分为数据层、模型层、监测层与告警层。各层通过消息队列与API网关衔接，形成松耦合的管道式架构。
2.2 核心组件与职责
下表列出各层的关键组件及其在生产环境中的具体职责：
| 架构层 | 核心组件 | 职责说明 | 技术选型示例 |
|---|---|---|---|
| 数据层 | 消息总线 | 接收交易流水、客户变更、外部黑名单等实时事件 | Kafka / Pulsar |
| 流处理引擎 | 数据清洗、格式转换、字段补齐、时间窗口对齐 | Flink / Spark Streaming | |
| 数据湖 | 存储原始交易与特征快照，支持回溯与模型训练 | Iceberg / Delta Lake | |
| 模型层 | 规则引擎 | 执行监管规则（如大额交易、频繁交易阈值） | Drools / EasyRules |
| 推理服务 | 加载 ML 模型，对交易特征进行实时评分 | ONNX Runtime / TensorRT | |
| 特征管道 | 从数据层提取特征，完成归一化、聚合与编码 | Feast / Tecton | |
| 监测层 | 评分聚合器 | 融合规则得分与模型得分，生成综合风险分 | 自研微服务 |
| 行为画像 | 维护客户/账户的实时行为基线（交易频次、金额分布） | Redis + Flink | |
| 关联分析 | 基于图结构发现团伙交易、资金循环等异常模式 | Neo4j / JanusGraph | |
| 告警层 | 告警生成器 | 根据风险分阈值与规则触发条件生成结构化告警 | 自研告警服务 |
| 案件管理 | 聚合关联告警，生成调查案件，支持人工标注 | 自研 + Elasticsearch | |
| 监管报送 | 按监管格式生成大额/可疑交易报告 | 自研报送适配器 |
2.3 数据流全景
一条交易从接入到最终告警，经历以下关键数据流阶段：
- 交易接入：上游核心系统通过 Kafka 发送交易事件，数据层进行格式校验与字段补齐。
- 特征提取：模型层从数据层拉取交易与客户画像，组装特征向量（如 24h 交易笔数、平均金额、对手方多样性）。
- 规则+模型并行评分：规则引擎与 ML 推理服务同时执行，规则命中直接产生中间告警，模型输出风险概率。
- 综合评分：监测层将规则得分与模型得分加权融合，结合行为画像偏差计算最终风险分。
- 告警决策：若风险分超过阈值，告警层生成告警记录，并关联历史告警与客户信息。
- 案件流转：告警进入案件管理模块，调查员复核后决定是否上报监管。
2.4 关键设计要点
💡 生产建议： 数据层与模型层之间使用 特征存储 (Feature Store) 作为缓存层，避免每次推理都重复计算特征，可将特征获取延迟从 50ms 降至 2ms 以内。
- 异步解耦：各层之间通过消息队列（Kafka/Pulsar）通信，避免同步阻塞；模型层与监测层可独立扩缩容。
- 状态管理：监测层的行为画像与窗口聚合使用 Flink 的 Keyed State 或 Redis 持久化，支持故障恢复。
- 模型热加载：模型层支持无中断更新模型版本，通过蓝绿部署或流量灰度切换实现。
- 告警降噪：告警层内置聚合规则，将同一客户在 5 分钟内的重复告警合并为一条案件，减少人工复核压力。
⚠️ 常见陷阱： 不要将规则引擎与 ML 推理放在同一线程池中执行。规则引擎通常为 CPU 密集型，ML 推理可能涉及 GPU 调用，混部会导致资源争抢与延迟抖动。建议使用独立的线程池或微服务部署。
2.5 架构演进路线
不同阶段的系统复杂度对应不同的架构选择：
| 阶段 | 架构特点 | 适用场景 |
|---|---|---|
| 单体阶段 | 规则+模型+告警部署在同一进程中，共享数据库 | 日均交易量 < 10 万笔，规则数 < 50 条 |
| 分层阶段 | 按数据/模型/监测/告警分层，通过消息队列解耦 | 日均交易量 10 万～500 万笔，规则数 50～200 条 |
| 微服务阶段 | 每层内部拆分为多个独立微服务，支持独立部署与扩缩容 | 日均交易量 > 500 万笔，多模型并行，多租户场景 |