实时风控决策引擎 — 系统设计文档

项目编号：FIN-DESIGN-03
版本：v1.0
作者：MomoFinance
日期：2026-04-13
状态：设计完成
关联 ADR：ADR-001 规则引擎选型 / ADR-002 特征计算架构 / ADR-003 决策编排模式

---

一、需求分析

1.1 面试场景

面试官："请设计一个实时风控决策引擎，要求毫秒级响应，支持规则+机器学习混合决策，日均亿级事件处理。"

这是金融系统设计面试中出现频率极高的题目。它考察候选人对高性能低延迟系统、规则引擎与 ML 融合、流式计算以及金融业务理解的综合能力。

1.2 需求澄清（10 个关键问题）

1.3 功能需求

1.4 非功能需求

1.5 风控场景梳理

关键洞察：不同场景的超时降级策略截然不同——交易/注册/登录超时放行（避免影响用户体验），信贷超时拒绝（控制资金风险）。这是面试中的高分答案点。

---

二、高层架构设计

2.1 C4 Context — 系统上下文

风控引擎作为中台能力，被多个业务系统调用，同时依赖多个外部数据源。

核心交互方：

详细 C4 Context 图见 diagrams/c4-context.mmd。

2.2 C4 Container — 内部容器

风控引擎内部分为 9 个核心容器：

详细 C4 Container 图见 diagrams/c4-container.mmd。

2.3 核心决策流程

事件接入 → 特征提取 → 名单匹配 → 规则执行 → 模型预测 → 决策编排 → 结果输出
                                                                    ↓
                                                              异步事后分析

决策编排采用 DAG 有向无环图模式（见 ADR-003），关键设计：

1. 名单匹配优先级最高——命中黑名单直接拒绝，命中白名单直接放行，短路后续所有计算
2. 规则执行和模型推理可并行执行，最后由决策编排器综合
3. 整体超时控制：Gateway 层设置 50ms 超时，任何子环节超时触发降级
4. 异步事后分析：决策结果异步写入 Kafka，供离线分析和模型训练

详细序列图见 diagrams/sequence.mmd。

---

三、数据模型设计

3.1 核心表结构

risk_event（风控事件表）

设计要点：extra_data 用 JSONB 存储场景差异化数据，避免表结构频繁变更。

risk_rule（规则表）

risk_decision（决策结果表）

feature_config（特征配置表）

model_config（模型配置表）

list_entry（名单表）

case_task（案件工单表）

3.2 状态机设计

风控事件状态机

[接收] → PROCESSING → ┬→ PASSED（通过）
                       ├→ REVIEWING（人审中）→ ┬→ APPROVED（审核通过）
                       │                      └→ REJECTED（审核拒绝）
                       └→ REJECTED（直接拒绝）

案件工单状态机

[创建] → PENDING → IN_PROGRESS → ┬→ CONFIRMED_FRAUD（确认欺诈）→ [加黑名单+反馈模型]
                                  ├→ FALSE_POSITIVE（误杀放行）→ [加白名单+反馈模型]
                                  └→ ESCALATED（升级）→ [高级审核员]

详细状态图见 diagrams/state-machine.mmd。

---

四、核心组件详细设计

4.1 决策编排引擎（Decision Orchestrator）

设计理念：将风控决策流程建模为 DAG（有向无环图），实现最大并行度。

DAG 执行拓扑

                    ┌─→ [规则引擎] ──┐
[特征提取] → [名单匹配] ─┤                 ├→ [决策合并] → [结果输出]
                    └─→ [模型推理] ──┘

核心机制

1. 短路优化：名单匹配命中黑/白名单时直接短路，跳过规则和模型执行
2. 并行执行：规则引擎和模型推理使用 Fork-Join 并行执行，取两者中较慢的耗时
3. 优先级机制：名单 > 规则 > 模型（名单结果不可覆盖；规则 REJECT 优先于模型 PASS）
4. 超时降级：
   • 整体超时 50ms，分配给子环节：特征提取 10ms / 名单匹配 5ms / 规则+模型 25ms / 编排 10ms
   • 规则超时 → 使用已完成规则的结果
   • 模型超时 → 使用 fallback_score（默认中等风险）
   • 全部超时 → 按场景降级（交易放行/信贷拒绝）

决策合并策略

最终决策 = f(名单结果, 规则结果集, 模型分数)

逻辑：
1. 黑名单命中 → REJECT（不可覆盖）
2. 白名单命中 → PASS（不可覆盖）
3. 任一规则命中 REJECT → REJECT
4. 任一规则命中 REVIEW 或 模型分数 > review_threshold → REVIEW
5. 所有规则 PASS 且 模型分数 < pass_threshold → PASS

4.2 规则引擎（Rule Engine）

DSL 语法设计

// 示例规则
RULE "大额境外交易"
  SCENE: TRANSACTION
  PRIORITY: 10
  WHEN:
    event.amount > 50000
    AND event.geo_location NOT IN ("CN", "HK", "MO")
    AND feature("txn_count_24h", event.user_id) < 3
  THEN:
    REJECT
    REASON: "大额境外交易，用户近24小时交易次数少于3"
END

RULE "高频小额交易"
  SCENE: TRANSACTION
  PRIORITY: 20
  WHEN:
    feature("txn_count_5min", event.user_id) > 5
    AND event.amount < 100
  THEN:
    REVIEW
    REASON: "疑似盗刷：5分钟内多笔小额交易"
END

Rete 算法优化

选择自研 Rete 引擎而非 Drools（见 ADR-001），核心优化点：

1. 规则预编译：DSL → AST → 编译后的 Rete 网络，缓存在 JVM 内存
2. 增量匹配：只对变化的事实（Working Memory）做增量传播，避免全量重算
3. Alpha 节点合并：相同条件的 Alpha 节点共享，减少重复计算
4. 短路求值：AND 条件按选择性排序，高选择性条件前置

热更新机制

规则变更流程：
1. 策略分析师在管理后台编辑规则
2. 规则编译服务验证 DSL 语法 + 编译成 Rete 网络
3. 新版本写入配置中心（ZooKeeper）
4. ZooKeeper Watch 通知所有 Rule Engine 实例
5. 各实例异步拉取新版本，编译并替换本地 Rete 网络（双缓冲切换）
6. 替换完成后上报版本号，管理后台确认全量生效

时间线：编辑提交 → 30s 内全量生效（包含编译 + 分发 + 替换）

4.3 特征平台（Feature Store）

特征平台是风控引擎的「数据大脑」，直接决定规则和模型的表达能力。

实时特征（Flink 计算）

Flink 实现要点：

• 使用 滑动窗口（Sliding Window）而非滚动窗口，保证边界处特征平滑
• 窗口状态存储在 RocksDB StateBackend，支持大状态
• 计算结果原子写入 Redis（MULTI/EXEC），保证读一致性
• Checkpoint 间隔 10s，保证 Exactly-Once

离线特征（Spark T+1 计算）

特征一致性保障

训练-推理偏斜（Training-Serving Skew）是 ML 风控的首要挑战：

解决方案：Feature Registry（特征注册中心）
1. 每个特征有唯一定义（名称/计算逻辑/数据源/窗口）
2. Flink 作业和 Spark 作业从同一 Registry 读取计算逻辑
3. 推理时和训练时使用同一套特征提取代码（Feature SDK）
4. 定期运行一致性校验作业：对比实时特征和离线重算结果

4.4 ML 模型 Serving

模型生命周期

训练完成 → 离线评估(AUC/KS) → 注册到 Model Registry
    → Shadow Mode（记录预测但不参与决策）
    → Canary（10% 流量灰度）
    → Active（全量上线）
    → Deprecated（老版本下线）

影子模式（Shadow Mode）

新模型上线最重要的安全网：

1. 新模型部署后，先进入 Shadow 状态
2. 每个风控事件同时发给新旧模型推理
3. 新模型结果仅记录到日志，不参与实际决策
4. 运营团队对比新旧模型的表现（准确率/召回率/误杀率）
5. 确认新模型效果后，切换为 Canary → Active

模型监控

4.5 名单系统（List Service）

三级名单

匹配性能优化

查询路径（< 1ms）：
1. Bloom Filter 预检（内存，0.1ms）
   - 返回「一定不在」→ 跳过名单查询
   - 返回「可能在」→ 进入第2步
2. Redis 精确查询（0.5ms）
   - 使用 SET 数据结构，O(1) 查询
3. 命中后加载详细信息（名单来源/加入原因/过期时间）

名单来源管理

• 内部名单：案件审核确认欺诈 → 自动加入黑名单
• 外部名单：征信机构/央行反洗钱名单 → 定时批量导入
• 行业共享：联防联控名单 → API 实时同步

---

五、深度问题

5.1 性能优化

目标：P99 < 50ms，峰值 5 万 TPS

5.2 高可用设计

多机房部署

机房 A（主）                    机房 B（备）
┌──────────────────┐          ┌──────────────────┐
│ Decision Gateway │◄─同步──►│ Decision Gateway │
│ Rule Engine      │          │ Rule Engine      │
│ ML Serving       │          │ ML Serving       │
│ Redis (Master)   │──复制──►│ Redis (Replica)  │
│ Flink Cluster    │          │ Flink Cluster    │
└──────────────────┘          └──────────────────┘

降级策略矩阵

限流与熔断

• 接入层限流：Sentinel 限流，按调用方配额
• 模型熔断：Hystrix 熔断，连续 5 次超时自动熔断，30s 后半开探测
• 降级开关：运维可手动切换为纯规则模式

5.3 准确率 vs 召回率

风控核心矛盾：查全（召回率） vs 不误杀（准确率）。

多级阈值动态调整

模型输出分数范围 [0, 1]：
- score > 0.9  → REJECT（高置信拒绝）
- 0.7 < score ≤ 0.9 → REVIEW（中风险人审）
- score ≤ 0.7  → PASS（低风险放行）

阈值可按场景/时间/维度动态调整：
- 大促期间：适当提高 REJECT 阈值（减少误杀，保障交易体验）
- 盗刷高发期：适当降低 REJECT 阈值（宁可误杀，控制资损）

效果监控

5.4 可解释性

金融监管要求风控决策必须可解释。

决策解释链

{
  "event_id": "evt_20260413_001",
  "decision": "REJECT",
  "explanation": {
    "list_check": { "result": "NOT_HIT" },
    "rules_hit": [
      {
        "rule_id": "R001",
        "rule_name": "大额境外交易",
        "matched_conditions": [
          "amount=80000 > 50000",
          "geo_location=US NOT IN (CN,HK,MO)",
          "txn_count_24h=1 < 3"
        ]
      }
    ],
    "model_scores": {
      "fraud_model_v3": { "score": 0.92, "top_features": ["amount_zscore: 3.2", "new_merchant: true", "unusual_time: true"] }
    },
    "final_reason": "命中规则R001(大额境外交易) + 模型高风险评分0.92"
  }
}

模型可解释性

• 使用 SHAP 值解释模型预测，输出 Top-5 影响特征
• 审核员可在案件工作台查看完整的决策解释链
• 合规审计可导出任意时间段的全量决策日志

5.5 对抗演化

欺诈手法持续进化，风控系统必须具备快速响应能力。

发现新欺诈模式 → 应急响应流程：

T+0小时：案件系统发现异常 pattern → 告警通知风控团队
T+1小时：分析师定义临时规则（DSL） → 热更新上线（<1分钟生效）
T+24小时：数据团队标注样本 → 启动模型增量训练
T+72小时：新模型完成训练 → 进入 Shadow Mode 观察
T+1周：模型效果验证 → Canary 灰度 → 全量上线

关键闭环：
案件审核结果 → 标注为 True Positive/False Positive → 反馈给特征工程+模型训练

5.6 合规要求

---

六、架构决策摘要

---

七、面试口述版

2 分钟版本

风控引擎的核心架构分三层：接入层接收各业务系统的风控请求，通过 gRPC 同步调用；决策层是核心，采用 DAG 编排模式，先做名单匹配快速短路，然后规则引擎和 ML 模型并行执行，最后合并决策；数据层包括 Flink 实时计算的滑动窗口特征和 Redis 存储的名单与特征。

要做到 P99 < 50ms，关键设计有三点：一是规则预编译到内存用 Rete 算法匹配，二是特征预计算存 Redis 避免实时聚合，三是模型用 ONNX 优化推理。高可用方面，多机房部署，超时降级策略按场景区分——交易超时放行保体验，信贷超时拒绝控风险。

5 分钟版本

在 2 分钟版本基础上追加：

规则引擎我选择自研而不是 Drools，原因是金融场景需要极致性能——Drools 的通用性带来了不必要的开销，自研 Rete 引擎可以针对我们的规则 DSL 做深度优化，预编译后单次匹配在微秒级。规则热更新通过 ZooKeeper Watch + 双缓冲切换实现，30 秒内全量生效。

特征平台采用流批一体架构，Flink 做实时滑动窗口聚合（如近 5 分钟交易次数），Spark 做 T+1 离线画像。解决训练-推理偏斜的关键是 Feature Registry——训练和推理共用同一套特征定义和提取代码。

ML 模型上线采用 Shadow → Canary → Active 的渐进式发布。Shadow 模式下新模型只记录不决策，是最重要的安全网。模型监控关注 AUC 和 PSI，PSI > 0.2 触发自动重训。

合规方面，全链路决策日志保留 7 年，支持 SHAP 可解释性，自动触发 AML 大额可疑交易报送。

15 分钟版本

在 5 分钟版本基础上，深入展开：

• 数据模型设计（各核心表的关键字段和设计考量）
• 状态机设计（风控事件和案件工单的完整状态流转）
• 降级策略矩阵（各故障场景的详细应对方案）
• 准确率 vs 召回率的动态平衡策略
• 对抗演化的闭环机制（案件反馈 → 规则更新 → 模型重训）
• 跨机房部署的特征同步方案

---

八、自评与反思

设计亮点

1. DAG 决策编排：相比串行 Pipeline 减少了约 40% 的端到端延迟
2. 名单短路：黑/白名单命中直接返回，避免无效的规则和模型计算
3. Shadow Mode：模型上线的安全网机制，在金融场景中不可或缺
4. 场景化降级：交易超时放行 vs 信贷超时拒绝，体现了对业务的深度理解
5. 特征一致性：Feature Registry 解决训练-推理偏斜，是 ML 风控的核心挑战

设计取舍

1. 自研 Rete vs Drools：选择了性能，牺牲了社区生态和学习曲线
2. Redis 特征存储 vs 内嵌式：选择了水平扩展能力，牺牲了极致延迟（增加 ~1ms 网络开销）
3. 同步决策 vs 异步决策：选择了同步阻塞式（业务需要实时结果），异步仅用于事后分析

进一步优化方向

1. 联邦学习：多机构联合建模，解决数据孤岛问题
2. 图神经网络：利用交易图谱识别团伙欺诈
3. 自适应阈值：基于实时资损率自动调整决策阈值
4. A/B 测试平台：支持更精细的策略实验
5. 知识图谱：构建实体关系图谱，增强关联分析能力

面试常见追问