4. 实时风控系统架构：流式处理框架、特征工程管道、模型推理服务与决策引擎

实时交易风控的 A/B 测试并非孤立运行，而是深度嵌入一套高吞吐、低延迟的流式处理架构中。本章将拆解该架构的四大核心组件：流式处理框架（Kafka、Flink）、特征工程管道、模型推理服务以及决策引擎。理解它们之间的数据流与协作关系，是设计有效 A/B 测试方案的前提。

4.1 流式处理框架：Kafka 与 Flink

流式处理框架是实时风控的“数据高速公路”与“计算引擎”。Apache Kafka 负责高吞吐、可持久化的消息队列，解耦各组件；Apache Flink 则提供有状态、Exactly-Once 语义的实时计算能力，是特征工程与事件关联的核心。

• Kafka Topics 设计： 按事件类型划分 Topic（如 transaction-raw、feature-update、model-score、decision-result），便于 A/B 测试按 Topic 粒度进行流量复制与隔离。
• Flink Job 职责： 消费 Kafka 原始事件，执行窗口聚合、多流 Join、时间序列特征计算，并将结果输出至特征存储或下游推理服务。
• A/B 测试集成点： 在 Flink 的 Source 算子中注入实验分桶逻辑，为每个事件打上 experiment_id 与 variant_id 标签，确保后续特征与模型路径一致。

4.2 特征工程管道

特征工程管道负责将原始交易事件转化为模型可用的数值特征。在实时场景下，管道需兼顾时效性与一致性，尤其当 A/B 测试涉及特征变更时，必须确保实验组与对照组使用同一套特征逻辑（或明确隔离的特征版本）。

4.3 模型推理服务

模型推理服务是风控决策的“大脑”。它接收来自特征管道的实时特征向量，加载训练好的模型（如 XGBoost、深度学习模型），输出风险评分。在 A/B 测试场景下，推理服务需要支持多模型版本共存与流量路由。

• 服务化部署： 通常采用 gRPC 或 RESTful API 对外暴露推理接口，容器化部署于 Kubernetes，支持弹性扩缩容。
• 模型版本管理： 通过模型注册中心（如 MLflow Model Registry）管理模型版本。推理服务根据请求中的 experiment_id 动态加载对应版本的模型。
• 性能要求： 单次推理延迟需控制在 10ms 以内，通常使用 GPU 或 ONNX Runtime 进行加速。

// 伪代码：推理服务根据实验 ID 路由模型
def predict(features: FeatureVector, experiment_id: str) -> float:
    if experiment_id == "exp_001":
        model = model_registry.load("fraud_model_v2")
    else:
        model = model_registry.load("fraud_model_v1")
    score = model.predict(features)
    return score

4.4 决策引擎

决策引擎是风控系统的“执行器”。它根据模型评分、规则集、用户层级策略，输出最终动作（通过、人工审核、拒绝）。在 A/B 测试中，决策引擎必须能够区分实验流量与基线流量，并应用不同的决策策略。