第4章规则引擎基础

4. 规则引擎基础：Drools规则引擎介绍、规则定义语法、规则与图数据的结合点

好，咱们进入第四章。这一章聊规则引擎，具体说就是Drools。

说实话，我在金融行业摸爬滚打这些年，见过太多“硬编码”的风控逻辑。一开始觉得挺爽，改个阈值直接改代码，上线就完事。后来项目大了，业务人员天天追着你改规则，那叫一个酸爽。直到我引入了Drools，才算是把业务逻辑和技术实现真正解耦了。

4.1 为什么金融系统需要规则引擎？

你想想看，金融业务里有多少“如果...那么...”的逻辑？

如果用户年龄小于18岁，拒绝开户
如果交易金额大于100万，触发人工审核
如果近30天登录IP超过5个不同城市，标记为高风险

这些规则，变化频率极高。业务部门今天说“风控阈值调一下”，明天说“新增一个反洗钱规则”。如果用Java if-else硬写，每次都要走完整的开发、测试、上线流程。一周能改一次就算快的了。

规则引擎的核心价值：把业务决策逻辑从应用程序代码中分离出来，用可读性强的规则语言编写，支持热部署、动态修改。

Drools就是干这个的。它是Red Hat开源的规则引擎，基于Rete算法（一种高效的模式匹配算法）。说白了，你给它一堆事实（Fact），它根据你定义的规则，自动匹配、推理、执行。

4.2 Drools规则定义语法（DRL）

Drools的规则文件后缀是.drl。我刚开始学的时候觉得语法有点怪，但用顺手了会发现，它其实很接近自然语言。

一个典型的规则长这样：

package com.example.rules

import com.example.model.Transaction

rule "大额交易人工审核"
    when
        $t: Transaction(amount > 1000000)
    then
        $t.setNeedManualReview(true);
        System.out.println("触发大额交易审核：" + $t.getId());
end

拆解一下：

package：规则包名，类似Java的包
import：导入要使用的Java类
rule "规则名称"：定义一条规则，名称要唯一
when：条件部分（LHS），匹配事实
then：动作部分（RHS），执行逻辑
end：规则结束

个人习惯：我写DRL文件时，喜欢把规则按业务模块分文件存放。比如风控规则放一个文件，反洗钱规则放另一个。这样维护起来清晰很多。

4.3 规则中的高级语法

实际项目中，规则不会这么简单。咱们看几个常用的高级特性。

4.3.1 多条件组合

rule "高风险客户交易拦截"
    when
        $c: Customer(riskLevel == "HIGH")
        $t: Transaction(amount > 50000, customerId == $c.getId())
    then
        $t.setBlocked(true);
        System.out.println("高风险客户交易已拦截");
end

这里用到了变量绑定和跨对象关联。规则引擎会自动做笛卡尔积匹配，效率比你自己写嵌套循环高得多。

4.3.2 规则优先级与冲突解决

当多条规则同时满足条件时，Drools按salience（优先级）决定执行顺序。数值越大，优先级越高。

rule "紧急规则"
    salience 100
    when
        // 条件
    then
        // 动作
end

rule "普通规则"
    salience 0
    when
        // 条件
    then
        // 动作
end

我曾经踩过的坑：有一次线上规则冲突，两条规则同时触发了不同的操作，导致数据状态不一致。后来我强制要求：所有规则必须显式声明salience，并且用注释写明优先级设计意图。这个习惯救了我好几次。

4.3.3 规则流（Rule Flow）

复杂场景下，规则不是简单并列的。比如：先做黑白名单检查，再做额度校验，最后做反洗钱分析。这时候可以用规则流来控制执行顺序。

<rule-flow>
    <start>
    <rule-set name="黑白名单检查">
        <rule name="黑名单拦截"/>
        <rule name="白名单放行"/>
    </rule-set>
    <rule-set name="额度校验">
        <rule name="单笔限额"/>
        <rule name="日累计限额"/>
    </rule-set>
    <end>
</rule-flow>

4.4 规则与图数据的结合点

好，重点来了。为什么咱们这门课要把规则引擎和图数据库放在一起讲？

因为传统的规则引擎，处理的是扁平的事实对象。比如一个Transaction对象，有金额、时间、用户ID。但金融风控中，很多规则需要多跳关联查询。

举个例子：

“如果交易对手的账户，在过去7天内，与超过3个被标记为欺诈的账户发生过交易，则本次交易需要拦截”

这个规则，用传统DRL写起来非常痛苦。你得先查交易对手，再查他的交易历史，再关联欺诈账户列表。数据量一大，性能直接崩。

但如果你把数据存在图数据库里，情况就完全不同了。

规则+图数据的结合点：用图数据库存储实体和关系，用规则引擎定义业务逻辑。规则引擎从图数据库中查询路径、模式、子图，作为规则判断的依据。

具体怎么做？我分享一个我在项目中实际用过的方案：

数据层：Neo4j存储客户、账户、交易、设备等实体，以及它们之间的关联关系
查询层：封装Cypher查询，暴露为Java服务
规则层：Drools规则中，调用这些查询服务，把结果作为规则条件

看一个伪代码示例：

rule "多跳关联欺诈检测"
    when
        $t: Transaction()
        // 调用图查询服务，检查交易对手的关联风险
        $riskPaths: GraphQueryResult(
            query == "MATCH (a:Account)-[:TRANSFERRED_TO*1..3]-(f:FraudAccount) WHERE a.id = $t.counterpartyId RETURN count(f) as riskCount",
            result.riskCount > 3
        )
    then
        $t.setRiskLevel("HIGH");
        System.out.println("多跳关联欺诈检测命中");
end

我建议：不要把复杂的图查询逻辑写在DRL文件里。更好的做法是，把图查询封装成独立的服务，规则引擎只做“调用服务+判断结果”的工作。这样规则清晰，图查询也能单独优化。

4.5 本章知识体系

下面这张图，帮你梳理本章的核心逻辑：

说白了，规则引擎负责“逻辑判断”，图数据库负责“关系挖掘”。两者结合，才能应对金融风控中那些复杂的、多跳的、动态的规则场景。

注意：规则引擎调用图查询时，一定要考虑性能。图查询如果涉及全图扫描，响应时间可能飙升到秒级。我的做法是：对高频查询加缓存，对低频复杂查询设置超时熔断。

嗯，这一章就到这里。规则引擎是个好东西，但别滥用。简单规则用DRL，复杂关联规则配合图数据库，这才是金融级系统的正确打开方式。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

4. 规则引擎基础：Drools规则引擎介绍、规则定义语法、规则与图数据的结合点

4.1 为什么金融系统需要规则引擎？

4.2 Drools规则定义语法（DRL）

4.3 规则中的高级语法

4.3.1 多条件组合

4.3.2 规则优先级与冲突解决

4.3.3 规则流（Rule Flow）

4.4 规则与图数据的结合点

4.5 本章知识体系