规则引擎的介绍与Drools的流程分析

 
 

  
  
规则引擎(RuleEngine)是一个有限状态机，通过入参实现状态转移，在Java中定义为JSR94规范。规则引擎目前的开源实现主要是JBoss家族的Drools，采用友好的Apache协议(意味着可以作为商业产品)。以及据说非常贵的ILOG引擎，还有一些国内引擎。

  
  
1. 规则引擎的简介

  
  
规则引擎一般用于处理请求报文总类繁多，业务控制复杂的场景，比如某个订单入口，某个网络的控制域，某个路由，比如

  
  
决策业务(Decisiontable)，比如XX可以打折，XX可以立减多少，多少利率，风控等
关联推荐，比如XX符合大数据，给TA推荐一些产品广告
邮件分类/智能短信，比如华为手机分析短信的“智能情景”业务


  
  
在进行大型项目设计时，结合StackOverflow的问答，有如下实践

  
  
规则引擎处理的业务大部分应该是无状态的。请求报文为结构体，一般可以用正则表达式去处理。
规则引擎也可以用于处理有状态的业务。而业务规格一般涉及到查表、查定时器等操作，需要与请求规格进行分层，不要滥用Then，更不要阻塞主线程。
通过外部DSL(比如Regex, XML, Groovy/JRuby/Kotlin)实现高扩展性，降低新需求的硬编码(详见之前写的DSL编程技术的介绍)
不要过于高估RETE算法而把所有的非关联业务扔到一个引擎中进行for循环，而要及时设计出子规格目录(也就是人为设计一个Category)


  
  
2. 把Drools批判一番

  
  
2.1. Drools源码中如何生成rule与when？

  
  
首先下载Drools，然后配置MVN代理(我这里用的是Cow，折腾了好久)，运行mvn package下载依赖并编译后，然后使用Idea导入example，断点分析即可。本文使用的版本是Drools7

  
  
Drools使用了自己的drl语法，是一种DSL，通过ASM实现了它自己的Parser(ConsequenceGenerator)，在启动时将读取META-INF/kmodule.xml中的配置，并将drl反序列化为RuleImpl与JVM字节码。

  
  
DRL文件

  
  
rule BrokenWing @Defeasible @Defeats( "AllBirdsFly" ) when
      // Drools设计的DSL
    b : Bird(  )
    Broken( part == "wing", bird == b )
then
    // Java代码与Drools的内置函数
    insertLogical( new Fly( b ), "neg" );
end
  
  
生成的ByteCode(通过IDEA的断点Eval调用ClassGenerator.generateBytecode()与配置-Ddrools.dump.dir= ./)实现)
  
  
生成的Rule是这样的，虽然通过ASM生成了代码，但是IDEA目前无法调试此断点
  
  
public class Rule_BrokenWing185864016DefaultConsequenceInvokerGenerated implements Consequence, CompiledInvoker {
    private static final long serialVersionUID = 510L;

    public Rule_BrokenWing185864016DefaultConsequenceInvokerGenerated() {
    }

    public int hashCode() {
        return -505782175;
    }

    public List getMethodBytecode() {
          //详见下面的Class
        return RuleImpl.getMethodBytecode(this.getClass(), "Rule_BrokenWing185864016", "org.drools.examples.birdsfly", "defaultConsequence", "org/drools/examples/birdsfly/Rule_BrokenWing185864016.class");
    }

    public boolean equals(Object var1) {
        return var1 != null && var1 instanceof CompiledInvoker?MethodComparator.compareBytecode(this.getMethodBytecode(), ((CompiledInvoker)var1).getMethodBytecode()):false;
    }

    public String getName() {
        return "Rule_BrokenWing185864016DefaultConsequenceInvokerGenerated";
    }

    // 从getTuple中获取输入并执行`then`
    public void evaluate(KnowledgeHelper var1, WorkingMemory var2) throws Exception {
        LeftTuple var3 = (LeftTuple)var1.getTuple();
        Declaration[] var4 = ((RuleTerminalNode)var1.getMatch().getTuple().getTupleSink()).getRequiredDeclarations();
        Tuple var8 = var3.getParent();
        InternalFactHandle var6 = var8.getOriginalFactHandle();
        Bird var7 = (Bird)var6.getObject();
        Rule_BrokenWing185864016.defaultConsequence(var1, var7, var6);
    }
}
  
  
生成的then是这样的
  
  
public class Rule_BrokenWing185864016 {
    private static final long serialVersionUID = 510l;

    public static void defaultConsequence(KnowledgeHelper drools, Bird b, FactHandle b__Handle__   ) throws Exception {     
        RuleContext kcontext = drools;
        drools.insertLogical( new Fly( b ), "neg" );
    }
}
  
  
这种可读性非常差的DSL注定了Drool只是一个半成品，你只要用过了，你就马上明白
  
  
DRL语法奇特，过于接近AST，不亚于又学了一门新语言
生成代码过程是黑盒，而且代码中不能打断点
  
  
这两个缺点注定了Drools只是少数人的玩具，无法普及。
  
  
2.2. RETE算法与WorkingMemory
  
  
我们接着讲Drools的优点。它使用了 RETE算法，RETE是net的拉丁文，可以翻译为【网络算法】，英文好的可以参考这里，中文可以参考这里。它可以将多个“规则”编译生成一个AST，其中重复的条件编译到树的前面，不相同的校验编译到后面，实现最后For循环的叶子最少。
  
  
举个官网上的例子，定义了如下的规则
  
  
rule
  when
    Cheese( $chedddar : name == "cheddar" )
    $person : Person( favouriteCheese == $cheddar )
  then
    println( $person.getName() + " likes cheddar" );
end

rule
  when
    Cheese( $chedddar : name == "cheddar" )
    $person : Person( favouriteCheese != $cheddar )
  then
    println( $person.getName() + " does not like cheddar" );
end
  
  
RETE通过算法，将重复的条件放到最前面，最后生成如下的树
  
  
红色为AlphaNode表示字面意义上的对比，类似Java8中的Predicate<T>
黄色为LeftInputNodeAdapter, 表示节点的一对多转换，类似于flatmap<Predicate>操作
绿色为JoinNode，类似Java8中的Predicate<T>.and()操作
  
  

   
   
   
   

   
   

    
    RETE
   
   
  
  
  
  
具体RETE算法需要对RuleImpl进行FindUsage与断点分析，就分析到这里了。
  
  
2. 3. Drools的优与劣
  
  
Drools成也RETE算法，败也RETE算法。
  
  
Drools完美实现了RETE算法，如果用的好应该是循环次数最少的规则引擎。
Drools设计的DSL受限于RETE算法中需要合并条件的约束，Rule扩展性太弱，无法承载复杂业务。
  
  
3. 更好的规则引擎
  
  
某厂为运营商提供后台系统，运营商的套餐有多复杂大家都知道。
  
  
如何处理众多套餐的业务识别呢？
如果防止大规模规则名称冲突？
如何让运营商通过网页点点点就可以定制与配置业务呢？
  
  
如果你希望了解，欢迎私信或者邮件，走社招(深圳南京)内部推荐流程，成为人人羡慕的“外来的和尚”，我也能分点推荐奖。
  
  
4. SUM
  
  
需求决定架构，有可能客户/业务也不明白自己要什么，规则引擎从最开始的if-else到正则表达式，再到最后的Drools，经过很多次迭代才完善软件，因此要计算时间投入收益比，没必要强行用drl实现无码化，从网上的中文资料数量可以看出国内精通Drools的人也不是很多。硬编码/正则表达式也是一种方法。
如果真的想用于复杂业务，可以进行二次定制支持更加通用的JVM脚本，比如在for循环中调用ScriptEngine进行可配置动态化的规则(比如JS+JMX热部署)。
 
 

作者：BlackSwift
链接：http://www.jianshu.com/p/a9a4e2ebba3c
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。