规则引擎学习

背景：

使软件可维护，适应业务变化不要经常改代码。

在没有规则引擎的时代，有些逻辑比较复杂的业务，只有不断的增添if-else去满足我们这个复杂的业务场景，对于开发者来说还好，对于后面接手的同学一看到处都是if-else。

类型：

一般来说分为下面三类：

  低配版：没有配置界面，靠业务人员编写引擎规则DSL，一般存储在数据库或者文件中，这种没有彻底解放业务人员和开发人员的耦合，但是加快了业务代码的上线速度，以及很容易就能进行规则变更。

  进阶版：这个一般是某种特定的系统，我们针对这种系统设置一些有针对性的页面，比如下面是某风控系统的截图，风控系统的规则引擎是相对来说比较简单的，只需要判断某些参数是否符合某些条件即可，然后返回固定的值即可。

  完全版：在进阶版中规则引擎只是其中的一个部件，一般这种都很难复用于其他场景。但是一个完全版的规则引擎，追求的超高的通用性，下面是从一个商业的规则引擎中截图：

可以看见提供了多种规则引擎的表达：比如决策集，决策表，决策树等等，适用于我们很多需要使用规则引擎的地方，下面暂时了一下决策树的配置，这个就和我们上面风控的配置有点类似，只不过通用性更强。

讲到这里基本上规则引擎是什么大家基本上心里面有个大概了，下面我们来讲下有哪些开源的规则引擎。

有哪些规则引擎

在社区中开源的规则引擎是比较多的，说明不同的业务团队，公司都对这个是比较看中的，但是整体上大的分类分为下面几类：

  通过界面配置的成熟规则引擎：这种规则引擎相对来说就比较重，但是因为功能全，也有部分业务会选择这个，一般出名的有:drools,urule。

  基于jvm脚本语言：这种其实不是一个成熟的规则引擎，他应该算是规则引擎中的核心技术，有很多公司比如美团，他会觉得drools这种太重了，然后会基于一些jvm的脚本语言，去自己开发一个轻量级的规则引擎，这里比较出名的有，groovy,aviator,qlexpress。

  基于java代码的规则引擎：上面是基于jvm脚本语言去做的，会有一些语法学习的成本，所以就有基于java代码去做的规则引擎，比如通过一些注解实现抽象的方式去做到规则的扩展，比较出名的有: easyRules。

成熟的规则引擎

作为完全版的成熟的规则引擎，往往可以当作sass产品进行售卖，urule再开源部分的同时，也再卖着自己的高级功能，drools是一个纯开源的产品，如果想体验这种规则引擎可以直接去urule.bstek可以体验他的产品，不需要自行搭建。

作为完全版到底是怎么满足各种奇奇怪怪的规则场景呢？在这些规则引擎里面都会分为好几种规则设计器来满足你想要的规则场景：

  规则集：一组普通规则和循环规则构成的规则集合，是使用频率最高的一种业务规则实现方式。一般分为向导式：通过图形界面构成的；还有脚本式：通过自定义的DSL语言，类似我们下面会讲的jvm脚本规则引擎一样。