前言

规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。–来自百度百科

这个定义我感觉比较清晰了，但是我们做的不一定要有推理模块。如果只是互联网化的简单规则执行，其实不需要推理，也能做到非常高的性能。，本文就介绍规则引擎的基本概念。

一、为什么要使用规则引擎？

1.不使用规则引擎的规则执行现状

if(f1){
	if(a||b||c||d)
}
if(f2){
}
if(a&b&d){
}

优点	缺点
当规则较少、变动不频繁时，开发效率非常高。	规则迭代成本高：对规则的少量改动就需要走全流程（排期，开发、测试、部署）。
稳定性较佳：语法级别错误不会出现，由编译系统保证。	当存量规则较多时，可维护性差。
没有外部依赖，执行速度很快	规则开发和维护门槛高：规则对业务分析人员不可见；没有规则效果分析，很难感知规则的效果。

2. 规则引擎优点

规则的变更非常方便，从而实现业务规则的随需应便。
业务规则与系统代码分离，实现业务规则的集中管理。
在不重启服务的情况下可随时对业务规则进行扩展和维护。
可以动态修改业务规则，从而快速响应需求变更，大大提高了对复杂逻辑代码的可维护性。
规则引擎是相对独立的，只关心业务规则，使得业务分析人员也可以参与编辑、维护系统的业务规则。
减少了硬编码业务规则的成本和风险。
使用规则引擎提供的规则编辑工具，使复杂的业务规则实现变得简单。

二、规则引擎的功能

规则配置-可视化
脚本语言编写规则
规则优先级执行
可视化规则流
版本发布，回滚
灰度发布
评分卡
决策表
决策树
黑白灰名单
标签管理
可视化决策流编辑
规则监控
用户权限管理
AB测试
冠军挑战
规则效果分析
本地化(和业务系统在一个进程中)和服务化(单独部署)

应用场景
对于一些存在比较复杂得业务规则并且业务规则会频繁变动的系统比较适合使用规则引擎。

风险控制系统----风险贷款、风险评估
反欺诈项目----银行贷款、征信验证
决策平台系统----财务计算
促销平台系统----满减、打折、加价购等等
典型场景-信用卡授信

三、规则引擎的分类实现

1.事中规则实现

规则配置，规则配置系统，主要是对一些表达式进行封装。然后将表达式交给规则解析程序/库
规则下发，规则建立好了之后实现规则下发，规则下发的方案有很多，可以根据自己系统要求进行实现，比如：

规则执行
规则引擎关注的是时延，不能进行跨进程调用问题，尽量不访问数据库和外部内存，直接使用机器内存
规则较多，尽量使用并行执行，不如有依赖，可以分析依赖树，然后并行执行

2.事后规则实现

主要通过大数据技术栈对多数据源数据在Hive中进行聚合，对于执行实现可以接收一定的延迟，或者采用流式处理降低时延
对于一些时间窗口的处理，使用flink进行聚合

四、规则引擎调研

1.开源规则引擎

JBoss Drools
Mandarax
OpenRules
JEOPS
InfoSapient
Roolie
Apache Camel

2.商业规则引擎

ODM(ILOG)
Oracle Business Rules
旗正规则引擎
Jess（可研究，商用收费）
TopRules
明策智能决策
Blaze
益博睿决策引擎

五、Drools

Drools 是用 Java 语言编写的开放源码规则引擎，使用 Rete 算法对所编写的规则求值。Drools 允许使用声明方式表达业务逻辑。可以使用非 XML 的本地语言编写规则，从而便于学习和理解。并且，还可以将 Java 代码直接嵌入到规则文件中，这令 Drools 的学习更加吸引人。

优点

非常活跃的社区支持
易用
快速的执行速度
在 Java 开发人员中流行
与 Java Rule Engine API（JSR 94）兼容
缺点

业务分析师无法独立完成规则配置：由于规则主体DSL是编程语言（支持Java, Groovy, Python），因此仍然需要开发工程师维护
规则规模变大以后也会变得不好维护，相对硬编码的优势便不复存在
规则的语法仅适合扁平的规则，对于嵌套条件语义（then里嵌套when…then子句）的规则只能将条件进行笛卡尔积组合以后进行配置，不利于维护。