2. 风控网关架构设计:网关层、规则引擎层、决策引擎层、数据存储层的分层架构
风控网关是金融交易系统的第一道防线,其架构设计直接决定了拦截效率、响应延迟与扩展能力。一个成熟的风控网关通常采用四层分层架构:网关层、规则引擎层、决策引擎层、数据存储层。每层职责清晰、解耦独立,通过标准化接口协同工作。
架构设计核心原则: 高内聚、低耦合、可水平扩展、毫秒级响应。每一层只处理本层逻辑,不跨层调用数据或规则。
2.1 四层架构总览
下图展示了风控网关的完整分层结构,从流量入口到数据持久化,每一层承担不同的职责与处理粒度。
2.2 各层职责与关键技术
| 架构层 | 核心职责 | 关键技术/组件 | 延迟要求 |
|---|---|---|---|
| 网关层 | 流量接入、协议解析、身份认证、限流熔断、请求分发 | Kong / APISIX / Nginx + Lua | < 5ms |
| 规则引擎层 | 黑白名单、频次控制、设备指纹校验、基础规则匹配 | Drools / EasyRules / 自研规则引擎 | < 10ms |
| 决策引擎层 | 规则编排、模型推理、评分卡、策略组合、人工审核 | PMML / ONNX / 自研决策流 | < 50ms |
| 数据存储层 | 实时缓存、历史存储、特征宽表、日志审计 | Redis / MySQL / ClickHouse / HBase | < 5ms(缓存) |
2.3 网关层:流量入口的守门人
网关层是风控系统的第一道关卡,所有交易请求首先到达这里。它负责处理非功能性需求,将干净的请求转发给下层引擎。
- 协议转换: 支持 HTTP、HTTPS、gRPC、Dubbo 等多种协议,统一转换为内部 RPC 格式。
- 身份认证: 校验 API Key、Token、签名,拦截非法调用。
- 限流熔断: 基于令牌桶或漏桶算法,防止突发流量冲垮下游。
- 请求分发: 根据交易类型(支付、转账、注册)路由到不同的规则引擎实例。
实践建议: 网关层不要做任何业务逻辑判断,只做通用拦截。业务规则下沉到规则引擎层,保持网关层轻量、高性能。
2.4 规则引擎层:快速拦截与过滤
规则引擎层负责执行确定性规则,这些规则通常变化频率低、逻辑简单、对延迟敏感。它是风控系统的“快速通道”。
- 黑白名单: 手机号、IP、设备 ID 的精确匹配与正则匹配。
- 频次控制: 同一用户/设备在单位时间内的操作次数限制。
- 设备指纹校验: 检查设备是否被篡改、是否为模拟器。
- 基础校验: 金额上限、交易时间限制、地区限制。
规则引擎层通常采用编译型规则(如 Drools DRL)或配置型规则(如 JSON 规则表),支持热加载,无需重启服务。
2.5 决策引擎层:复杂策略与模型推理
决策引擎层是风控系统的大脑,处理需要多规则组合、模型评分、人工审核的复杂场景。它接收规则引擎层“放行”或“待审”的请求,进行深度分析。
- 规则编排: 支持 AND/OR/NOT 逻辑组合,支持规则优先级与权重。
- 模型推理: 加载机器学习模型(XGBoost、神经网络),输出风险评分。
- 评分卡: 基于特征变量的加权打分,输出最终风险等级。
- 人工审核: 对中风险请求生成工单,推送给审核人员。
注意: 决策引擎层是延迟消耗最大的环节。建议将模型推理结果缓存(如用户画像分),避免重复计算;同时设置超时熔断,防止模型卡死拖垮整个链路。
2.6 数据存储层:实时与历史的统一
数据存储层为上层引擎提供数据支撑,分为实时存储和历史存储两个维度。
| 存储类型 | 用途 | 典型技术 | 数据特点 |
|---|---|---|---|
| 实时缓存 | 频次计数器、用户画像、设备指纹、黑名单 | Redis Cluster | 高并发、低延迟、可过期 |
| 历史存储 | 交易流水、审核日志、特征宽表、模型训练数据 | MySQL / ClickHouse | 大容量、支持分析查询 |
| 消息队列 | 异步写日志、事件驱动、数据同步 | Kafka / RocketMQ | 削峰填谷、解耦 |
2.7 分层架构的请求处理流程
一个完整的交易请求在四层架构中的流转路径如下:
- 网关层接收请求,完成身份认证与限流,将请求转发给规则引擎层。
- 规则引擎层执行黑白名单、频次控制等快速规则。若命中拦截,直接返回拒绝;否则将请求传递给决策引擎层。
- 决策引擎层加载用户画像、调用模型、执行策略组合,输出“通过/拒绝/人工审核”结果。
- 数据存储层异步记录本次请求的完整日志、更新特征宽表、推送事件到消息队列。
2.8 分层架构的优势与避坑
| 优势 | 说明 |
|---|---|
| 独立扩展 | 网关层、规则引擎层、决策引擎层可分别水平扩展,应对不同压力场景。 |
| 故障隔离 | 某一层故障不会导致整个系统瘫痪,例如规则引擎宕机,网关层可降级为全量放行。 |
| 技术异构 | 各层可以使用不同的技术栈,例如网关层用 Go,决策引擎层用 Java + Python。 |
| 灰度发布 | 新规则或模型可以先在决策引擎层灰度,不影响规则引擎层的稳定规则。 |
常见避坑:
1. 不要在网关层做复杂业务逻辑,否则限流熔断会误伤正常请求。
2. 规则引擎层不要依赖外部 RPC 调用,否则延迟不可控。
3. 决策引擎层必须设置超时熔断,防止模型推理卡死。
4. 数据存储层要区分热数据(Redis)和冷数据(ClickHouse),避免冷数据查询影响实时链路。
1. 不要在网关层做复杂业务逻辑,否则限流熔断会误伤正常请求。
2. 规则引擎层不要依赖外部 RPC 调用,否则延迟不可控。
3. 决策引擎层必须设置超时熔断,防止模型推理卡死。
4. 数据存储层要区分热数据(Redis)和冷数据(ClickHouse),避免冷数据查询影响实时链路。
2.9 架构落地示例:代码片段
以下是一个简化的风控网关请求分发伪代码,展示网关层如何将请求路由到规则引擎层:
// 网关层请求分发伪代码
public class RiskGatewayFilter implements GlobalFilter {
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
ServerHttpRequest request = exchange.getRequest();
// 1. 身份认证
if (!authenticate(request)) {
return rejectResponse(exchange, "AUTH_FAILED");
}
// 2. 限流检查
if (!rateLimiter.tryAcquire(request.getRemoteAddress())) {
return rejectResponse(exchange, "RATE_LIMITED");
}
// 3. 根据交易类型路由到规则引擎
String txType = request.getHeaders().getFirst("X-Tx-Type");
String ruleEngineUrl = routeToRuleEngine(txType);
// 4. 转发请求(异步非阻塞)
return forwardToRuleEngine(exchange, ruleEngineUrl, chain);
}
}
架构演进提示: 初期业务量小时,可以将规则引擎层和决策引擎层合并部署;随着业务增长,再逐步拆分为独立服务。分层架构的设计应预留扩展点,而非一步到位。