1.3 规则引擎的使用流程

上面我从概念和使用场景的维度介绍了规则引擎，这一节介绍规则引擎的使用流程及其可以带来的方便之处。

在未使用规则引擎的情况下，改动业务逻辑的基本步骤如图1-1所示。

图1-1 未使用规则引擎时改动业务逻辑的基本步骤

图1-1也可视为一个新功能开发的基本流程，不同的公司或项目组可能会有更复杂、更严格的新功能开发上线流程。在没有使用规则引擎时，一般公司或项目组合按照一个项目发布流程来更新规则。

当引入规则引擎之后，新需求的处理流程会有两种情况：初次新增规则和修改已有规则。这里的初次新增规则不仅包括从无到有的过程，也包括传入的业务数据（在Drools中也称作Fact对象、事实对象，它就是一个承载业务数据的普通JavaBean）已无法满足现有规则的情况，需要修改或新增Fact对象的场景。

以前文的用户信用评级为例。起初以用户的证件、年龄、收入等数据的权重评定用户信用等级，随着业务的发展，需要增加一个固定资产（比如持有房产）数据，而且此数据所占权重还比较大，这会导致其他数据的权重发生变化。初次新增规则的操作流程如图1-2所示。

在图1-2中，新增规则的过程涉及规则脚本的编写、发布等工作。在实践中，以Drools为例，一旦修改了原始的Fact对象，那么规则中对应的Fact对象也需要修改。也就是说，业务系统和规则引擎的规则需要同时修改和发布。由于系统架构不同，因此其操作流程也并不一定像图1-2那样按照严格的线性顺序。如果给运营人员提供了规则管理页面，在该流程中可能还需要同时修改规则管理的部分页面。

图1-2 初次新增规则的操作流程

表面上整个业务系统的开发、发布流程变得复杂了，但这只是因为涉及了新增业务维度。业务维度稳定后，规则再发生变化，相应操作流程就简单很多。

修改已有规则的操作流程如图1-3所示，开发和发布业务系统的步骤没有了，取而代之的是规则脚本的修改与发布。图1-3中还有开发人员参与，如果只是修改现有规则的一些条件或条件的组合，大多数情况下不需要开发人员参与。

图1-3 修改已有规则的操作流程

其中，规则脚本的修改与发布往往是通过独立的规则管理平台来操作的，并不影响核心业务系统。图1-3中操作规则脚本的是开发人员，如果系统中规则管理平台设计得足够人性化，运营人员经过简单培训，便可直接修改、发布规则。此时，规则引擎的灵活性发挥到了极致，支持随时修改规则并发布，而不用修改业务系统代码和发布业务系统。