第3章：风控系统整体架构——分层架构设计
风控系统的架构设计，说白了就是解决一个问题：怎么在几百毫秒内，把海量数据变成一条“放行”或“拒绝”的指令。我做了这么多年风控架构，见过太多团队一上来就堆技术栈，结果系统跑起来像老牛拉车。今天咱们聊聊分层架构，这是风控系统的骨架。
3.1 为什么必须分层？
你想想看，一个风控请求从进来到出去，要经历多少环节？数据采集、特征计算、规则匹配、模型打分、人工审核……如果全揉在一起，改一个规则可能就要重启整个服务。我在项目中遇到过这种惨痛教训——线上规则更新导致整个决策链路阻塞了半小时。
分层架构的核心思想就八个字：各司其职，解耦协作。每一层只干自己的活，层与层之间通过标准接口通信。这样改规则不影响数据层，换模型不影响接入层。
分层架构的三大好处：
- 可维护性：每层独立迭代，互不干扰
- 可扩展性：哪层瓶颈加哪层资源
- 可观测性：每层都有清晰的监控指标
3.2 四层架构全景图
我习惯把风控系统分成四层：接入层、决策层、数据层、监控层。先看一张整体结构图，后面咱们一层层拆解。
3.3 接入层：系统的守门员
接入层是风控系统的第一道关卡。所有外部请求都从这里进来。嗯，这里要注意——接入层不干决策的活，它只负责两件事：收得进来，挡得出去。
我在项目中遇到过一个问题：某个渠道的请求量突然暴涨10倍，直接把决策层打挂了。后来我们在接入层加了限流和降级，才解决这个问题。
接入层核心职责
- 协议转换：HTTP、Dubbo、gRPC、MQ，统一转成内部协议
- 身份认证：校验调用方身份，防止恶意攻击
- 流量控制：令牌桶、漏桶、滑动窗口，按渠道/接口限流
- 请求路由：根据业务类型路由到不同的决策流
- 参数校验：空值、格式、长度等基础校验
避坑指南：我曾经在接入层做过一个蠢事——把参数校验做得太严格，导致正常请求被误杀。后来改成“宽松校验+异常标记”，把校验结果传给决策层，让规则自己判断要不要拒绝。
3.4 决策层：风控的大脑
决策层是整个系统的核心。说白了，就是根据数据层提供的特征，跑规则和模型，最后输出一个决策结果。我见过很多团队把决策层做得特别重，什么逻辑都往里塞，结果性能一塌糊涂。
决策层的核心组件
| 组件 | 职责 | 我的经验 |
|---|---|---|
| 规则引擎 | 执行if-else规则，支持热更新 | 用Drools或自研规则引擎，注意规则冲突检测 |
| 模型引擎 | 加载和运行机器学习模型 | 模型要支持灰度发布，别一把全切 |
| 策略编排 | 组合规则和模型，形成决策流 | 用DAG图编排，方便可视化 |
| 决策缓存 | 缓存相同请求的决策结果 | 注意缓存过期策略，别把拒绝结果缓存太久 |
| 人工审核 | 处理机器无法决策的case | 设计好审核队列和优先级 |
你想想看，一个请求进来，先跑规则还是先跑模型？顺序不同，结果可能天差地别。我习惯的做法是：先跑轻量规则过滤，再跑模型深度分析。这样能节省大量计算资源。
决策层性能关键指标：
- P99延迟：控制在200ms以内
- 吞吐量：根据业务量设计，一般要求5000+ TPS
- 规则命中率：监控每条规则的命中情况
- 模型AUC：定期评估模型效果
3.5 数据层：风控的弹药库
没有数据，风控就是瞎搞。数据层负责提供决策所需的所有特征。我见过最夸张的项目，一个请求要拉取200多个特征，数据层扛不住，决策层只能干等。
数据层的分层设计
数据层内部也要分层，我习惯分成三层：
- 实时数据层：从请求中提取的实时特征，比如IP、设备指纹、行为序列
- 离线数据层：从数仓计算的统计特征，比如历史交易次数、逾期率
- 图数据层：实体之间的关系特征，比如关联设备、共用手机号
注意：实时特征和离线特征要分开存储。实时特征用Redis或内存，离线特征用HBase或ES。混在一起会导致实时查询变慢。
特征计算的两种模式
特征计算有两种模式，我根据场景选择：
- 预计算模式：离线算好特征，决策时直接查。适合变化慢的特征，比如用户画像。
- 实时计算模式：请求来了现场算。适合时效性强的特征，比如当前IP的访问频率。
我曾经犯过一个错误：把所有特征都做成实时计算，结果高峰期CPU直接打满。后来改成“80%预计算+20%实时计算”，系统稳如老狗。
3.6 监控层：系统的眼睛
监控层不是独立的一层，它贯穿所有层。说白了，就是给系统装个仪表盘，出了问题能第一时间发现。
监控的三个维度
| 维度 | 监控内容 | 常用工具 |
|---|---|---|
| 业务监控 | 通过率、拒绝率、人工审核率、规则命中分布 | Grafana + Prometheus |
| 性能监控 | 各层延迟、吞吐量、资源使用率 | SkyWalking、CAT |
| 数据监控 | 特征缺失率、数据延迟、数据一致性 | 自研数据质量平台 |
我的习惯：每个监控指标都要设置上下两个阈值。上阈值触发告警，下阈值触发通知。比如延迟超过500ms告警，低于100ms通知。这样能避免告警疲劳。
3.7 分层架构的落地要点
说了这么多理论，最后聊聊落地时要注意的几个点：
- 接口设计要稳定：层与层之间的接口一旦确定，尽量少改。改接口意味着上下游都要改，成本很高。
- 超时和熔断：每一层都要设置超时时间。数据层挂了，决策层不能跟着挂。我习惯用Hystrix或Sentinel做熔断。
- 异步化：非核心链路可以异步处理。比如决策结果写日志，没必要同步等待。
- 灰度发布：规则和模型的变更要支持灰度。先切1%流量验证，没问题再全量。
总结一句话：分层架构不是把系统拆碎，而是让每一层各司其职。接入层管流量，决策层管逻辑，数据层管特征，监控层管全局。各层之间通过标准接口协作，出了问题能快速定位。
嗯，这就是我对风控系统分层架构的理解。下一层咱们聊聊接入层的具体实现，包括API网关选型、限流算法、协议转换这些实战细节。
公众号:蓝海资料掘金营，微信deep3321