3. 整体架构设计：分层架构图及各层职责
贷后预警策略实时化改造的核心在于构建一套可水平扩展、低延迟、高可观测的分层架构。我们将整体系统划分为五个逻辑层：数据接入层、实时计算层、策略决策层、预警分发层和监控层。每一层职责清晰，通过标准化的数据协议和接口进行交互，确保整个预警链路从数据产生到用户触达的端到端延迟控制在秒级以内。
3.1 分层架构总览
下图展示了实时化改造后的贷后预警系统分层架构。数据从左至右流动，监控层从各层采集指标，形成闭环观测能力。
架构设计原则：各层之间通过异步消息解耦，数据接入层与实时计算层之间使用 Kafka 作为缓冲，保证流量洪峰时系统不崩溃。策略决策层无状态化设计，支持横向扩展。
3.2 各层职责详解
3.2.1 数据接入层
数据接入层是实时预警系统的“传感器”，负责从各类数据源采集原始数据，并进行统一的协议转换、数据清洗和格式化输出。该层必须支持高吞吐、低延迟的数据摄取，并保证数据不丢失。
| 数据源类型 | 接入方式 | 典型延迟 | 关键要求 |
|---|---|---|---|
| 业务数据库（MySQL/Oracle） | CDC (Debezium / Canal) | < 1s | Binlog 解析、断点续传 |
| 应用日志（Nginx/Java） | Filebeat / Flume | < 3s | 日志结构化、多行合并 |
| 外部 API 回调 | API Gateway + Kafka | < 500ms | 鉴权、限流、重试 |
| 用户行为埋点 | SDK 直推 Kafka | < 2s | 数据脱敏、Schema 校验 |
3.2.2 实时计算层
实时计算层是系统的“大脑”，负责对接入的数据进行实时特征计算、时间窗口聚合和复杂事件处理（CEP）。该层通常基于 Flink 或 Spark Streaming 构建，利用状态后端（如 RocksDB）管理中间状态，支持 Exactly-Once 语义。
- 特征实时计算：如近 30 天逾期次数、近 7 天还款金额波动率、当前在贷余额等。
- 时间窗口统计：滑动窗口（5min/1h/1d）内的交易频次、金额累计、异常行为计数。
- 复杂事件匹配：定义事件序列模式，如“连续 3 次还款失败 + 1 小时内更换设备”触发高优预警。
- 数据关联：将实时流与离线维度表（如黑名单、客户分层标签）进行 Stream-Table Join。
工程要点：实时计算层是延迟瓶颈所在。建议将状态后端配置为 RocksDB，并开启增量检查点（Incremental Checkpoint）以降低 Checkpoint 对性能的影响。同时，对 Keyed State 的 TTL 进行合理设置，防止状态无限膨胀。
3.2.3 策略决策层
策略决策层是预警系统的“裁判”，负责将实时计算层产出的特征向量输入到规则引擎和模型推理服务中，输出最终的风险等级和预警动作。该层要求具备毫秒级响应能力和动态热加载能力。
| 决策组件 | 适用场景 | 延迟要求 | 部署方式 |
|---|---|---|---|
| 规则引擎（Drools / EasyRules） | 确定性规则（如：逾期 > 30天 且 金额 > 1万） | < 10ms | 嵌入应用 / 独立服务 |
| 模型推理（PMML / ONNX Runtime） | 机器学习模型（XGBoost / LR / DNN） | < 50ms | 独立推理集群 |
| 决策表 / 决策树 | 多条件组合评分（如信用评分卡） | < 5ms | 配置中心下发 |
| AB 实验分流 | 策略灰度验证、冠军/挑战者模式 | < 2ms | SDK 嵌入 |
3.2.4 预警分发层
预警分发层负责将决策层产出的预警事件，按照预设的渠道路由规则和频率控制策略，推送给最终用户或下游系统。该层需要处理渠道不可用、用户退订、消息去重等异常场景。
- 渠道路由：根据预警等级和用户偏好，选择 Push、短信、邮件、企微等渠道。高优预警可多通道并行发送。
- 模板渲染：将预警参数（如客户名称、逾期金额、截止时间）填充到消息模板中，生成最终文案。
- 频率控制：同一用户在一定时间窗口内（如 1 小时）最多接收 N 条预警，避免骚扰。
- 送达确认：记录每条消息的发送状态（成功/失败/已读），支持失败重试和死信队列。
3.2.5 监控层
监控层是系统的“眼睛”，贯穿所有层级，负责采集指标、日志和链路追踪数据，提供实时告警和事后分析能力。没有完善的监控，实时系统就是“黑盒”。
| 监控维度 | 采集指标 | 工具选型 | 告警阈值示例 |
|---|---|---|---|
| 数据接入层 | 消息吞吐量、消费延迟、解析失败率 | Kafka Exporter + Prometheus | 消费延迟 > 30s |
| 实时计算层 | 算子延迟、Checkpoint 耗时、背压状态 | Flink Metrics + Grafana | 背压持续 > 1min |
| 策略决策层 | 规则命中率、模型推理 P99 延迟、决策超时次数 | Micrometer + Prometheus | P99 延迟 > 100ms |
| 预警分发层 | 发送成功率、渠道响应时间、退订率 | ELK + 自定义 Dashboard | 发送成功率 < 99% |
| 全链路 | 端到端延迟（数据产生到预警送达） | OpenTelemetry + Jaeger | P99 延迟 > 10s |
避坑提醒：监控层不要只关注“平均延迟”，务必设置 P99 / P999 延迟告警。平均延迟正常但 P99 飙升，往往意味着部分请求已经超时，系统存在长尾问题。同时，建议为每个预警事件生成唯一的 Trace ID，以便在 Jaeger 中快速定位瓶颈。
3.3 分层架构的核心优势
采用上述分层架构，相比传统的单体预警系统，带来了以下关键收益：
- 解耦与复用：各层独立演进，数据接入层可同时服务多个业务线，策略决策层的规则和模型可被不同预警场景复用。
- 弹性伸缩：实时计算层和策略决策层支持水平扩展，应对业务量突增（如双十一、还款高峰期）时只需增加节点。
- 可观测性：监控层从各层采集标准化指标，端到端延迟可追踪，故障定位时间从小时级缩短到分钟级。
- 灰度与实验：策略决策层的 AB 实验分流能力，使得新规则或新模型可以先在 5% 流量上验证，再全量上线，降低变更风险。