3. 整体架构设计：分层架构与技术选型
低延迟贷后预警特征服务的核心挑战在于：在数百毫秒内完成数十个特征的实时计算与聚合，同时保证数据一致性与系统可用性。为此，我们采用四层分层架构，将数据接入、计算、存储与服务解耦，每一层独立扩展、独立优化。
设计目标：端到端 P99 延迟 < 200ms，单节点 QPS > 5000，支持每日亿级事件吞吐。
3.1 分层架构总览
整体架构分为四个逻辑层：数据源层、计算层、存储层、服务层。层与层之间通过轻量级协议（gRPC / Kafka）通信，避免强依赖。
3.2 各层职责与关键设计
3.2.1 数据源层
负责接入所有贷后相关事件与状态变更。核心数据流包括：
- 实时事件流：还款、逾期、催收动作、客户信息变更等，通过 Kafka 接入，Topic 按业务域拆分。
- 变更数据捕获（CDC）：监听 MySQL Binlog，将核心表变更实时同步到计算层。
- 外部回调：第三方征信、支付渠道的回调结果，通过统一网关转为内部事件。
- 离线快照：每日 Hive 全量特征快照，用于冷启动与数据校正。
3.2.2 计算层
低延迟的核心所在。采用 Apache Flink 作为实时计算引擎，配合轻量级规则引擎处理特征逻辑。
| 计算组件 | 职责 | 延迟要求 |
|---|---|---|
| Flink 实时算子 | 滑动窗口计数、求和、最大/最小值、比率计算 | < 50ms |
| 特征衍生引擎 | 基于原始特征组合生成衍生特征（如逾期天数 / 授信额度） | < 20ms |
| 规则预计算 | 将固定时间窗口的规则结果提前物化，减少查询时计算 | < 100ms |
避坑提示：避免在计算层使用复杂 Join 或大状态算子。将需要关联的维度数据提前广播到算子本地缓存，可大幅降低延迟。
3.2.3 存储层
采用多模态存储策略，不同特征类型选择不同存储引擎：
- Redis Cluster：存放高频访问的实时特征（如近 7 天逾期次数），TTL 按需设置，平均读取延迟 < 1ms。
- HBase：存储宽表特征，支持按客户 ID 快速扫描，适合批量导出与回溯。
- ClickHouse：用于离线分析与监控报表，不参与在线查询链路。
- MySQL：元数据中心，存储特征定义、版本、数据源映射关系。
3.2.4 服务层
对外暴露统一的特征查询接口，屏蔽底层存储与计算细节。核心能力：
- gRPC 接口：批量查询指定客户的特征值，支持特征版本路由。
- 缓存穿透保护：布隆过滤器 + 本地缓存兜底，防止热点 Key 打穿存储层。
- 限流与熔断：基于令牌桶的 QPS 限流，熔断阈值可动态配置。
3.3 技术选型原则
技术选型遵循 “延迟优先、成本可控、运维友好” 三大原则。以下为关键组件的选型对比：
| 组件 | 选型 | 选型理由 | 备选方案 |
|---|---|---|---|
| 实时计算引擎 | Apache Flink | 低延迟、Exactly-Once 语义、丰富的窗口函数 | Spark Streaming（微批延迟较高） |
| 特征缓存 | Redis Cluster | 亚毫秒级读取、天然支持 TTL、集群模式易扩展 | Memcached（不支持复杂数据结构） |
| 消息队列 | Kafka | 高吞吐、持久化、多消费者订阅 | Pulsar（运维复杂度高） |
| 服务框架 | gRPC + Protobuf | 二进制协议、低序列化开销、支持流式调用 | Thrift（社区活跃度较低） |
| 元数据中心 | MySQL + Etcd | MySQL 存储特征定义，Etcd 存储动态配置与路由 | ZooKeeper（不适合大量元数据存储） |
注意：技术选型不是一成不变的。当业务量级从百万级增长到亿级时，Redis 集群的分片策略、Flink 的状态后端（从 RocksDB 切换到内存）都需要重新评估。
3.4 架构图：数据流与组件交互
下图展示了从事件产生到特征查询的完整数据流，以及各组件之间的交互关系：
3.5 架构设计要点总结
- 分层解耦：每层可独立扩缩容，计算层与存储层通过异步消息解耦，避免级联故障。
- 缓存为王：90% 的特征查询在 Redis 层命中，穿透率控制在 5% 以下。
- 冷热分离：实时特征走 Redis + Flink，离线特征走 HBase + ClickHouse，互不干扰。
- 可观测性：每层暴露 Prometheus 指标（延迟、QPS、错误率），配合 Grafana 监控大盘。
架构决策记录：为什么不用 Elasticsearch 做特征存储？虽然 ES 查询灵活，但写入延迟抖动较大（尤其在合并段时），且内存占用高。对于固定 Key 的特征查询，Redis + HBase 组合在成本与延迟上更优。