风险归因流式链路搭建与API实践 - 第2节

2.1 事件驱动架构：流式处理的基石

风险归因链路的核心是“事件”的流动。事件驱动架构（EDA）将系统行为建模为事件的产生、检测、消费和响应，是流式处理最自然的编程范式。

2.1.1 事件驱动 vs. 请求驱动

2.1.2 事件驱动架构核心组件

• 事件生产者（Producer）： 产生事件并发布到消息中间件。例如：网关服务在用户登录成功后发布 LoginSuccessEvent。
• 事件通道（Channel）： 通常是消息队列或事件流平台，负责缓冲、路由和持久化事件。
• 事件消费者（Consumer）： 订阅特定类型的事件，执行风控逻辑。例如：规则引擎消费 TransactionEvent 进行评分。
• 事件存储（Event Store）： 用于事件溯源和回放，是归因分析的数据基础。

2.2 消息队列核心概念：Kafka 与 RabbitMQ

消息队列是事件驱动架构的“血管”。在风险归因链路中，Kafka 和 RabbitMQ 是最主流的两种选择，但设计哲学差异显著。

2.2.1 核心概念对比

2.2.2 Kafka 核心组件详解

• Topic（主题）： 事件的逻辑分类。风控中通常按事件类型划分，如 risk-transaction、risk-login。
• Partition（分区）： Topic 的物理分片，每个分区是一个有序、不可变的日志文件。分区数决定了并行消费能力。
• Offset（偏移量）： 分区内每条消息的唯一序号。消费者通过提交 offset 记录消费进度，支持“从任意位置重放”。
• Consumer Group（消费组）： 一组消费者共同消费一个 Topic，每个分区只能被组内一个消费者消费，实现负载均衡。

2.3 流式数据模型设计

流式数据模型与传统的“表-行”模型有本质区别。在风险归因场景中，数据模型需要支持高吞吐写入、时序关联和状态更新。

2.3.1 事件模型（Event Model）

每个事件是一个自包含的不可变记录，包含以下核心字段：

{
  "eventId": "evt_20250321_001",       // 全局唯一事件ID
  "eventType": "LOGIN_SUCCESS",        // 事件类型
  "source": "gateway-service",         // 事件来源
  "timestamp": 1742544000000,          // 事件发生时间（毫秒时间戳）
  "key": "user_12345",                 // 分区键（用于顺序保证）
  "payload": {                         // 事件体
    "userId": "user_12345",
    "deviceId": "device_abc",
    "ip": "192.168.1.1",
    "loginMethod": "password"
  },
  "metadata": {                        // 元数据
    "traceId": "trace_xyz",
    "version": "1.0"
  }
}

2.3.2 状态模型（State Model）

流式处理中的“状态”是随时间演变的。风控归因需要维护以下典型状态：

• 窗口聚合状态： 例如“过去 5 分钟内同一 IP 的登录失败次数”。使用滑动窗口或滚动窗口维护。
• 实体画像状态： 例如“用户当前风险等级”、“设备历史行为摘要”。通常使用 Key-Value Store（如 RocksDB）持久化。
• 时序序列状态： 例如“用户最近 10 笔交易金额序列”。用于序列模型（如 LSTM）的实时推理。

2.3.3 数据模型设计原则