对于规则引擎技术的思考

    我们当前对规则引擎了解主要是开源的Drools项目，以及商用的ILog JRules，Fair Isaac等产品。目前也主要用于银行的授信、风险控制，保险的核保，医院排班等等环节。这些就是根据一些规则，在大量的数据中，找出符合条件的那些数据，然后进行风险控制。

    但是我们平时接触的项目中，都是实时的业务处理，都是把业务数据存入数据库，经过一定的处理，进行展现或者转化。因此很少会用到像银行风险控制这种逻辑，也就觉得规则引擎技术似乎没有什么用处。

    但是在平时的项目中，一般都采用分层的方式来实现，界面层、业务逻辑层、数据库层。我们看到规则引擎是将业务逻辑通过规则语言写在配置文件中，进行解析。那就应该也可以将平时我们用到的业务逻辑层中的逻辑也用规则引擎技术，采用规则语言来进行实现，最后来解析执行。

    如果这样实现的话，业务逻辑就可以程序进行了完全的分离，业务逻辑真正的脱离了程序。直接可以供业务人员进行修改。

    我们怀着这样的目的，去尝试使用Drools或者JRules等产品，却发现现实并不像我们想象的那么简单。

    首先，业务逻辑一般分离了数据库层，而我们日常的数据处理，相关的数据都存储在数据库中，这样当我们将数据准备好，传给规则引擎，最后再根据规则引擎的结果进行处理。发现这样做，使我们的工作变得更加复杂，而且我们发现将那些数据传给规则引擎进行处理以及怎么操作数据库的逻辑，这些都限定死了。而这些往往在业务逻辑发生变动时，也可能会发生变化。其结果是当我们碰到变动时，并不能简单的仅仅去修改规则，仍然需要去修改程序，这样感觉还不如原先用程序来实现。

    因此如果仅仅用规则引擎去实现业务逻辑，是不够的。但规则管理系统本身的特点又吸引着我们，比如规则可以直观的展现业务逻辑，规则修改后，不用重启服务器，直接应用，规则修改后，不用走程序变更流程，自动进行版本控制。因此我们应该有方法采用规则管理系统去满足我们项目中需求变更的问题。这就需要我们改良我们已经碰到的规则引擎技术。

    我们现实的需求是，当业务需求发生变动时，我们可以不改动程序，而直接修改规则，就能满足需求变更。

    因此应该需要规则引擎可以直接调用数据库中的数据，另外规则引擎与外部程序接口，不能是限定的，应该是可以扩充的。这些才是我们真正的需要。