问题的提出

假设这样一个场景：

某公司生产两种型号的设备，M{m1,m2}，两种型号都支持四种功能F{f1,f2,f3,f4}，但开放哪些功能取决于出厂设置。在出厂之前需要对设备进行多方面的测试，目前定义了五种测试T{t1,t2,t3,t4,t5}，要执行哪些测试取决于型号。对每台设备的每种测试都有一个最晚执行日期D的要求，D取决于设备要执行的测试项。

由于业务需要，每种型号的设备要进行哪些测试、D与要执行的测试项的关系会经常变化。比如其中的一组规则是：

测试项规则：

if m=m1, exec(t1,t2,t5)

if m=m2 and m.hasfunction(f1), exec(t2,t3)

if m=m2 and m.hasfunction(f2), exec(t4,t5)

if m=m2 and m.hasfunction(f3), exec(t3,t4)

if m=m2 and m.hasfunction(f4), exec(t1,t3)

测试时间规则（其中d表示天数，如3表示最晚执行日期为3天后）按照优先级从高到底如下：

if m.todo(t1), d=3

if m.todo(t2),d=7

if m.todo(t3),d=10

if m.todo(t4),d=12

if m.todo(t5),d=14

 

要实现的功能是，根据给定的规则和一组设备，得出每个设备的测试项和测试时间。

 

即使不考虑规则的变化，要实现这样的业务规则也是非常繁琐和乏味的。而为了避免频繁的部署，规则必须能够以某种形式进行定义和配置，不能硬编码实现。（当然，如果你采用OSGI架构，定期更新规则的bundle我也无话可说）。

推理机和规则引擎

上面例子中的问题是典型的推理问题：根据已有的知识，分析实际情况并给出结论。如果由程序来处理推理过程，那么这个程序就叫做推理机/推理引擎（Inference Engine）。推理机是专家系统（专家系统是人工智能的一个分支）的核心模块。

 

推理引擎根据知识表示的不同采取的控制策略也是不同的，常见的类型包括基于神经网络、基于案例和基于规则的推理机。其中，基于规则的推理机易于理解、易于获取、易于管理，被广泛采用。这种推理引擎被称为“规则引擎”。

在规则引擎中，将知识表达为规则（rules），要分析的情况定义为事实（facts）。二者在内存中的存储分别称为Production Memory和Working Memory，如下图：

rules和facts是规则引擎接受的输入参数，而规则引擎本身包括两个组成部分：Pattern Matcher和Agenda。Pattern Matcher根据facts找到匹配的rules，Agenda管理PatternMatcher挑选出来的规则的执行次序。在外围，还会有一个执行引擎（Execution Engine）负责根据Agenda输出的rules执行具体的操作。

其中Pattern Matcher是规则引擎负责推理的核心。和人类的思维相对应，规则引擎中也存在两种推理方式：正向推理（Forward-Chaining）和反向推理（Backward-Chaining）。

正向推理也叫演绎法，由事实驱动，从 一个初始的事实出发，不断地应用规则得出结论。首先在候选队列中选择一条规则作为启用规则进行推理，记录其结论作为下一步推理时的证据。如此重复这个过程，直到再无可用规则可被选用或者求得了所要求的解为止。

反向推理也叫归纳法，由目标驱动，首先提出某个假设，然后寻找支持该假设的证据，若所需的证据都能找到，说明原假设是正确的；若无论如何都找不到所需要的证据，则说明原假设不成立，此时需要另做新的假设。

 

规则引擎是一种相对简单的推理机，可以将规则引擎作为一种组件潜入到应用系统中，从而将业务决策从应用程序代码中分离出来，并使用预定义的规则语言编写业务决策。使用规则引擎带来的好处是：

1. 避免业务规则变化带来的重新编译和重新部署的问题；

2. 使用声明性编程方法，大大提高业务规则代码的可读性；

3. 开发人员不需要过多关注业务逻辑（根据各种情况判断发生了什么事情），可以专注于应用逻辑（在发生了什么事情时进行什么样的处理）