3. 核心组件拆解：事件接入层、规则引擎层、决策引擎层、数据存储层、监控告警层
好，咱们直接切入正题。一个低延迟风控系统，说白了就是五层架构的精密配合。我见过不少团队，一上来就堆技术栈，结果层与层之间耦合得像一团乱麻。今天我就把这五层拆开揉碎了讲，每一层该干什么、不该干什么，咱们一次说清楚。
核心原则：每一层只做一件事，并且做到极致。层间通信必须轻量，序列化协议首选 Protobuf 或 FlatBuffers，别用 JSON 硬扛。
3.1 事件接入层：风控系统的第一道门
事件接入层，说白了就是系统的「嘴巴」。所有外部请求、消息、日志，都得从这里进来。我个人习惯把它设计成无状态的水平扩展节点，这样流量再大也不怕。
核心职责：
- 协议适配：HTTP、gRPC、MQ（Kafka/RocketMQ）、TCP 直连，统统要能接。我在项目中遇到过最头疼的情况——业务方用自定义二进制协议，解析逻辑写了一大堆。后来我强制统一用 Protobuf 定义事件结构，世界清净了。
- 流量整形：限流、熔断、降级。你想想看，如果双十一流量直接怼到规则引擎，那引擎肯定秒挂。接入层必须做第一道防护。
- 事件标准化：把各种乱七八糟的原始数据，转成统一的内部事件格式。比如用户注册事件，不管从哪个渠道来，最终都变成
UserRegisterEvent。
避坑指南：我曾经在接入层做数据清洗，结果把规则引擎的活抢了。记住，接入层只做格式转换，不做业务判断。否则一旦规则变了，接入层也得跟着改，耦合度直接爆炸。
3.2 规则引擎层：风控的大脑
规则引擎层，这是整个系统的核心。我见过很多团队用 Drools，但说实话，对于低延迟场景，Drools 太重了。我个人更倾向于自研轻量级规则引擎，或者用 Groovy、MVEL 这类脚本引擎做动态规则。
关键设计点：
- 规则编译与缓存：规则不能每次都解析。我习惯在规则变更时，预编译成 AST（抽象语法树）并缓存起来。运行时直接执行 AST，延迟能降低 80% 以上。
- 规则优先级与短路：命中高风险规则后，直接返回拒绝，不再执行后续规则。这叫「短路优化」，能省下大量计算资源。
- 规则版本管理：线上规则变更必须支持灰度发布。我曾经因为一次全量规则更新，导致误杀大量正常用户，从那以后，没有灰度我绝不上线。
// 伪代码：规则引擎核心执行逻辑
public class RuleEngine {
private Map<String, CompiledRule> ruleCache;
public RuleResult execute(Event event) {
for (CompiledRule rule : sortedRules) {
if (rule.matches(event)) {
if (rule.getAction() == Action.REJECT) {
return RuleResult.REJECT; // 短路
}
// 记录命中，继续执行
}
}
return RuleResult.PASS;
}
}
3.3 决策引擎层：从规则到决策的最后一公里
很多人把规则引擎和决策引擎混为一谈，其实不对。规则引擎负责「是否命中」，决策引擎负责「命中了怎么办」。举个例子：规则引擎发现用户登录地点异常，决策引擎就要决定——是直接拒绝、还是要求短信验证、还是只记录日志？
决策引擎的核心能力：
- 策略组合：多个规则命中的结果，需要加权、投票、或按优先级组合。我习惯用「决策表」来配置，清晰又直观。
- 风险评分：输出一个 0-100 的风险分，业务方可以根据分数做更精细的控制。
- 异步决策：对于非实时场景（如事后分析），决策引擎可以走异步通道，不阻塞主流程。
注意：决策引擎的输出必须可追溯。每次决策都要记录「命中了哪些规则、最终决策是什么、为什么」。否则出了问题，你连锅都甩不出去。
3.4 数据存储层：风控系统的记忆体
数据存储层，说白了就是存「特征」和「结果」的地方。低延迟场景下，存储选型至关重要。我个人的经验是：
| 数据类型 | 推荐存储 | 原因 |
|---|---|---|
| 实时特征（用户最近 5 分钟行为） | Redis / Redis Cluster | 毫秒级读写，支持 TTL 自动过期 |
| 离线特征（用户历史画像） | HBase / Cassandra | 海量存储，列式查询快 |
| 规则与配置 | MySQL / Etcd | 强一致性，支持事务 |
| 决策日志 | Elasticsearch / ClickHouse | 全文检索，聚合分析快 |
缓存策略：我建议做两级缓存。本地缓存（Caffeine）扛热数据，Redis 扛温数据。冷数据直接查 HBase。这样 P99 延迟能控制在 5ms 以内。
避坑指南：我曾经把用户 IP 归属地这种静态数据也放 Redis，结果白白浪费内存。后来改成本地缓存 + 定时刷新，延迟没变，内存省了 60%。
3.5 监控告警层：风控系统的眼睛和耳朵
监控告警层，很多人觉得是「锦上添花」，其实它是「保命符」。没有监控，你根本不知道系统什么时候会挂。
必须监控的指标：
- 延迟：P50、P99、P999 延迟。我习惯在每一层都埋点，这样能快速定位瓶颈。
- 吞吐量：每秒处理事件数（TPS）。如果 TPS 突然下降，大概率是某层堵了。
- 规则命中率：每条规则的命中次数。如果某条规则命中率突然飙升，可能是误杀，也可能是攻击。
- 资源使用率：CPU、内存、GC 频率。Java 应用尤其要注意 GC，一次 Full GC 可能让延迟飙升到秒级。
告警策略：不要什么异常都告警。我见过最夸张的团队，一天告警 2000 条，最后运维直接屏蔽了所有告警。我建议只对「影响用户」的异常告警，比如 P99 延迟超过 100ms、错误率超过 1%。
// 伪代码：监控埋点示例
public class Monitor {
private static final Histogram latencyHistogram = Histogram.build()
.name("decision_latency")
.help("Decision engine latency in milliseconds")
.register();
public void recordDecision(long startTime) {
long cost = System.currentTimeMillis() - startTime;
latencyHistogram.observe(cost);
if (cost > 100) {
// 触发告警
alertManager.sendAlert("Decision latency too high: " + cost + "ms");
}
}
}
核心观点：监控不是用来「看」的，是用来「动」的。看到指标异常，必须能自动触发降级、扩容、或切流。否则等人工介入，黄花菜都凉了。
3.6 五层架构的整体协作
这五层不是孤立的，它们像流水线一样协同工作。我画了一张图，帮你理解整个流程：
从图上你能看到，事件从接入层进来，经过规则引擎匹配、决策引擎判断，最终输出结果。整个过程数据存储层提供特征支持，监控告警层全程盯着。嗯，这里要注意，每一层都必须是独立的进程或容器，这样才能独立扩缩容。
个人经验：我习惯在接入层和规则引擎之间加一个「事件总线」（比如 Kafka），这样即使规则引擎挂了，事件也不会丢。等引擎恢复后，从总线重新消费就行。这个设计救过我两次，一次是机房断电，一次是规则引擎内存溢出。
好了，五层架构的核心拆解就到这里。每一层都有它的脾气，摸透了，你的风控系统就能稳如老狗。