了解JBoss Drools Engine

说一个自己比较喜欢的开源产品JBoss Drools, 很多企业内部大型项目都在使用的规则引擎
该怎么理解规则引擎，到底是个什么东西，我好像没听过，我们能用么。

它是配有内置算法及对应数据结构的计算容器，在容器内部可以写我们的业务规则或计算规则。这套算法在规则引擎内的规则数爆增的情况下，可保计算速率不会有明显影响。 光是这点，就足够有吸引力。自己纯写代码不能避免这个问题。举个例子，比如有一个场景根据受保人的信息及车况信息来计算他下一年要交多少车险。略想一下，这个问题很简单么，就是建一个Java Pojo Bean Customer类，然后去针对这个Customer类的各个属性值在哪个区间内给出对应的车险金额。那我们可以这样写：
if((customer.getAge>24||customer.age<40)and (customer.getLoyaltyLevel()==Rang.GOLD) and (customer.getCarAge()<5) and customer.getCarCrashed()==0)
{
    payment = 2000;
}
else if(...)
else if(...)
else if(...)
...
else
{

}

好，当我们写了十几、二十个的else if，这条业务才写完，然后也没错，我们意大利式面条的代码就出现了，看着有木有好揪心，有密集恐惧症的童鞋就碰也不想碰这套业务了。
那这种写法的大O记号为O(n)，但如果这些业务规则写在规则引擎内，它的大O记号一定是O(1)<x<O(n)，而且很有可能无限趋近于O(1)，这是因为Drools engine的ReteOO+Phreak算法，可以做Node Index, Node Sharing, 对某些运算符优化，消除无用的部分匹配等等。这就是为什么规则数爆增的情况下，计算速率不会有明显影响。有兴趣可以去看看这两个算法。

那更多的业务情况不会有这么简单，更多的是几套子业务规则拼成一个完整的业务，一般情况是，先从前面的子业务规则做收纳，把可能有效的信息放在一个集合内。那在后面的业务规则再去把这个集合内的对象遍历一遍做减法，该修改的修改，该移除移除的。然后得出一个最优解。那代码就变成if()else if()...else() + for(if()else if()...else())...，好吧，这又是一份意大利面。说好编程是门艺术呢？怎么编程变成意大利面烹饪技？？？

Drools的规则语法是声明式的，不是解释式的。只要把每个业务规则写进去，把要计算的对象放进Working Memory中，规则引擎自己帮咱们算，我们不需要写if else，不需要写for或while。因为Drools的Working memory中的每个对象会被自动的去匹配所有的规则，它内部的事情就交给Drools的算法吧。我们只要告诉它有什么样的业务规则就好。Just care what to do, don't worry how to do.

有一次在我把基于Drool写出来的项目给一客户看，他面露喜色，这东西很巧嘛。 嘿嘿，灵巧之处还不仅仅在于此。
它能线上修改业务规则，不需要启停服务。在Drools中，业务规则没有放在Java代码内，是以单独的文件形式存放，比如drl(其实是txt)、csv、excel。业务与代码，业务与数据分离了。只要咱们的Model没变，只变业务规则，我们就不用修改代码，比方说，正好感上公司十周年庆，全场5折，仅限本周。这个需求一下来，我们就得开始去屡我们的意大利面，然后找到修改的地方，改完以后发QA测，产品人员验收，打包上线。 然而在Drools中，负责产品的人员就可以直接做了，不需要开发人员及QA的介入。有时候产品和开发、QA得解释半天要上线的规则，开发和QA才能听明白。这一套流程下来，一两天去了。如果产品自己做，几分钟或半小时就能搞定。 在互联网+的今天，时间就是市场。

有些人可能觉得这是不是有点夸张，其实真的可以，我们只需要为产品做一个规则管理的Web系统，这套管理系统能检索到所有的规则，并能增删改查及仿真。只有产品不要求开发改数据模型，就真心没开发QA什么事了。有人说，如果我把规则直接放数据库就好了，为什么还要用Drools？很好，但是您要加的规则不是模板化的怎么办？如果是多个对象协同计算怎么办？您是不是要去修改表结构？您也别忽略了Drools 算法的可优化性及潜力。

说了Drools这么多好处，它的缺点也不能不谈，它既然内置了一套算法和数据结构，说明它就是有开销的。它能把Java代码以外的规则文件并入到JVM内一起协作，也是有开销的。但是这些开销是只是业务规则小，计算量小的时候才能体现出来是个问题，如果业务规则复杂和计算量大可以靠它的算法去优化，它的价值就体现出来了。而且这些开销仅仅是在规则加载的时候比较明显。 要不说架构是演变出来的，从来就没有一颗银弹。但是在内存这么便宜的今天，Drools这么点开销真算不上什么 。
所以不是所有的应用都适合用它，如果只有一个或几个简单的规则还是不要用了，为了几个简单的业务去学习一个新产品，不值当。它适合比较复杂的业务及业务规则需要实时修改的，它能帮上很多忙。

这里只讲了Drools Engine的粗枝大叶，Drools 还有其它的组件，下次再聊。