1. 从“硬编码”到“规则引擎”为什么我们需要它如果你写过业务代码尤其是那些充满if-else或者switch-case的逻辑那你一定对“规则”这个词不陌生。比如“如果用户是新注册用户且订单金额大于100元则赠送一张10元优惠券”或者“如果商品库存小于10件则在商品详情页显示‘库存紧张’”。这些逻辑我们通常直接写死在代码里。一开始这没什么问题业务简单规则清晰。但随着业务发展问题就来了。市场部的同事跑过来说“我们下周要搞个活动规则改成‘新用户订单满50就送券老用户满200才送’。” 这时候你就得去改代码、测试、发布。没过两天运营又说“这个活动效果不好我们想按地区再细分一下一线城市用户门槛再降20块。” 你又得重复一遍改代码、测试、发布的过程。更头疼的是如果规则复杂到涉及多个部门的审批流比如风控规则、促销规则、审核规则每次改动都牵一发而动全身测试成本高上线风险大业务响应速度慢得像蜗牛。这就是“硬编码”规则的痛点变更成本高、灵活性差、业务与技术耦合紧密。规则引擎就是为了解决这些问题而生的。它把业务决策逻辑从应用程序代码中剥离出来用更接近业务语言比如自然语言或特定DSL的方式来编写和管理规则实现规则的动态加载、执行和更新而无需重启应用。市面上规则引擎不少老牌的像Drools功能强大但体系庞大学习曲线陡峭更像一个“重型武器”。对于很多中小型项目或者只是想快速、轻量地解耦业务规则的需求来说Drools 可能有点“杀鸡用牛刀”。这时候像Easy Rules这样的轻量级规则引擎就进入了我们的视野。它核心目标明确提供一个简单而强大的规则抽象让开发者能以最小的代价引入规则引擎的能力。它不是 Drools 的替代品而是在“简单规则管理”这个细分场景下的一个优雅解决方案。2. Easy Rules 核心设计哲学简单到极致Easy Rules 的“Easy”体现在它的设计哲学上。它没有试图去实现一个完整的、复杂的规则管理系统Rete算法、决策表、流处理等而是聚焦于最核心的概念规则Rule、事实Facts和规则引擎RulesEngine。它的 API 设计非常直观几乎一看就懂。2.1 核心三要素Rule, Facts, RulesEngine规则Rule这是业务逻辑的载体。一个规则必须包含三个核心部分名称Name与描述Description用于标识和说明规则。条件Condition一个返回布尔值的表达式。当条件为true时表示该规则被激活。动作Actions当条件满足时执行的一系列操作。在 Easy Rules 中你可以通过实现Rule接口或者更方便地使用Rule注解来定义一个规则。事实Facts顾名思义就是执行规则时所依据的数据。它本质上是一个键值对MapString, Object的包装类。你可以把业务数据比如用户对象、订单对象、当前时间等以特定的键Key放入 Facts 中规则的条件和动作就可以通过这个键来获取和操作这些数据。Facts 是规则引擎与外部世界你的应用程序进行数据交换的桥梁。规则引擎RulesEngine这是规则的执行者。它负责评估所有注册规则的条件对符合条件的规则按照一定的策略优先级、跳过策略等执行其动作。Easy Rules 提供了几种不同的引擎实现比如默认的DefaultRulesEngine它允许你配置各种参数来控制规则执行的行为。2.2 与 Drools 的直观对比为了更清楚 Easy Rules 的定位我们把它和 Drools 做个快速对比特性维度Easy RulesDrools核心目标轻量、简单、易集成企业级、功能全面、高性能学习曲线极低API直观半小时上手陡峭需要理解Rete算法、DRL语法、决策表等规则定义主要基于 Java 注解或 POJO支持 DRL领域特定语言、决策表、向导式规则编辑规则复杂度适合中等及以下复杂度的业务规则适合高复杂度、规则数量庞大、需要高性能推理的场景规则管理通常与代码一起管理或通过文件/DB加载提供完整的规则仓库、版本管理、部署控制如 KIE Workbench集成成本极低一个 Jar 包几乎零配置较高需要引入多个模块配置相对复杂适用场景微服务中的局部规则解耦、配置化业务逻辑、快速原型验证风控系统、金融产品定价、保险理赔、复杂审批流简单来说如果你的需求是“我需要把代码里那一坨if-else抽出来让它能动态配置但又不想引入一个庞然大物”那么 Easy Rules 几乎是为你量身定做的。如果你的规则成千上万且相互之间关联复杂需要高性能的模式匹配那么 Drools 或类似的重量级引擎才是更合适的选择。3. 手把手入门第一个 Easy Rules 应用理论说再多不如动手试一下。我们来构建一个最简单的例子一个年龄检查规则。规则是“如果一个人的年龄大于等于18岁则输出‘您是成年人’否则输出‘您是未成年人’。”3.1 项目搭建与依赖引入首先创建一个普通的 Maven 或 Gradle 项目。添加 Easy Rules 的核心依赖。目前主流版本是 easy-rules-core。Maven 依赖dependency groupIdorg.jeasy/groupId artifactIdeasy-rules-core/artifactId version4.1.0/version !-- 请检查并使用最新版本 -- /dependency如果你还想使用基于注解和表达式如 MVEL, SpEL的便捷功能可以额外引入easy-rules-support和表达式引擎依赖如easy-rules-mvel。dependency groupIdorg.jeasy/groupId artifactIdeasy-rules-support/artifactId version4.1.0/version /dependency dependency groupIdorg.jeasy/groupId artifactIdeasy-rules-mvel/artifactId version4.1.0/version /dependency3.2 定义规则注解式 vs 编程式Easy Rules 提供了两种主要方式来定义规则。我们先看最常用的注解式。方式一使用Rule注解推荐import org.jeasy.rules.annotation.*; import org.jeasy.rules.api.Facts; Rule(name “成人规则” description “检查年龄是否成年”) public class AdultRule { Condition // 条件方法返回布尔值 public boolean isAdult(Fact(“age”) int age) { // 从Facts中获取 key 为 “age” 的 fact 这里会自动注入 return age 18; } Action(order 1) // 动作方法order指定执行顺序如果有多个Action public void printAdult() { System.out.println(“您是成年人”); } Action(order 2) public void doSomethingElse() { // 可以执行其他操作 } }这种方式非常清晰通过注解将规则的各个部分与类的方法绑定起来。Fact注解用于将 Facts 中的值注入到方法参数中。方式二实现Rule接口import org.jeasy.rules.api.*; public class AdultRule implements Rule { Override public String getName() { return “成人规则”; } Override public String getDescription() { return “检查年龄是否成年”; } Override public int getPriority() { return 1; // 规则优先级数字越小优先级越高 } Override public boolean evaluate(Facts facts) { Integer age facts.get(“age”); return age ! null age 18; } Override public void execute(Facts facts) throws Exception { System.out.println(“您是成年人”); } }这种方式更底层你可以完全控制规则的每一个细节比如优先级逻辑。但在大多数简单场景下注解方式更简洁。3.3 组装与执行让规则跑起来定义好规则后我们需要创建规则引擎注册规则准备事实Facts然后触发执行。import org.jeasy.rules.api.*; import org.jeasy.rules.core.DefaultRulesEngine; public class AgeCheckApp { public static void main(String[] args) { // 1. 创建规则引擎使用默认配置 RulesEngine rulesEngine new DefaultRulesEngine(); // 2. 创建规则实例 Rule adultRule new AdultRule(); // 或者通过其他方式获取Rule对象 // 3. 创建事实Facts并放入业务数据 Facts facts new Facts(); facts.put(“age” 25); // 键 “age” 必须与规则中 Fact(“age”) 或 facts.get(“age”) 对应 // 4. 注册规则并执行引擎 rulesEngine.fire(new Rules(adultRule) facts); } }运行这段代码控制台会输出“您是成年人”。如果你把年龄改成 16则规则条件不满足不会执行动作没有任何输出。注意这里有一个初学者常犯的错误。DefaultRulesEngine的fire方法会执行所有符合条件的规则。如果你有多个规则并且希望当某个规则执行后阻止后续规则评估你需要使用RulesEngineParameters来配置引擎或者使用SkipOnFirstAppliedRule这样的监听器。我们稍后会详细讨论引擎的配置。4. 深入引擎配置与规则组织策略当你只有一个规则时一切都很简单。但现实项目往往是多个规则协同工作。如何管理这些规则引擎的行为如何定制这是 Easy Rules 进阶使用的关键。4.1 RulesEngine 的配置参数创建DefaultRulesEngine时可以传入一个RulesEngineParameters对象进行精细控制。RulesEngineParameters parameters new RulesEngineParameters() .skipOnFirstAppliedRule(true) // 当第一个规则被应用后跳过剩余规则的评估 .skipOnFirstFailedRule(false) // 当第一个规则失败后是否跳过剩余规则默认为false .skipOnFirstNonTriggeredRule(false) // 当第一个规则未触发是否跳过剩余 .rulePriorityThreshold(10) // 只执行优先级高于此阈值的规则优先级数字越小越高 .silentMode(false); // 是否静默模式不抛出异常 RulesEngine rulesEngine new DefaultRulesEngine(parameters);skipOnFirstAppliedRule(true)这是一个非常实用的配置。想象一下风控场景一系列风控规则按顺序检查一旦命中一条高风险规则比如“黑名单用户”后续的规则比如“交易额超限”就没有必要再检查了可以直接拒绝。这个配置就能实现这种“短路”逻辑。rulePriorityThreshold用于规则过滤。你可以为规则设置优先级通过getPriority()方法或Priority注解然后通过这个阈值来控制哪些规则有资格被执行。这在规则分组和分级执行时有用。4.2 规则优先级Priority与执行顺序规则优先级决定了当多个规则条件都满足时它们的执行顺序。优先级数字越小规则越先执行。在注解式规则中可以使用Priority注解Rule Priority(1) // 高优先级 public class HighPriorityRule { ... }在实现Rule接口的方式中则重写getPriority()方法。引擎默认按照优先级升序从高优先级到低优先级来执行规则。结合skipOnFirstAppliedRule参数你可以构建出复杂的规则流。4.3 规则来源如何动态加载规则把规则写在 Java 类里虽然清晰但变更还是需要重新编译。Easy Rules 支持从外部文件加载规则这才是实现“动态”的关键。1. 使用规则描述符YAML/JSON这是最常用的动态加载方式。你可以将规则定义在 YAML 或 JSON 文件中。adult-rule.yml:name: “成人规则” description: “检查年龄是否成年” priority: 1 condition: “person.age 18” actions: - “System.out.println(\\“您是成年人\\“);”然后使用YamlRuleDefinitionReader来加载MVELRuleFactory ruleFactory new MVELRuleFactory(new YamlRuleDefinitionReader()); Rule rule ruleFactory.createRule(new FileReader(“adult-rule.yml”));这里condition和actions使用的是 MVEL 表达式语言。你需要引入easy-rules-mvel依赖。你也可以使用 SpELSpring Expression Language等其他表达式引擎只需引入对应的支持模块。2. 从数据库加载你可以将规则的 YAML/JSON 内容或表达式字符串存储在数据库表中。在应用启动或通过监听机制如定时任务、配置中心通知从数据库读取规则定义然后利用MVELRuleFactory或SpELRuleFactory在内存中创建Rule对象并注册到引擎中。这样就实现了不重启应用的热更新规则。3. 组合规则Composite Rule对于一组逻辑上紧密相关、总是需要一起评估的规则可以使用UnitRuleGroup。它会将多个规则作为一个单元对待只有当组内所有规则的条件都满足时组内所有规则的动作才会按顺序执行。这类似于逻辑“与”AND。UnitRuleGroup myUnitRuleGroup new UnitRuleGroup(“myUnitRuleGroup” 1); myUnitRuleGroup.addRule(rule1); myUnitRuleGroup.addRule(rule2); // 只有 rule1 和 rule2 都满足条件它们的action才会执行还有ActivationRuleGroup类似逻辑“或”的变体和ConditionalRuleGroup更复杂的条件依赖用于处理不同的规则组合逻辑。5. 实战场景剖析促销系统规则设计让我们用一个更贴近实际的例子——电商促销系统来串联 Easy Rules 的核心用法。假设我们有如下需求新用户首单立减 10 元。订单金额满 100 元减免 5 元。如果商品属于“电子产品”类额外赠送积分金额每10元送1积分。以上优惠可以叠加但总减免金额不能超过订单金额的50%。5.1 定义领域对象与 Facts 键规划首先定义我们的业务对象// 简化的领域对象 Data // 使用Lombok public class User { private String id; private boolean isNew; // 是否新用户 // ... 其他属性 } Data public class Product { private String id; private String category; // 商品类别 private BigDecimal price; // ... 其他属性 } Data public class Order { private String orderId; private User user; private ListProduct products; private BigDecimal totalAmount; // 订单原总金额 private BigDecimal discountAmount BigDecimal.ZERO; // 累计减免金额 private int bonusPoints 0; // 赠送积分 // 计算商品总价等方法... }在准备 Facts 时我们需要规划好键Key规则将通过这些键来获取数据。Facts facts new Facts(); facts.put(“order” currentOrder); // 放入整个订单对象 facts.put(“user” currentOrder.getUser()); // 也可以放入计算好的中间结果如“electronicsTotal” 电子产品总价5.2 实现多个业务规则我们使用注解式规则来实现。规则1新用户首单优惠Rule(name “NewUserDiscountRule” description “新用户首单立减10元”) Priority(1) // 高优先级先执行 public class NewUserDiscountRule { Condition public boolean isNewUserAndFirstOrder(Fact(“user”) User user) { // 这里简化处理实际业务可能需要查询订单历史 return user ! null user.isNew(); } Action public void applyDiscount(Fact(“order”) Order order) { BigDecimal discount new BigDecimal(“10”); order.setDiscountAmount(order.getDiscountAmount().add(discount)); System.out.println(“应用新用户优惠-” discount “元”); } }规则2满减规则Rule(name “OverAmountDiscountRule” description “订单满100减5”) Priority(2) public class OverAmountDiscountRule { Condition public boolean isOverThreshold(Fact(“order”) Order order) { return order.getTotalAmount().compareTo(new BigDecimal(“100”)) 0; } Action public void applyOverDiscount(Fact(“order”) Order order) { BigDecimal discount new BigDecimal(“5”); order.setDiscountAmount(order.getDiscountAmount().add(discount)); System.out.println(“应用满减优惠-” discount “元”); } }规则3电子产品赠积分规则Rule(name “ElectronicsPointsRule” description “电子产品每10元送1积分”) Priority(3) public class ElectronicsPointsRule { Condition public boolean hasElectronics(Fact(“order”) Order order) { return order.getProducts().stream() .anyMatch(p - “electronics”.equalsIgnoreCase(p.getCategory())); } Action public void addPoints(Fact(“order”) Order order) { BigDecimal electronicsTotal order.getProducts().stream() .filter(p - “electronics”.equalsIgnoreCase(p.getCategory())) .map(Product::getPrice) .reduce(BigDecimal.ZERO BigDecimal::add); int points electronicsTotal.divide(new BigDecimal(“10”) 0 RoundingMode.DOWN).intValue(); order.setBonusPoints(order.getBonusPoints() points); System.out.println(“赠送电子产品积分” points “分”); } }5.3 引入规则监听器进行边界控制现在三个优惠规则可以叠加但我们需要确保总折扣不超过订单金额的50%。我们可以在所有规则执行完毕后通过一个规则监听器RuleListener来进行校验和修正。Easy Rules 提供了RuleListener接口允许你在规则生命周期的各个阶段评估前、评估后、执行前、执行后、执行失败插入自定义逻辑。我们创建一个全局的监听器在所有规则执行完成后onEvaluate和onExecute是单个规则的我们需要在引擎层面处理更合适的做法是创建一个专门的“校验规则”放在最后执行或者使用RulesEngineListener。这里为了演示监听器我们使用RuleListener并配合一个虚拟的“最终校验规则”。创建校验规则Rule(name “DiscountCapRule” description “确保总折扣不超过订单金额的50%”) Priority(10) // 设置为最低优先级确保最后执行 public class DiscountCapRule { Condition public boolean needToCheckCap(Fact(“order”) Order order) { // 这个条件始终返回true确保此规则总被执行以进行最终校验 return true; } Action public void applyCap(Fact(“order”) Order order) { BigDecimal maxDiscount order.getTotalAmount().multiply(new BigDecimal(“0.5”)); if (order.getDiscountAmount().compareTo(maxDiscount) 0) { System.out.println(“警告总折扣” order.getDiscountAmount() “元超过上限” maxDiscount “元 已调整为上限值。”); order.setDiscountAmount(maxDiscount); } System.out.println(“最终订单金额” order.getTotalAmount().subtract(order.getDiscountAmount()) “元 获得积分” order.getBonusPoints()); } }将这个规则也注册到引擎中由于其优先级最低10它会在所有优惠规则执行完毕后才执行进行最终的费用封顶校验。5.4 组装与测试最后我们创建主程序来组装和测试这个促销系统。public class PromotionSystem { public static void main(String[] args) { // 准备测试数据 User newUser new User(); newUser.setNew(true); Product phone new Product(); phone.setCategory(“electronics”); phone.setPrice(new BigDecimal(“3000”)); Product book new Product(); book.setCategory(“books”); book.setPrice(new BigDecimal(“50”)); Order order new Order(); order.setUser(newUser); order.setProducts(Arrays.asList(phone book)); // 假设计算出的总金额为3050 order.setTotalAmount(new BigDecimal(“3050”)); // 创建Facts Facts facts new Facts(); facts.put(“order” order); facts.put(“user” newUser); // 创建规则引擎配置为不跳过任何规则因为我们要叠加优惠 RulesEngineParameters params new RulesEngineParameters() .skipOnFirstAppliedRule(false); RulesEngine engine new DefaultRulesEngine(params); // 创建规则集合 Rules rules new Rules(); rules.register(new NewUserDiscountRule()); rules.register(new OverAmountDiscountRule()); rules.register(new ElectronicsPointsRule()); rules.register(new DiscountCapRule()); // 最后加入校验规则 // 执行所有规则 engine.fire(rules facts); // 输出最终结果 System.out.println(“\n 促销结果 ); System.out.println(“订单原价” order.getTotalAmount()); System.out.println(“累计折扣” order.getDiscountAmount()); System.out.println(“实付金额” order.getTotalAmount().subtract(order.getDiscountAmount())); System.out.println(“获得积分” order.getBonusPoints()); } }运行这个程序你会看到规则被依次触发并输出最终的促销计算结果。通过这个例子你可以清晰地看到如何将复杂的、可变的业务逻辑从主业务代码中剥离出来变成一个个独立的、可配置的规则对象。6. 性能考量、常见陷阱与最佳实践在享受 Easy Rules 带来的灵活性的同时我们也需要关注它在生产环境下的表现和可能遇到的问题。6.1 性能与线程安全规则评估开销每次调用RulesEngine.fire()引擎都会遍历所有注册的规则并评估其条件evaluate方法。如果规则数量很多比如上千条或者条件评估非常耗时比如涉及数据库查询、远程调用性能可能会成为瓶颈。优化建议规则分组与过滤使用rulePriorityThreshold或自定义的规则源只加载和评估当前上下文相关的规则子集。缓存条件结果如果某个规则的条件依赖于变化频率很低的数据如用户等级可以考虑在 Fact 中缓存计算结果或者使用Condition方法内部做简单的缓存。简化条件表达式避免在 MVEL/SpEL 表达式中编写过于复杂的逻辑尤其是循环和递归。线程安全RulesEngine本身是无状态的除了配置参数它的fire方法也是线程安全的只要传入的Facts和Rules对象是线程隔离的即每个线程使用自己的实例。关键在于Rule对象的实现。重要原则Rule 必须设计为无状态的Stateless。即不要在 Rule 类中定义可变的成员变量。规则的所有输入都应来自Facts所有输出都应写回Facts或作用于外部系统如数据库。这样同一个 Rule 实例才能被多个线程安全地并发执行。错误示例Rule public class BadRule { private int counter 0; // 非线程安全的成员变量 Condition public boolean condition() { return true; } Action public void action() { counter; } // 多线程下会出问题 }6.2 你可能遇到的“坑”与解决方案规则不执行检查 Fact 的键Key这是最常见的问题。规则中Fact(“myKey”)注解或facts.get(“myKey”)里的字符串“myKey”必须与你在facts.put(“myKey” value)时使用的键完全一致包括大小写。建议将 Fact 的键名定义为常量避免拼写错误。规则执行顺序不符合预期首先确认规则的优先级Priority或getPriority()是否正确设置。其次检查RulesEngineParameters中的skipOnFirstAppliedRule等配置。记住引擎默认按优先级升序执行所有符合条件的规则除非配置了“跳过”逻辑。使用表达式语言MVEL/SpEL时的安全隐患如果你允许从外部如数据库、配置文件加载规则表达式那么表达式注入就是一个安全风险。恶意用户可能构造一个执行系统命令的表达式如java.lang.Runtime.getRuntime().exec(‘rm -rf /’)。解决方案使用沙箱环境Sandbox。对于 MVEL可以配置MVELRuleFactory使用一个安全的ParserContext禁用危险的类和方法访问。对于 SpEL在 Spring 环境下可以使用StandardEvaluationContext并配合TypeLocator和MethodResolver进行严格限制。永远不要直接执行未经校验的外部表达式。规则循环依赖或死锁如果规则 A 的动作修改了某个 Fact导致规则 B 的条件被重新评估并触发而规则 B 的动作又可能反过来影响规则 A 的条件在复杂的规则集中可能形成非预期的循环。Easy Rules 本身没有内置的循环检测机制。解决方案这更多依赖于良好的规则设计。确保规则动作是幂等的并仔细规划规则的优先级和执行流。对于特别复杂的场景可能需要将规则分组分阶段执行。6.3 生产级使用建议规则版本化与回滚将规则定义文件YAML/JSON纳入 Git 等版本控制系统进行管理。每次规则变更都是一个提交可以方便地查看历史、比较差异和回滚。部署时可以将规则文件作为应用配置的一部分进行发布。规则热更新实现一个RuleProvider接口它负责从持久层数据库、配置中心如 Apollo/Nacos加载规则定义。在应用内启动一个定时任务或监听配置中心的变化事件当规则发生变化时由RuleProvider重新加载规则并刷新引擎中的规则集。刷新时要注意线程安全可以采用 Copy-On-Write 的方式替换整个Rules集合。监控与日志为关键的规则执行添加详细的日志记录规则的触发、Fact 的状态、执行结果等。这对于问题排查和业务审计至关重要。可以利用RuleListener在onSuccess或onFailure方法中统一添加日志和指标上报如到 Prometheus。单元测试规则也是代码需要测试。为每个规则类编写单元测试模拟不同的Facts输入验证其条件和动作是否符合预期。也可以对规则组合进行集成测试。与 Spring 等框架集成在 Spring Boot 项目中你可以将RulesEngine声明为 Bean并通过Component扫描所有带Rule注解的类自动注册到引擎中。利用 Spring 的依赖注入规则类中可以注入 Service 或 Repository 来获取更复杂的业务数据但需注意性能。7. 总结何时选择 Easy Rules经过以上详细的拆解我们可以对 Easy Rules 的适用边界有一个更清晰的认识。选择 Easy Rules当你的项目是 Spring Boot 微服务需要一个轻量级的组件来处理服务内部的、复杂度不高的业务规则。你受够了频繁修改和发布代码来应对规则变化希望找到一个快速解耦的方案。规则数量在几十到几百条这个量级且规则之间的交叉依赖不那么复杂。你希望团队业务人员如产品经理、运营能够通过编辑 YAML/JSON 文件来参与部分规则的配置当然需要一定的格式培训。你需要快速原型验证证明规则引擎能带来价值之后再考虑是否迁移到更强大的系统。考虑 Drools 或其他重型引擎当规则数量爆炸数千上万条且需要高性能的模式匹配。规则逻辑极其复杂存在大量的交叉引用、递归和推理需求。你需要一个完整的、带 Web 管理界面的规则生命周期管理平台规则编写、测试、版本、部署。你的团队有足够的资源和时间学习并维护一个更复杂的系统。Easy Rules 就像一把精致的手术刀在“规则管理”这个细分领域里它做到了简单、专注和高效。它可能不是所有规则问题的终极答案但对于那些渴望从“硬编码”泥潭中挣脱出来的团队来说它无疑是一个成本极低、收益显著的起点。