2. 风控网关架构设计:网关层、规则引擎层、决策引擎层、数据存储层的分层架构

风控网关是金融交易系统的第一道防线,其架构设计直接决定了拦截效率、响应延迟与扩展能力。一个成熟的风控网关通常采用四层分层架构:网关层、规则引擎层、决策引擎层、数据存储层。每层职责清晰、解耦独立,通过标准化接口协同工作。

架构设计核心原则: 高内聚、低耦合、可水平扩展、毫秒级响应。每一层只处理本层逻辑,不跨层调用数据或规则。

2.1 四层架构总览

下图展示了风控网关的完整分层结构,从流量入口到数据持久化,每一层承担不同的职责与处理粒度。

风控网关四层分层架构 网关层(Gateway Layer) 流量接入 | 协议转换 | 身份认证 | 限流熔断 | 请求分发 规则引擎层(Rule Engine Layer) 黑白名单 | 频次控制 | 设备指纹 | 基础校验规则 决策引擎层(Decision Engine Layer) 规则编排 | 模型推理 | 评分卡 | 策略组合 | 人工审核 数据存储层(Data Storage Layer) 实时缓存(Redis) | 历史库(MySQL/ClickHouse) | 特征宽表 | 日志 各层通过 RPC/HTTP 或消息队列异步通信,支持独立部署与水平扩展

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 分层架构的请求处理流程

一个完整的交易请求在四层架构中的流转路径如下:

  1. 网关层接收请求,完成身份认证与限流,将请求转发给规则引擎层。
  2. 规则引擎层执行黑白名单、频次控制等快速规则。若命中拦截,直接返回拒绝;否则将请求传递给决策引擎层。
  3. 决策引擎层加载用户画像、调用模型、执行策略组合,输出“通过/拒绝/人工审核”结果。
  4. 数据存储层异步记录本次请求的完整日志、更新特征宽表、推送事件到消息队列。
请求处理流程时序 客户端 网关层 规则引擎 决策引擎 存储层 ① 请求 ② 转发 ③ 规则结果 ④ 决策请求 ⑤ 决策结果 ⑥ 返回 ⑦ 异步日志 关键时序说明 • 步骤①-②:网关层完成认证与限流后,将请求转发给规则引擎层。 • 步骤③-④:规则引擎层执行快速规则,若未拦截则传递至决策引擎层。 • 步骤⑤-⑥:决策引擎层返回最终结果,网关层响应客户端。 • 步骤⑦:决策引擎层异步写入日志与特征数据,不阻塞主流程。

2.8 分层架构的优势与避坑

优势 说明
独立扩展 网关层、规则引擎层、决策引擎层可分别水平扩展,应对不同压力场景。
故障隔离 某一层故障不会导致整个系统瘫痪,例如规则引擎宕机,网关层可降级为全量放行。
技术异构 各层可以使用不同的技术栈,例如网关层用 Go,决策引擎层用 Java + Python。
灰度发布 新规则或模型可以先在决策引擎层灰度,不影响规则引擎层的稳定规则。
常见避坑:
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);
    }
}
架构演进提示: 初期业务量小时,可以将规则引擎层和决策引擎层合并部署;随着业务增长,再逐步拆分为独立服务。分层架构的设计应预留扩展点,而非一步到位。