三大类规则引擎简介

一、什么是规则引擎

什么是规则引擎，规则引擎到底长啥样？一般来说主要分为下面三类：

• 低配版：没有配置界面，靠业务人员编写引擎规则DSL，一般存储在数据库或者文件中。这种规则引擎没有彻底解放业务人员和开发人员的耦合，但是加快了业务代码的上线速度，以及很容易就能进行规则变更。
• 进阶版：一般是某种特定的系统，针对这种系统需要设置一些有针对性的页面，需要判断某些参数是否符合某些条件，然后返回固定的值即可。

• 完全版：在进阶版中，规则引擎只是其中的一个部件，一般这种都很难复用于其他场景。但是一个完全版的规则引擎，追求的是超高的通用性，它提供了多种规则引擎的表达：比如决策集，决策表，决策树等，可以适用于很多需要使用规则引擎的地方。

二、有哪些规则引擎

在各大社区中，开源的规则引擎还是比较多的，但整体上，大分类主要为下面三类：

• 通过界面配置的成熟规则引擎：这种规则引擎相对来说就比较重，但是因为功能全，也有部分业务需要选择这个，比较出名的有:drools,urule。
• 基于jvm脚本语言：这种其实不是一个成熟的规则引擎，他应该算是规则引擎中的核心技术，有很多公司都会基于一些jvm的脚本语言，去自己开发一个轻量级的规则引擎，这里比较出名的有：groovy,aviator,qlexpress。
• 基于java代码的规则引擎：上面是基于jvm脚本语言去做的，会有一些语法学习的成本，所以就出现了基于java代码去做的规则引擎。比如通过一些注解实现抽象的方式去做到规则的扩展，比较出名的有: easyRules。

下面，我们就更详尽的去说明一下这三类规则引擎的一些内容。

三、成熟的规则引擎

作为完全版的成熟的规则引擎，往往可以当作saas产品进行售卖，urule既有开源的部分，同时也在卖着自己的高级功能，drools则是一个纯开源的产品。在这些规则引擎里，它一般都会分成好几种规则设计器来满足你想要的规则场景：

• 规则集：一组普通规则和循环规则构成的规则集合，是使用频率最高的一种业务规则。实现方式一般分为向导式：通过图形界面构成的；还有脚本式：通过自定义的DSL语言，类似我们下面会说到的jvm脚本规则引擎一样。
• 决策表：如果我们的业务规则是表格的形式，我们可以使用决策表来进行规则运算，通常我们的产品或者运营人员会给你一个excel表格去执行这些规则。如果我们想用规则集来实现，也是可以的，但是整体比较复杂，需要大量的写if/else，所以如果直接使用决策表的话，就能很快完成这些规则需求的执行。
• 决策树：决策树和其他的都有点不同，决策树的规则在底部，结果在顶部，这种形式所表达的业务也更为形象，我们可以根据自身的需要去选取使用。
• 规则流：又称决策流，它整个的结构类似于工作流，用来对已有的决策集、决策表、交叉决策表、决策树、评分卡、复杂评分卡或其它决策流的执行顺序进行编排，以清晰直观的实现一个大的复杂的业务规则。编排过程中即可以常见串行执行，也可以并行执行、或者是根据条件选择分支执行。

通过上面这些不同的规则设计器，我们便可以设计出不同的规则场景，那么我们应该怎么去调用这些规则呢，一般来说主要有下面三种方式：

• 生成jar包：配置好了之后会生成jar包，然后我们引入到我们项目中，项目调用这个jar包即可。
• 热更新模式：由规则引擎帮助你对这个jar包文件进行热更新，动态的加载到我们的jvm内存中，这种方式不需要重启机器。
• 服务模式：规则引擎自己提供机器，然后通过远程调用的方式，进行规则的计算。

以上三种，大家可以根据自己的场景需求来选择合适的调用模式。

四、jvm脚本语言的规则引擎

drools在互联网公司进行规则引擎调研的时候都会进入备选项，但是最后往往都会以太重，学习成本高而落选，轻量级的脚本语言最终会受到互联网公司的青睐。一般来说，下面三种比较轻量级的脚本语言会比较多的被大家用来做规则引擎：

• Groovy:Groovy是Apache基金会维护的一个脚本语言，它是基于JVM的语言，它结合了Python、Ruby和Smalltalk的许多强大的特性，Groovy 代码能够与 Java 代码很好地结合，也能用于扩展现有代码。由于其运行在 JVM 上的特性，Groovy也可以使用其他非Java语言编写的库。开源的风控引擎radar就是使用的Groovy去实现的。
• qlexpress：qlexpress是阿里开发的一个脚本语言，在阿里内部以及部分java系的公司都有使用，但是这个我不是太推荐，因为现在这个的社区活跃程度整体的确比较低，上一次更新是一年多前了。
• aviator：aviator又叫AviatorScript，是一门高性能、轻量级，寄宿于 JVM 之上的脚本语言，又叫做表达式语言，提供的语法有限制，支持闭包和函数式编程。最主要它是google开源出来的一个项目，对于他的品质还是非常有保证的，且其上手成本整体比较低。其主要特性有：

1.高性能：Aviator的基本执行过程是将表达式直接翻译成对应的 java 字节码执行，整个过程最多扫两趟，这样就保证了它的性能超越绝大部分解释性的表达式引擎。

2.轻量级：Aviator 除了依赖 commons-beanutils 这个库之外不依赖任何第三方库，因此，整体非常轻量级，整个 jar 包大小哪怕发展到 5.0 这个大版本，也才 430K。

3.开放能力强：Aviator内置的函数库非常“节制”，除了必须的字符串处理、数学函数和集合处理之外，类似文件 IO、网络等等你都是没法使用的，这样便能有效保证 Aviator 运行期的安全。如果你需要更多的高阶能力，是可以通过开放的自定义函数来接入以及各种定制选项。

4.开发量少：Aviator 与脚本语言类似，使用表达式引擎也需要自行实现规则的组合和决策流的编排等功能，不过由于表达式的运行比较易于控制，所以 Aviator 减少了不少的基础开发工作。对于有界面的需求话需要和前端进行配合，让前端的一些控件能自动转换成这种表达式语言，就能完成自动化。

五、java代码的规则引擎

基于java的代码规则引擎往往是一种框架，我们基于框架限定的一些条件来进行实现。下面来看一个实例：如果我们有多个加编号的流程，比如猿辅导加上编号前缀tutor,斑马的加上编号前缀conan,搜题的加上编号前缀solar，我们的普通写法是怎么写的呢？

    if(biz == "猿辅导"){
            tradeNo = "tutor" + tradeNo;
        }else if(biz == "斑马"){
            tradeNo = "conan" + tradeNo;
        }else if (biz == "搜题"){
            tradeNo = "solar" + tradeNo;
        }
复制代码

通过if/else 进行处理，看起来这种写法也没什么大毛病，其实他破坏了开闭原则，比如我们增加或者修改逻辑的时候都需要去动这一段代码，如果不小心改错了影响到其他逻辑这就得不偿失了。那么我们如何通过easyRule完成我们的这个功能呢？

@Rule(priority = 1)
public class FudaoRule {
    @Condition
    public boolean isFudao(@Fact("biz") String biz) {
        return biz == "猿辅导";
    }

    @Action
    public void process(Facts facts) {
        String tradeNo = facts.get("tradeNo");
        facts.put("tradeNo", "tutor" + tradeNo);
    }
}

@Rule(priority = 2)
public class BanmaRule {
    @Condition
    public boolean isBanma(@Fact("biz") String biz) {
        return biz == "斑马";
    }

    @Action
    public void process(Facts facts) {
        String tradeNo = facts.get("tradeNo");
        facts.put("tradeNo", "conan" + tradeNo);
    }
}
复制代码

我们实现这两个不同的类,@Rule注解中定义priority代表我们的if/else优先级， @Condition就是我们的条件判断，如果属于则进入条件判断，@Action是我们匹配之后的动作。通过这种方式如果后面再增加或者修改相关逻辑我们可以在不同的类里面去进行修改,也满足了我们的开闭原则。

另外，easyRules也支持使用yaml文件来进行规则的定义，类似我们之前的dsl，但是我觉得实现java类注解的方式是它的最大特点，很值得去了解学习。

      以上便是对这三大类规则引擎的一个简单介绍。如果你还在被if/else的逻辑所困扰，如果你的产品或者运营人员老是吐槽你的开发更不上他的需求，那么请选择一款趁手的规则引擎去解决这些问题吧。地址：规则引擎专题。