📚 课程目录第3章规则引擎入门

规则引擎入门：从概念到实战

说到规则引擎，很多同学第一反应是「这东西不就是 if-else 的升级版吗？」。嗯，这么说也没错，但只对了一半。我在风控系统里摸爬滚打这些年，见过太多把规则引擎用成「高级 if-else 集合」的案例，结果就是维护成本爆炸，线上事故频发。

今天咱们就好好聊聊，规则引擎到底是什么，它和普通代码逻辑有什么区别，以及市面上主流的 Drools 和 Aviator 该怎么选。

规则引擎的核心概念

规则引擎，说白了就是一个「把业务决策逻辑从代码中抽离出来，用更灵活的方式管理和执行」的组件。它通常包含三个核心部分：

规则库：存放所有业务规则的容器
工作内存：存放待匹配的事实数据
推理引擎：负责匹配规则和事实，决定执行顺序

我刚开始做风控时，觉得这东西太复杂了。后来踩过坑才明白，规则引擎最大的价值不是「执行规则」，而是「让规则可配置、可热更新、可审计」。你想想看，一个风控系统每天要处理上千万笔交易，如果每次改规则都要发版重启，那运维同学怕是要骂娘了。

核心观点：规则引擎的本质是「将业务决策从代码中解耦」，让非技术人员也能参与规则维护，同时保证执行效率和可追溯性。

规则与策略的区别

这个问题我面试时经常问，但能说清楚的人不多。很多人觉得「规则就是策略，策略就是规则」，其实不然。

维度	规则	策略
粒度	原子级，单条判断	组合级，多条规则编排
变更频率	高，随时调整	低，相对稳定
目标	解决「是否」问题	解决「如何」问题
举例	「金额 > 10000 则标记高风险」	「高风险交易走人工审核 + 短信验证」

举个例子你就明白了。在风控场景里，规则是「如果交易金额超过 5 万，且用户是新注册 7 天内，则命中高风险」。而策略是「高风险交易需要执行二次验证，中风险交易走异步审核，低风险交易直接放行」。规则是策略的砖瓦，策略是规则的蓝图。

我的经验：设计规则引擎时，一定要把规则和策略分开管理。我曾经在一个项目里把两者混在一起，结果业务方想调整策略顺序，却影响到了底层规则的执行逻辑，排查了整整两天才定位到问题。

Drools 与 Aviator 简介

市面上规则引擎不少，但风控领域用得最多的就是 Drools 和 Aviator。这两者走的是完全不同的路线。

Drools：重量级选手

Drools 是一个基于 Rete 算法的完整规则引擎。它有自己的规则语法（DRL 文件），支持前向链、后向链、规则冲突解决等高级特性。说白了，它就是一个「规则操作系统」。

// Drools 规则示例
rule "高风险交易拦截"
    when
        $t: Transaction(amount > 50000 && userAge < 7)
    then
        $t.setRiskLevel("HIGH");
        $t.setAction("BLOCK");
        System.out.println("命中高风险规则，交易已拦截");
end

Drools 的优点很明显：功能强大，社区活跃，适合复杂规则场景。但缺点也很突出：学习曲线陡峭，内存占用高，不适合超高频的实时计算场景。

我记得有一次在项目中用 Drools 处理每秒 5000+ 的实时风控请求，结果规则引擎的内存直接飙到 2GB，GC 频繁触发，延迟从 5ms 涨到了 50ms。后来我们不得不把 Drools 降级为离线规则校验，实时链路换成了更轻量的方案。

Aviator：轻量级黑马

Aviator 是一个高性能的轻量级 Java 表达式引擎。它不提供完整的规则引擎功能，而是专注于「表达式求值」。你可以把它理解成一个「超级计算器」。

// Aviator 表达式示例
// 规则：金额 > 10000 且 用户等级 < 3 则标记为高风险
String expression = "amount > 10000 && userLevel < 3 ? 'HIGH' : 'LOW'";
Map<String, Object> env = new HashMap<>();
env.put("amount", 15000);
env.put("userLevel", 2);
Object result = AviatorEvaluator.execute(expression, env);
System.out.println("风险等级：" + result); // 输出：HIGH

Aviator 的优势在于：轻量（核心包不到 1MB）、高性能（单次求值微秒级）、语法简单（类 Java 表达式）。但它的短板也很明显：不支持复杂规则编排，没有 Rete 算法优化，不适合规则间有依赖关系的场景。

避坑指南：我曾经在一个项目里用 Aviator 处理复杂的规则链，结果发现它不支持规则优先级和冲突解决。最后不得不自己写了一个规则编排层，反而增加了复杂度。选型时一定要搞清楚自己的场景。

如何选择？一张图说清楚

下面这张图是我根据多年实战经验总结的选型框架，你可以直接拿来用。

实战中的选型建议

说了这么多，到底该怎么选？我给出三个判断标准：

规则复杂度：如果规则之间没有依赖关系，只是简单的条件判断，Aviator 完全够用。如果规则需要优先级、冲突解决、规则链编排，那就得上 Drools。
性能要求：实时风控场景下，单次规则求值时间不能超过 5ms。Aviator 的微秒级性能更适合高频场景。Drools 虽然慢一些，但它的 Rete 算法在规则数量多时反而有优势。
团队能力：Drools 的学习成本不低，如果团队里没人熟悉 DRL 语法和 Rete 算法，建议先从 Aviator 入手，等业务复杂了再考虑升级。

我的习惯：在风控项目中，我通常采用「混合架构」——实时链路用 Aviator 做快速判断，离线链路用 Drools 做深度分析。这样既保证了实时性能，又保留了复杂规则的处理能力。

好了，规则引擎的入门知识就聊到这里。记住一句话：工具是死的，场景是活的。别为了用规则引擎而用规则引擎，先想清楚你的业务到底需要什么。