️This article has been over 2 years since the last update.
规则引擎(RuleEngine)是一个有限状态机,通过入参实现状态转移,在Java中定义为JSR94规范。规则引擎目前的开源实现主要是JBoss家族的Drools,采用友好的Apache协议(意味着可以作为商业产品)。以及据说非常贵的ILOG引擎,还有一些国内引擎。
1. 规则引擎的简介
规则引擎一般用于处理请求报文总类繁多,业务控制复杂的场景,比如某个订单入口,某个网络的控制域,某个路由,比如
- 决策业务(Decisiontable),比如XX可以打折,XX可以立减多少,多少利率,风控等
- 关联推荐,比如XX符合大数据,给TA推荐一些产品广告
- 邮件分类/智能短信,比如华为手机分析短信的“智能情景”业务
在进行大型项目设计时,结合StackOverflow的问答,有如下实践
- 规则引擎处理的业务大部分应该是无状态的。请求报文为结构体,一般可以用正则表达式去处理。
- 规则引擎也可以用于处理有状态的业务。而业务规格一般涉及到查表、查定时器等操作,需要与请求规格进行分层,不要滥用Then,更不要阻塞主线程。
- 通过外部DSL(比如Regex, XML, Groovy/JRuby/Kotlin)实现高扩展性,降低新需求的硬编码
- 不要过于高估RETE算法而把所有的非关联业务扔到一个引擎中进行for循环,而要及时设计出子规格目录(也就是人为设计一个Category)
2. 把Drools批判一番
2.1. Drools源码中如何生成rule与when?
首先下载Drools,运行mvn package
下载依赖并编译后,然后使用Idea导入example,断点分析即可。本文使用的版本是Drools7
Drools使用了自己的drl语法,是一种DSL,通过ASM实现了它自己的Parser(ConsequenceGenerator),在启动时将读取META-INF/kmodule.xml
中的配置,并将drl反序列化为RuleImpl与JVM字节码。
DRL文件
1 | rule BrokenWing when |
生成的ByteCode(通过IDEA的断点Eval调用ClassGenerator.generateBytecode()
与配置-Ddrools.dump.dir= ./)
实现)
生成的Rule
是这样的,虽然通过ASM生成了代码,但是IDEA目前无法调试此断点
1 | public class Rule_BrokenWing185864016DefaultConsequenceInvokerGenerated implements Consequence, CompiledInvoker { |
生成的then
是这样的
1 | public class Rule_BrokenWing185864016 { |
这种可读性非常差的DSL注定了Drool只是一个半成品,你只要用过了,你就马上明白
- DRL语法奇特,过于接近AST,不亚于又学了一门新语言
- 生成代码过程是黑盒,而且代码中不能打断点
这两个缺点注定了Drools只是少数人的玩具,无法普及。
2.2. RETE算法与WorkingMemory
我们接着讲Drools的优点。它使用了 RETE(/ri:ti/)算法,RETE
是net
的拉丁文,可以翻译为【网络算法】,英文好的可以参考这里,中文可以参考这里。它可以将多个“规则”编译生成一个AST,其中重复的条件编译到树的前面,不相同的校验编译到后面,实现最后For循环的叶子最少。
举个官网上的例子,定义了如下的规则
1 | rule |
RETE通过算法,将重复的条件放到最前面,最后生成如下的树
- 红色为
AlphaNode
表示字面意义上的对比,类似Java8中的Predicate<T>
- 黄色为
LeftInputNodeAdapter
, 表示节点的一对多转换,类似于flatmap<Predicate>
操作 - 绿色为
JoinNode
,类似Java8中的Predicate<T>.and()
操作
具体RETE算法需要对RuleImpl
进行FindUsage与断点分析,就分析到这里了。它本质上是生成了一个Trie,比较类似于ElasticSearch中的NGram的Autocomplete,但是Elastic中通过分词来合并相同的字段,而RETE中通过DSL中提供的函数以维护Tokenizer并按照权重排序。
2. 3. Drools的优与劣
Drools成也RETE算法,败也RETE算法。
- Drools完美实现了RETE算法,如果用的好应该是循环次数最少的规则引擎。
- Drools设计的DSL受限于RETE算法中需要合并条件的约束,Rule扩展性太弱,无法承载复杂业务。
个人观点:我们在引入Drool后,由于语法表达能力弱,很难进行大规模/外包化开发(项目太庞大了,Drools的质量无法控制),最终还是牺牲性能(用更多的for循环+手动维护重要分支)把它换掉了。
3. 更好的规则引擎
某厂为运营商提供后台系统,运营商的套餐有多复杂大家都知道。
- 如何处理众多套餐的业务识别呢?
- 如果防止大规模规则名称冲突?
- 如何让运营商通过网页点点点就可以定制与配置业务呢?
如果你希望了解,欢迎联系加入,我们不996加班。
4. SUM
需求决定架构,有可能客户/业务也不明白自己要什么,规则引擎从最开始的if-else到正则表达式,再到最后的Drools,经过很多次迭代才完善软件,因此要计算时间投入收益比,没必要强行用drl
实现无码化,从网上的中文资料数量可以看出国内精通Drools的人也不是很多。硬编码/正则表达式也是一种方法。
下面是我个人的推荐选型流程
- 复杂的企业级业务(上百人开发团队): 在for循环中调用ScriptEngine执行Groovy/Ruby实现可配置动态化的规则,开发工作量可外包,代码表达业务能力强;缺点就是贵,需要中间件团队来支撑实现。
- 中等复杂度业务(20~100人):建议Drools或者开源的Easy Rules。如果是基于NodeJS团队,可以选择Nools作为工具,这个也实现了rete算法。缺点上面也讲了,表达能力弱,门槛高,需要团队人均水平较强。
- 硬件编码/字符串解析/算法: 这里大部分是数据清洗流程,直接用正则表达式,或者ELK中的Grok/Logstash,最小编辑距离等方法,想要自己复杂实现的可以用LL Parser进行解析
- 领域业务语言(DSL)编解码: 建议直接转换为AST进行分析,这个在半导体/IC设计等工具中非常广泛。