在规则引擎出现之前,许多企业建立IT团队,由他们接受来自业务部门的需求,提炼出业务规则并将其转化为代码写入到程序中。这种模式的产生是非常自然的,因为业务规则总是可以表达为If…Then…的逻辑表达式,而这种基本的逻辑表达式在各种程序语言中是必然存在的。但是随着公司业务的迅速发展,这种方式很快就会受到巨大的挑战,这种挑战主要来自两方面。
首先,调整业务规则需要进行大量的检查。越来越多的业务部门会提出需求,每次的变更和调整都要求IT团队重新审视所有的代码,确保逻辑的一致性和准确性,这种检查的工作量是非常巨大的。为了保证程序的可靠性,IT团队还需要对变更后的程序进行大量的测试,排除各种可能的Bug。
其次,规则的执行效率非常低下。当业务规则是以If…Then…的方式嵌入在代码中,程序需要顺序地逐条执行完所有的规则才能获得最终的结果。假设程序中存在100条业务规则,每条规则需要1s的执行时间(不考虑IO),那么一次规则集的检查和执行需要花费100s。 当然,如果可以将规则集以矩阵的方式进行计算判别(相当于进行并行计算),那么规则集的整理执行时间可以缩短到接近单条规则的时间(忽略使用矩阵运算的额外开销)。但是一个企业的业务规则通常不会那么简单,这里需要引入“推断(Inference)规则”的概念。如果A规则的结果是B规则的执行条件,那么B规则为推断规则,或者说B规则的执行与否依赖于A规则的执行结果。由于推断规则的存在,使得直接使用矩阵并行执行所有规则变得不可能,因为有些规则的执行条件一开始是”未知“的。因此程序中需要存在循环检查的机制:一旦有规则成功运行,那么程序需要检查所有的规则,看是否有新的规则可以被执行。可以容易的看出,这种检查-执行的方