[置顶] 旗正规则引擎设计思路

    很多人都有疑惑，既然已经有很多成熟的规则引擎产品，并且开源的规则引擎产品也有很多，应用也很广泛，又何必去搞一个商业的规则引擎产品呢。在国内的环境下，并不认同这类商业的中间件产品，特别是国产的。

    但是国际上的规则引擎产品实在太贵，因此旗正最初的想法也是希望能够使用开源的规则引擎产品进行改造。

    规则引擎有一套约定俗成的标准，就是基于rete算法。特别是出来了JSR94标准之后，虽然说JSR94标准中只是约定了接口，并没有规定算法。但是JSR94标准的接口是事实上承认了基于rete算法的实现机制的一种应用。因此很多时候会感觉没有rete算法好像就不是规则引擎产品一样。很多规则引擎厂商从一开始介绍自己产品，都是先介绍rete算法的原理，以及说明自己的算法有多么先进。

    按照这些通用标准，旗正也走了很长时间的弯路。利用开源的规则引擎来实现rete算法，然后在此基础上，制作规则编辑器。但是做了这些扩展之后，发现基于rete算法的规则引擎是非常的不灵活。应用面也很小，特别是在一些通用的管理系统中，根本就没有什么用武之地。而且性能也很差，异步调用时经常出现资源共享的问题。

    因此在此前提下，不得不对规则引擎的算法本身进行改进。经过长时间的实践之后发现，其实没有rete算法的规则引擎反而更好。很多国际上的产品，其实都类似的使用了没有rete算法的规则引擎，但是并没有冠以规则引擎产品在单独销售。因此旗正公司最终决定研发没有rete算法的规则引擎。

    在此前提下，发现其实规则引擎的路更宽了，而且在性能、应用面、易用性等各方面都可以比一般的规则引擎产品做得更好。

    经过长时间的产品研发和项目应用之后，回过头发现其实不采用rete算法的决策是正确的，虽然说这需要挑战国际标准的权威，但毕竟事实证明了不采用rete算法的规则引擎更好用，也更加实用。

    由于原理的不同，与采用rete算法的引擎相比，以下一些指标优势非常明显：

    1、性能：比采用rete算法的规则引擎，速度至少快100倍，特别在批量的数据处理性能上。同时消耗的内存以及CPU资源更好。

    2、易用性：由于不采用rete算法，这样制作更多可控的规则配置界面，在操作界面的制作上，更加灵活。而且不采用rete算法，就不用培训和理解此算法，因此学习曲线也更低。

    3、应用面：基于rete算法的规则引擎，基本上还是只适用推理类的规则。对于数据校验、数据预处理、数据存取、数据转换等规则，却根本不能用。而不采用rete算法的规则引擎，也可以来配置这些规则，这样使得应用面也更广。

    如果希望将系统中涉及的业务规则全部采用规则引擎来进行管理，那么rete算法将是一个障碍。摒弃rete算法，提高实用性，是规则引擎产品研发正确的方向。