4. 风控Serving架构设计：整体架构分层、Serving与规则引擎的协作模式、高可用设计要点
风控Serving层是风控系统在线推理的核心枢纽，负责在毫秒级时间内完成特征计算、规则匹配、模型评分与决策输出。本章围绕Serving架构的三大核心维度展开：整体分层架构、Serving与规则引擎的协作模式、高可用设计要点。
4.1 整体架构分层：接入层、决策层、存储层
风控Serving架构采用经典的三层解耦设计，每一层职责清晰，便于独立扩展与灰度发布。
| 层级 | 核心职责 | 典型组件 | 关键指标 |
|---|---|---|---|
| 接入层 | 协议适配、流量整形、身份认证、限流熔断 | Nginx / OpenResty / Kong / 自研网关 | QPS、P99延迟、拒绝率 |
| 决策层 | 特征聚合、规则推理、模型Serving、策略编排 | 规则引擎（Drools / EasyRules）、模型Serving（Triton / ONNX Runtime）、策略编排引擎 | 单次决策耗时、规则命中率、模型吞吐 |
| 存储层 | 实时特征、黑名单、历史决策、模型元数据 | Redis / HBase / MySQL / TiDB / S3 | 读写延迟、数据一致性、容量水位 |
架构原则：接入层无状态，决策层轻量化，存储层读写分离。每一层都通过独立的健康检查与熔断机制保障整体可用性。
4.2 Serving与规则引擎的协作模式
在风控决策链路中，规则引擎与模型Serving并非串行或并行二选一，而是根据业务场景采用混合编排模式。常见的协作模式有三种：
- 前置规则过滤（Pre-filter）：规则引擎先执行，命中高置信拒绝规则（如黑名单、设备指纹异常）直接拦截，不再调用模型Serving，降低模型调用压力。
- 后置模型增强（Post-enrich）：模型Serving先输出风险评分，规则引擎基于评分结果执行二次策略（如评分 > 0.8 且命中多头规则则拒绝）。
- 并行投票融合（Parallel Voting）：规则引擎与模型Serving并行执行，结果通过决策融合层（如加权投票、逻辑回归融合）输出最终决策。
| 协作模式 | 适用场景 | 延迟影响 | 模型调用量 |
|---|---|---|---|
| 前置规则过滤 | 黑名单、设备指纹、IP风险 | 低（规则命中即返回） | 显著降低 |
| 后置模型增强 | 信用评分、额度测算 | 中（模型+规则串行） | 全部调用 |
| 并行投票融合 | 欺诈检测、多模型集成 | 较高（需等待最慢分支） | 全部调用 |
工程建议：生产环境中推荐“前置规则过滤 + 后置模型增强”组合。前置规则拦截率通常可达 30%~50%，大幅降低模型Serving的QPS压力，同时保证核心模型评分不被绕过。
4.3 高可用设计要点
风控Serving一旦不可用，直接影响业务放行或拦截决策，造成资损或客诉。高可用设计需覆盖以下五个关键维度：
- 无状态化与水平扩展：决策层所有节点不持有本地状态，特征与模型元数据全部下沉至存储层，支持秒级扩缩容。
- 多级熔断与降级：接入层配置QPS熔断（如单机QPS > 2000 触发降级）；存储层超时熔断（如Redis响应 > 50ms 降级为本地缓存兜底）。
- 同城双活 + 异地灾备：至少部署两个可用区，流量通过DNS/全局负载均衡分发；主备切换RTO < 30秒，RPO < 1秒。
- 灰度发布与全量回滚：规则与模型版本支持按流量比例灰度（如1%→5%→20%→100%），发现问题一键回滚至上一版本。
- 全链路监控与告警：覆盖接入层（QPS/4XX/5XX）、决策层（P99延迟/规则命中率/模型超时率）、存储层（连接数/慢查询/缓存命中率）。
避坑提醒：很多团队只关注模型AUC而忽略Serving可用性。实际生产中，Serving P99延迟从20ms抖动到200ms，可能导致网关超时重试，进而引发雪崩。务必为每个依赖设置独立的超时阈值与线程池隔离。
4.4 架构设计总结
风控Serving架构的核心在于分层解耦与协作编排。接入层负责流量治理，决策层聚焦推理效率，存储层保障数据一致性。规则引擎与模型Serving通过前置过滤、后置增强、并行投票三种模式灵活组合，兼顾性能与决策精度。高可用设计则从无状态化、熔断降级、多活部署、灰度回滚、全链路监控五个方面兜底，确保风控Serving在极端流量与故障场景下仍能稳定输出决策。