规则引擎选型与落地实践：从Drools到Aviator的取舍

1. 这次调研的起因：业务规则已经从配置变成了代码债

1.1 每次改规则都要发版，问题不在发版本身

前一阵子，业务方提了个听起来很简单的需求：把订单中心里“新客立减”的优惠门槛从满 100 改为满 99，生效范围限定在指定渠道，并且要求这次改动能像配置一样上线，而不是等我们排版本。就是这个需求，逼着我做了一轮完整的规则引擎调研分析。

当时我们订单中心的优惠计算逻辑已经有几千行，结构上做了策略模式、责任链，甚至加了一部分 SPI 扩展。单看某一个策略类，代码也算清晰。但把所有规则组合在一起之后，问题就暴露了：满减规则依赖用户等级，会员折扣依赖商品类目，新客立减又和渠道身份绑定。规则之间存在隐式优先级，改动一条往往要连带评估另外两三条。业务方想要的很简单，就是改一个数字。但对我们来说，这个数字散落在代码里，和编译、测试、发布紧紧绑在一起。

更难受的是规则只能由开发维护。运营每次想调整活动，哪怕只是改个金额阈值，都要提工单、排期、上线。时间一长，开发同学变成了“改规则的机器人”，业务方又觉得响应太慢。规则已经从最初的业务配置，慢慢变成了一笔沉重的代码债。

1.2 调研前我圈定的三个问题

做规则引擎调研很容易一头扎进产品对比里，但我在开始之前先给自己定了三个问题，后面所有选型判断都围绕这三个问题展开。

第一，规则能不能真正和业务代码解耦。我希望实现的效果是“条件”和“动作”可以被描述成数据，存在数据库或配置文件里，而不是散落在 Java 方法中。业务方只需要通过后台修改参数，不需要开发改代码。这个目标听起来简单，实际做起来会发现很多规则引擎只解决了“怎么执行规则”，没解决“规则从哪来、谁来改、怎么审批”。

第二，引入规则引擎之后，系统性能和稳定性会不会变差。订单优惠计算处在核心链路上，哪怕多消耗 5 毫秒，在大促流量下都可能被放大。所以我不光要看引擎的执行速度，还要看它能否缓存编译结果、是否支持热加载、规则数量增加后性能是否线性劣化。

第三，团队的学习成本和维护成本是否可控。规则引擎本身也是系统组件，它需要监控、需要排障、需要人维护。如果团队没人愿意学复杂的 DSL，选了一个功能再强的引擎，最后也只会被弃用。这三个问题在调研过程中不断帮我把方案拉回现实。

1.3 这次调研的边界

既然要做调研分析，我需要先划定边界，避免被“规则引擎”这个宽泛概念带跑。

我的重点是开源 Java 生态里的规则引擎和类规则引擎方案，包括 Drools、Easy Rules、Aviator、QLExpress、LiteFlow 这几个常见选项。商业业务规则管理系统（BRMS）不在考虑范围内，因为我们需要控制基础设施成本和供应商风险。工作流引擎也不在这次调研范围内，虽然它和规则引擎经常被放在一起比较，但解决的问题其实是两回事。

另一个边界是我没有把“可视化规则编排平台”作为必需项。很多团队一上来就追求业务人员能在界面上拖拽配置规则，但实际落地中，复杂的可视化平台反而会成为新的维护负担。我更倾向于先用规则文件或规则表的形式跑通流程，再逐步给运营配置人力所能及的配置界面。这个取舍在后面选型时起到了关键作用。

2. 规则引擎拆开看：核心概念与工作方式

2.1 先区分规则引擎、表达式引擎和编排引擎

在调研过程中我发现一个普遍误区：很多人把表达式引擎、规则引擎、流程编排引擎混为一谈。这三者的定位差异非常明显。

表达式引擎的核心能力是“算”，它接收一个表达式和一组变量，返回计算结果。比如判断amount >= 100 && user.isNew()，或者计算折扣金额。它不关心规则之间是什么关系，也不帮你管理规则优先级。

规则引擎的核心能力是“判断和组织”，它接收一批事实（Fact），把它和一组规则做匹配，命中后触发对应的动作。规则引擎会处理规则之间的优先级、互斥关系和依赖关系，它更像一个裁判员：规则都说清楚了，事实放进来，裁判决定吹哪个哨。

流程编排引擎的核心能力是“串联”，它把一个业务链路拆成多个步骤，通过 DSL 或配置控制步骤的先后顺序和分支条件。它本身不一定关心“条件是否成立”，更关心“下一步该执行谁”。

这三者的边界在实际项目中是模糊的，很多系统用表达式引擎实现了规则引擎的效果，也有系统用流程编排引擎把规则节点串起来。理解差异后，再看选型就会清晰很多。

2.2 一条规则的标准结构

无论用哪款引擎，规则的核心结构都差不多：条件部分（LHS）和动作部分（RHS），再加上名称、优先级、描述等元数据。一句话概括就是“当满足什么条件，执行什么动作”。

以 Drools 为例，一条简单的满减规则在 DRL 文件里长这样：

rule "new_user_discount" salience 10 when $order: Order(amount >= 100) $user: User(tags contains "NEW_USER") then $order.applyDiscount(20); end

如果换成 Easy Rules 这类轻量级引擎，规则就变成 Java 注解和对象：

@Rule(name = "new user discount", description = "新客满减") public class NewUserDiscountRule { @Condition public boolean isNewUser(@Fact("user") User user) { return user.isNew(); } @Action public void applyDiscount(@Fact("order") Order order) { order.discount(20); } }

无论哪种形式，规则的本质都是一种“可命中的判定逻辑”。真正影响选型的，是规则数量、规则之间的关系，以及引擎如何处理这些关系。

2.3 Rete 算法：为什么规则引擎可以处理成百上千条规则

Drools 之类完整规则引擎的核心竞争力在于 Rete 算法。简单理解，Rete 会先扫描一遍规则集合，把条件中的公共模式提取出来，构建成一个匹配网络。事实进来时，不是一条一条规则去扫，而是把事实沿着网络传播，每个节点只做自己那部分匹配。匹配结果还会被缓存，当事实变化时，只更新受影响的路径。

用图书馆来类比：普通做法是读者每找一个主题就翻一遍书架，Rete 则先按分类建好索引，新书进来直接放到对应分类，查询时只去相关区域找。规则数量越大，这种索引优势越明显。

但要注意，不是所有规则引擎都实现了 Rete。Easy Rules 默认是线性遍历所有规则，规则量少时完全够用，一旦规则到了上千条，就要压测确认是否会成为瓶颈。这也解释了为什么 Drools 很重，但依然有不可替代的地位。

3. 几款主流规则引擎的横向对比：从重到轻的选型谱系

3.1 Drools：最正宗，也最重的规则引擎

Drools 是 JBoss 社区维护的开源规则引擎，采用 Rete 算法，支持 DRL 规则文件、决策表、规则流等。你可以把一组规则打包进 KieContainer，通过 KieBase 和 KieSession 跟业务代码交互。功能上它确实能覆盖大多数复杂规则场景，包括激活组、议程组、规则流等等。

但重也是真的重。Drools 的 DSL 和运行时模型比较复杂，团队需要专门学习 Rete 概念、Kie 容器生命周期、冲突解决策略。规则文件一旦多了，没有配套管理工具的话，排查一条规则为什么没命中会变得很痛苦。它在银行、保险这种规则数量大、规则关系复杂、需要严格审核的场景下很合适，但对绝大多数互联网业务团队来说，可能有点高射炮打蚊子。

3.2 Easy Rules：适合中小团队的轻量级方案

Easy Rules 是一个很务实的轻量级规则引擎。它没有外部 DSL，规则直接用 Java 注解或者 RuleBuilder 定义，Fact 用 Map 传递。使用起来几乎不需要额外学习成本，项目里引入依赖就能用。规则之间可以通过 Rule 对象上的 compareTo 或者引擎的 RulePriorityComparator 控制优先级，功能虽然简单，但足够解决很多实际问题。

我之所以比较认可 Easy Rules，是因为它把“规则从业务代码里拆出来”这件事做到了最低成本。你可以把规则定义存到数据库里，启动时构建成 Easy Rules 的 Rule 对象，修改规则不必发版。当然，它不会帮你解决规则之间的复杂推理、不会自动管理规则的触发链，规则多了以后性能需要靠压测确认。它更适合中小团队、规则数量可控、核心诉求是“少发版”的场景。

3.3 Aviator 与 QLExpress：表达式引擎不是规则引擎，但对付简单规则很实用

Aviator 和 QLExpress 本质上都是表达式引擎，不是规则引擎，但它们经常出现在规则引擎选型讨论里。原因很简单：很多所谓规则，本质就是一条带 if 逻辑的表达式。

Aviator 性能高、语法轻量，适合做条件判断和公式计算；QLExpress 是阿里开源，语法更接近 Java，支持自定义函数、脚本块，灵活度更高。如果你把规则拆成“条件表达式”和“动作表达式”，存在数据库里，再写一个轻量执行器，完全可以自建一套很轻的规则服务。关键是规则之间大多是相互独立的，没有复杂优先级和依赖关系。

我在调研中发现，很多团队最终落地时并没有选 Drools 或 Easy Rules，而是用表达式引擎自建了规则层。原因很朴素：规则少、逻辑浅，表达式引擎完全够用，还不需要引入一套复杂框架。但如果你期待引擎帮你解决规则冲突、循环触发、依赖分析，表达式引擎做不到，这部分只能自己写。

3.4 LiteFlow：从流程编排角度解决“规则怎么组织”

LiteFlow 的定位和上面几个不太一样。它本质是流程编排框架，核心思想是把业务拆成组件，用 DSL 声明组件的执行顺序和跳转条件。在规则引擎调研里，LiteFlow 往往作为“规则编排”的备选方案出现。

比如风控链路：先加载用户信息，再判断是否命中黑名单，如果不命中再判断额度，最后决定放行或转人工。这种链路如果用 if-else 串起来，逻辑不难但不好维护；用 LiteFlow 可以把每一步变成独立组件，用编排 DSL 控制顺序。

它的优点是流程可视化、组件可以热更新、性能很高。但它不是推理式规则引擎，规则之间没有复杂的冲突解决机制，一切靠编排顺序表达。如果你的规则天然是流程式的，LiteFlow 会让你感觉很顺手；但如果你有成百上千条相互独立的 if 规则，硬往编排上套只会更别扭。

3.5 横向对比表与调研结论

下面这张表浓缩了我对几类方案的判断，方便快速回顾。

调研结论也比较明确：规则数量少且相互独立，优先考虑表达式引擎；规则数量多、关系复杂、需要统一管理，再考虑 Drools；Easy Rules 是两者之间的平衡点；如果业务本身是流程式规则，LiteFlow 是个不错的视角。

4. 选型判断与落地路径：我们选了哪条路，以及怎么切

4.1 为什么我们没有直接上 Drools

一开始我也动过直接上 Drools 的念头，毕竟它是公认的完整规则引擎，资料多、案例也多。但结合我们团队的实际情况反复评估后，我把这个方案否掉了。

我们当前的业务规则数量只有几十条，绝大多数是“新客判断”“金额阈值”“渠道白名单”这类单条件规则，规则之间基本是并列关系，没有复杂的触发链和冲突需要引擎推理。Drools 的 Rete 算法、议程组、激活组等能力，对我们现有问题属于高配，团队还要额外熟悉 DRL 语法和 Kie 容器生命周期，运维成本明显增加。

最终我们选择的是“Aviator 表达式引擎 + 自建规则表 + 轻量执行器”的组合。Aviator 负责条件表达式的解析和执行，规则表负责存储规则元数据、优先级和版本，执行器负责从规则表加载规则、按场景执行并记录日志。这个方案在保证灵活性的同时，把技术复杂度压到了最低。

4.2 试点范围怎么切才不至于翻车

选型完成后，最难的不是写代码，而是决定从哪里切。我强烈建议不要一开始就把核心链路迁移到规则引擎。我们选择的试点规则是“新客专享券”发放，它低频、影响面小、逻辑简单，最适合验证整条链路。

具体流程是先在原有代码旁新增规则引擎分支，通过开关控制走新逻辑还是旧逻辑：

if (ruleEngineSwitch.isOn("order_new_user_discount")) { result = ruleService.execute("order_discount", order); } else { result = oldService.calculate(order); }

线上先让规则引擎和新逻辑并行跑一段时间，每次执行都记录新旧结果。有差异时，第一时间打印规则命中日志和事实快照。跑通后再按用户维度灰度放量，先放内部账号，再放小流量，最后全量切换。这样即使规则引擎有边界问题，也能在放大流量前被及时发现。

4.3 规则的存储与发布流程

规则不能散落在配置文件里，那样跟写在代码里区别不大。我们在数据库中建了一张规则表，核心字段包括场景 code、规则名称、优先级、条件表达式、动作参数、版本号、生效开始时间、生效结束时间、状态。

发布流程上，每一次规则修改都生成新版本，不覆盖旧记录。上线前通过后台做表达式语法校验和试算，确认结果符合预期后再发布。发布时引擎只需要根据场景 code 和当前时间，选择状态为启用且时间窗内最新版本即可。回滚更简单，把指向的版本号改回旧版本，规则内容不需要重新发布。

这套设计本质上就是把“规则”当成数据资产来管理，而不是当成代码来管理。开发人员只需要关心规则执行器的稳定性，业务人员通过后台配置规则内容，双方各司其职。

5. 落地阶段真正让人头疼的细节

5.1 规则版本管理与灰度发布

规则引擎落地过程中，最先暴露的问题往往不是性能，而是规则版本混乱。我见过有的团队直接在数据库里修改规则字段，改完也看不出来到底改了什么。上线后出了问题只能靠回忆找回之前的配置。

所以规则版本化必须从第一天就做好。我的做法是规则表里每次变更都新增一条记录，保留完整的历史版本。版本号由数据库自增或通过版本序列生成，不允许更新已发布记录。规则引擎加载时会根据场景 code、当前时间和状态，找到唯一生效的版本。同时我会把规则内容做一次 hash，用来在缓存失效时快速校验版本一致性，避免缓存里面是旧规则、数据库里面是新规则的情况。

灰度发布方面，规则引擎本身和业务应用是绑在一起的，所以规则灰度要借助业务侧的用户维度和渠道维度。比如只对部分 user_id 尾号放量，只对指定渠道生效。不要想着让规则引擎自己去灰度，它只负责执行，灰度策略应该放在接入层。

5.2 性能、缓存与动态加载

表达式引擎虽然轻量，但也不能每次都重新编译表达式。Aviator 支持把编译后的表达式缓存起来，我们会在缓存 key 里带上场景 code、版本号和表达式 hash，这样规则更新后缓存 key 自然失效，不会出现新规则不生效的诡异问题。

规则执行器本身要做到无状态。每一条规则执行时，只接收事实对象，执行完返回结果，不持有业务状态。动作部分尽量只做计算和结果标记，不要把下单、发券这类副作用写在规则内部。真正的外部副作用放到执行器外面，等规则执行完再统一处理。这样做的好处是规则引擎可以随时重跑、试算和回放，而不会重复发券。

压测也很有必要。虽然 Aviator 性能很高，但规则动作里如果有远程调用，整体延迟就会不可控。我们要求规则表达式只能访问传入的 Fact 对象，不允许在表达式内部发起 HTTP 或者 RPC。这样规则执行耗时基本可控，压测数字也稳定。

5.3 调试与全链路日志

规则引擎最怕的是什么？一条规则线上没命中，但没人知道为什么。所以在落地阶段，我最早做的是规则命中日志。日志里至少要包含场景 code、规则名称、规则版本、关键事实摘要、执行耗时和 traceId。这样用户反馈订单没享受到优惠时，我们能快速查出来到底是规则没有加载，还是没有匹配，还是动作执行失败。

除了日志，我还加了一个“试算接口”。运营在后台可以输入模拟的订单和用户信息，引擎用当前最新版规则执行一遍，返回命中了哪些规则、执行了哪些动作、最终结果是什么。这个接口不产生任何副作用，纯粹做计算。它让业务人员改完规则后能自己验证，不用每次找开发陪跑。试算接口看起来很基础，但实际使用后能省掉很多沟通成本。

5.4 权限与审计

规则直接关联优惠、扣减、风控，所以不能让人人都能改。我在配置后台做了三档权限：查看、编辑、发布。查看权限给所有相关角色，编辑权限给产品运营，发布权限只给规则管理员和开发负责人。

每次规则修改都必须记录操作者、操作时间、变更前后的完整规则内容。规则发布前还要经过一次审批，审批人不是走形式，而是要对规则的业务结果负责。规则引擎本身不判断业务合理性问题，比如满减金额能不能是负数、折扣比例是否超限，这些校验要在配置写入时拦住。

这一步看起来繁琐，但实际发生资损事故后，你会庆幸每一条规则变更都有据可查。没有审计的规则引擎，就像没有日志的线上系统，出事之后只能靠猜。

最后说一个我自己的体会。规则引擎不会让混乱的业务规则自动变得清晰，它只是把规则从代码里搬到了配置层。如果规则本身已经失控，换任何引擎都只是换一种方式乱。判断要不要引入，先看两个指标：规则多久变一次、改规则的人是谁。一个月都改不了一次，代码加枚举就够；一周改好几次且希望运营自己动手，规则引擎才真的值得投入。这套调研和落地方法，希望对同样在纠结的你有一点参考。