1 业务分析
1.1 现状
在很多行业应用中比如银行、保险领域，业务规则往往非常复杂，并且规则处于不断更新变化中，而现有很多系统做法基本上都是将业务规则绑定在程序代码中。
1.2 问题
主要存在的问题有以下几个方面：
1） 当业务规则变更时，对应的代码也得跟着更改，每次即使是小的变更都需要经历开发、测试验证上线等过程，变更成本比较大。
2） 长时间系统变得越来越难以维护。
3） 开发团队一般是由一个熟悉业务的BA（业务分析人员）和若干个熟悉技术的开发人员组成，开发人员对业务规则的把握能力远不及BA，但实际上却承担了将业务规则准确无误实现的重任。
4） 系统僵化，新需求插入困难。
5） 新需求上线周期较长。
1.3 解决方案
能否让我们的业务系统更灵活一点呢？
思路：将业务规则从技术实现中提取出来，实现技术和业务分离，开发人员处理 技术、业务分析人员定义业务规则，各自做自己所擅长的事情。
方案：目前已经有比较成熟的开源产品支持，这就是本文所要介绍的Drools，我们将业务规则定义在Database或者BRMS(Business Rule Management System)中，通过管理DB或者BRMS实现业务逻辑的动态改变。
1.4 适用情景
什么时候应该使用规则引擎？
虽然规则引擎能解决我们的许多问题，但我们还需要认真考虑一下规则引擎对我
们的项目本身是否是合适的。需要关注的点有：
我的应用程序有多复杂?
对于那些只是把数据从数据库中传入传出，并不做更多事情的应用程序，最好不要使用规则引擎。但是，当在Java中有一定量的商业逻辑处理的话，可以考虑Drools的使用。这是因为很多应用随着时间的推移越来越复杂，而Drools可以让你更轻松应对这一切。
我的应用的生命周期有多久？
如果我们应用的生命周期很短，也没有必要使用Drools，使用规则引擎将会在中长期得到好处。
我的应用需要改变吗？
这个答案一般情况下是肯定的，“这世界唯一不变的只有变化”，我们需求也是这样的，无论是在开发过程中或是在开发完成以后，Drools能从频繁变化的需求中获得好处。
规则引擎是一种推理引擎，它是根据已有的事实，从规则知识库中匹配规则，并处理存在冲突的规则，执行最后筛选通过的规则。因此，规则引擎是人工智能（AI）研究领域的一部分，具有一定的选择判断性、人工智能性和富含知识性。目前，比较流行的规则引擎有商业规则引擎 iLog 和开源规则引擎 drools。本文将对开源规则引擎 drools 做详细介绍，并通过分析一个在汽车保险行业中的实际应用案例，让读者对开源规则流引擎有一个更深刻的理解。
2 什么是规则引擎
规则引擎是基于规则的专家系统的核心部分，主要由三部分组成：规则库(Knowledge base)+Working Memory(Fact base)+推理机(规则引擎)，规则引擎根据既定事实和知识库按照一定的算法执行推理逻辑得到正确的结果。
3 Drools简介
Drools 是一个基于Charles Forgy's的RETE算法的，易于访问企业策略、易于调整以及易于管理的开源业务规则引擎，符合业内标准，速度快、效率高。
业务分析师人员或审核人员可以利用它轻松查看业务规则，从而检验是否已编码的规则执行了所需的业务规则。
在 Drools 中，规则被存 放在 Production Memory（规则库）中，推理机要匹配的 facts（事实）被存在 Working Memory（工作内存）中。当时事实被插入到工作内存中后，规则引擎会把事实和规则库里的模式进行匹配，对于匹配成功的规则再由 Agenda 负责具体执行推理算法中被激发规则的结论部分。
4 竞争产品比较
与Drools功能类似的同类开源产品主要有：OpenRules、OpenLexicon等，商业产品功能比较强也比较贵，这里不做比较，主要差别如下表：
