2. 特征服务架构总览
特征服务是规则引擎的“数据前处理层”，负责将原始业务数据转化为规则可消费的特征变量。在风控决策链路中，特征服务位于数据源与规则引擎之间，承担特征抽取、实时计算、版本管理与样本对齐的核心职责。
2.1 特征服务的定位
| 维度 | 说明 |
|---|---|
| 数据抽象层 | 屏蔽底层异构数据源（MySQL、Kafka、HBase、Redis）的访问差异，对外暴露统一特征标识 |
| 计算编排层 | 支持离线批处理、实时流计算、在线近线三种计算模式，按特征时效性自动路由 |
| 版本管理单元 | 每个特征可独立发布版本，支持 A/B 测试、灰度验证与回滚 |
| 样本对齐锚点 | 在特征生成时刻打上时间戳与版本标签，确保训练样本与线上推理使用同一特征逻辑 |
关键认知：特征服务不是简单的“数据搬运”，而是规则引擎的“感知器官”——它决定了规则能“看到”什么维度的信息，以及信息的时效性与准确性。
2.2 特征服务与规则引擎的关系
两者通过特征-规则契约解耦协作，典型交互流程如下：
- 规则定义阶段：规则分析师在规则配置平台引用特征标识（如
user_30d_loan_cnt），不关心特征计算逻辑 - 决策请求阶段：规则引擎收到请求后，向特征服务批量请求所需特征值（一次请求可包含 50~200 个特征）
- 特征计算阶段：特征服务根据特征定义，从数据源实时/准实时计算并返回结果
- 规则执行阶段：规则引擎将特征值代入规则表达式，输出决策结果
解耦收益：规则变更无需修改特征代码；特征升级不影响规则逻辑；双方可独立进行性能优化与容量规划。
2.3 整体架构分层
特征服务采用经典的三层架构：接入层 → 计算层 → 存储层，每层职责明确，支持水平扩展。
2.4 各层核心职责
2.4.1 接入层
- 协议适配：统一接收 HTTP/gRPC/消息队列请求，转换为内部 RPC 调用
- 流量管控：基于令牌桶的限流、基于响应时间的降级、基于调用方的鉴权
- 批量聚合：将同一请求中的多个特征按计算模式分组，减少下游调用次数
- 超时熔断：设置特征计算超时阈值（通常 50ms~200ms），超时返回默认值或降级特征
2.4.2 计算层
| 计算模式 | 典型场景 | 延迟要求 | 计算引擎 |
|---|---|---|---|
| 实时计算 | 设备指纹、IP 风险分、实时多头 | < 50ms | Flink / 自研 C++ 引擎 |
| 近线计算 | 用户 30 天行为聚合、时序特征 | 1s ~ 5s | Spark Streaming / Kafka Streams |
| 离线批处理 | 特征回溯、样本生成、全量统计 | 小时级 / 天级 | Hive / Spark / MapReduce |
常见陷阱：将离线特征逻辑直接用于在线推理，因数据口径不一致导致训练-推理偏差（Training-Serving Skew）。计算层必须维护统一的特征定义与版本映射。
2.4.3 存储层
- 在线 KV 存储：Redis / HBase / TiKV，存储实时特征值与预计算结果，支持高并发低延迟读取
- 离线 Hive 表：按日期分区存储全量特征快照，用于模型训练与回溯分析
- 特征元数据：MySQL / PostgreSQL，记录特征名称、类型、版本、计算逻辑、依赖数据源、负责人等
- 样本快照：在特征计算时刻，将特征值与请求上下文一起持久化，形成带版本标签的训练样本
2.5 特征请求处理流程
一次完整的特征请求经历以下步骤：
- 请求到达接入层：解析请求头（appId、userId、requestId），进行鉴权与限流检查
- 特征列表解析：从请求体中提取所需特征标识列表，按特征类型分组
- 缓存命中检查：查询在线缓存，命中则直接返回；未命中则进入计算层
- 计算路由：根据特征定义中的计算模式，路由到实时/近线/离线计算单元
- 结果聚合：合并缓存命中结果与计算层返回结果，统一格式返回给规则引擎
- 异步样本落盘：将本次请求的特征值与上下文写入样本快照队列，供后续训练使用
2.6 架构设计要点
设计原则：
- 无状态计算：计算层节点不持有状态，所有状态外置到存储层，便于弹性伸缩
- 缓存分层：本地堆内缓存（Caffeine）→ 分布式缓存（Redis）→ 持久化存储，逐级回退
- 特征血缘：记录每个特征值由哪个版本的计算逻辑、哪些原始数据源产生，支撑问题排查与样本审计
- 容量隔离：实时特征与离线特征使用独立的计算资源池，避免离线任务影响在线稳定性
特征服务架构的核心价值在于：将特征的生产与消费解耦，让规则引擎专注于决策逻辑，让数据工程师专注于特征质量，双方通过统一的特征契约协同工作。