3、规则引擎入门：规则引擎的概念、Drools/Aviator等轻量级引擎对比、规则表达式基础
规则引擎这东西，说白了就是把业务决策逻辑从代码里抽出来。我刚开始做风控那会儿，每次改个规则都要重新打包上线，烦得很。后来用了规则引擎，才算是解放了双手。
你想想看，风控规则变化多快？今天要封某个IP段，明天要调整交易限额。如果每次都改代码，运维得疯掉。规则引擎就是干这个的——让业务人员也能自己配规则，系统自动执行。
3.1 规则引擎的核心概念
规则引擎有三个核心部件：规则库、工作内存和推理引擎。
- 规则库：存放你定义的所有规则。比如“如果交易金额大于5000，则标记为高风险”。
- 工作内存：存放当前要处理的数据对象。比如一笔交易的所有字段。
- 推理引擎：负责把规则和数据匹配起来，决定哪些规则该触发。
我个人习惯把规则引擎想象成一个裁判。规则库是裁判手里的规则手册，工作内存是场上球员的实时数据，推理引擎就是裁判的大脑——看到犯规就吹哨。
关键点：规则引擎的核心价值在于解耦。业务逻辑和系统代码分开，改规则不用改代码，上线风险大大降低。
我在项目中遇到过一种情况：业务方早上提了个需求，说要把某个渠道的通过率从30%降到10%。如果没有规则引擎，我得改代码、走审批、等发布，最快也得半天。有了规则引擎，业务自己在后台改个阈值，5分钟生效。嗯，这就是价值。
3.2 轻量级规则引擎对比
市面上规则引擎不少，但做实时风控，我建议重点关注轻量级的。太重的那种（比如Drools的完整版）在毫秒级场景下扛不住。下面是我用过的几个主流选择：
| 引擎 | 特点 | 性能 | 适用场景 |
|---|---|---|---|
| Drools | 功能最全，支持RETE算法、规则流、决策表 | 中等，规则多时编译慢 | 复杂规则、规则间有依赖关系 |
| Aviator | 轻量级表达式引擎，语法类似Java | 极快，微秒级执行 | 简单条件判断、实时风控 |
| EasyRules | 极简API，基于注解 | 快，适合少量规则 | 快速原型、小规模规则 |
| QLExpress | 阿里出品，支持脚本扩展 | 快，支持动态编译 | 需要动态脚本的场景 |
我个人最常用的是Aviator。为什么？因为实时风控对延迟要求极高，Aviator的执行时间通常在微秒级，而且语法简单，业务人员稍微培训一下就能看懂。
我的建议：如果你的规则数量在100条以内，且规则之间没有复杂的依赖关系，直接用Aviator就够了。Drools虽然强大，但学习成本高，而且规则多了之后性能下降明显。
我曾经在一个项目中踩过坑——一开始用了Drools，规则写了两百多条，结果每次规则变更后编译要等好几秒。线上流量一大，规则引擎直接成了瓶颈。后来换成Aviator，同样的规则，执行时间从几十毫秒降到了几微秒。嗯，选对工具很重要。
3.3 规则表达式基础
规则表达式，说白了就是“如果...那么...”的逻辑。在Aviator里，表达式写起来跟Java差不多，但更简洁。
来看个例子：
// 判断交易金额是否超过阈值
amount > 5000 && riskLevel == 'HIGH'
// 判断是否在黑名单中
blacklist.contains(userId)
// 组合条件
(amount > 10000 || transactionCount > 5) && !isWhitelisted这些表达式可以直接写在规则配置里，运行时由引擎解析执行。你想想看，如果这些逻辑写在Java代码里，每次改条件都得重新编译。用表达式，改个数字就行了。
规则表达式有几个基础概念要掌握：
- 变量：就是你要判断的数据字段，比如amount、userId
- 操作符：>、<、==、!=、&&、|| 这些
- 函数：引擎内置的一些方法，比如contains、startsWith
- 常量：固定的值，比如5000、'HIGH'
避坑指南：我曾经在表达式里写了个 amount == null，结果Aviator直接抛异常。因为Aviator对null的处理跟Java不一样，你得用 amount == nil 才行。每个引擎的语法细节不同，一定要看文档。
再复杂一点的场景，比如需要计算多个维度的分数：
// 计算风险分数
score = (amount / 1000) * 2 + (transactionCount > 10 ? 5 : 0) + (isNewUser ? 3 : 0)
// 判断是否拒绝
score > 10 || blacklist.contains(ip)这种表达式在Aviator里可以直接写，不需要额外的函数。我个人习惯把常用的判断逻辑封装成函数，比如：
// 自定义函数：判断是否在短时间内高频交易
highFreqTrade(userId, 60, 5) // 60秒内交易超过5次这样业务人员配规则时，直接调用函数名就行，不用关心底层实现。
3.4 规则引擎在风控中的典型用法
实时风控里，规则引擎通常放在交易链路的关键节点上。比如用户发起支付时，系统先调风控服务，风控服务把交易数据喂给规则引擎，引擎跑一遍所有规则，输出一个决策结果。
我画了一张图，帮你理解这个流程：
这个流程看起来简单，但实际落地时有很多细节。比如规则引擎的规则怎么热加载？数据怎么预处理？异常怎么处理？这些后面章节会详细讲。
经验之谈：我建议你在规则引擎前面加一层数据预处理。比如把用户的历史行为聚合好，把IP的地理信息查好，再喂给规则引擎。这样规则表达式里直接拿处理好的数据判断，效率高得多。
规则引擎入门其实不难，关键是理解它的定位——它不是一个万能的决策系统，而是一个把“判断逻辑”从代码里剥离出来的工具。选对引擎、写好表达式，你的风控系统会灵活很多。
嗯，今天就先聊到这儿。规则表达式这块，多写多练就熟了。下次遇到复杂的规则场景，你也能知道该用哪个引擎、怎么写表达式了。