1.2 为什么要使用规则引擎

在了解了什么是规则引擎，以及它能够解决什么问题之后，要理解为什么要使用规则引擎就变得简单了。本节重点从规则引擎的常见使用场景及简单的示例分析着手，来讲解使用规则引擎的原因、条件和场景。

1.2.1 规则引擎的使用场景

在技术交流的过程中，常常有刚入门的人提问：“我们这样的业务是否适合使用规则引擎？”如果你有同样的疑问，建议先根据现有的业务场景问一下自己：“我们为什么要使用规则引擎？它能为我们解决什么问题？又能给我们带来什么问题？”

可以明确的一点是，一旦引入了规则引擎，系统的复杂性会增加，如果是重量级的规则引擎，复杂性会增加得更多。Drools算是一个比较重量级的框架，它的引入不但会增加系统的复杂性，还会增加相关人员的学习成本。如果再与KIE Server、Business Central Workbench、Kogito等进行整合，学习成本将更高。

因此，在使用一款规则引擎前，首先要考虑现有业务场景面临的问题是否值得引入规则引擎，而不是如何引入。

规则引擎本质上就是将业务逻辑中变化的部分抽离成一系列规则，使得原本通过硬编码实现的业务逻辑分离为规则和数据，然后围绕数据和规则提供一些管理和处理功能。

规则也可以被理解为一种脚本，脚本通常会包含两部分：条件判断和行为执行。当满足条件判断时，会触发行为的执行。对照Drools的规则脚本，就是：when和then部分。其中，条件判断（when部分）相当于代码中的if判断，行为执行（then部分）就是符合判断之后所执行的业务逻辑，相当于满足if之后要执行的代码。

理解了规则引擎的基本实现逻辑之后，使用规则引擎的场景就很明确了：当系统中出现大量if…elseif…else…时，就可以考虑将这些判断抽离到规则引擎当中。

但在抽离的过程中还要思考一个问题：值不值得？并不是说只要有if…elseif…else…就适合用规则引擎，引入规则引擎还要满足以下两个前提条件：

❑ 复杂度高。业务流程分支非常复杂，判断变量庞大。

❑ 变化多。判断具有不确定性，变更频率较高，同时需要做出快速响应和决策。

思考一下：用户注册时，用户名、密码参数校验是否适合使用规则引擎？答案是：不适合。虽然在此过程中也会用到if…elseif…else…，也能用规则引擎来替代它们，但它们的业务复杂度不高，所以没必要引入规则引擎。

上面的两个前提条件只是供使用者判断的参考维度，并不是强制条件，也不是说必须同时具备才能使用规则引擎。比如，业务系统有大量的阈值判断，这些阈值判断虽然都很简单，但业务需要运营人员进行不定时的配置，同样也可以考虑使用规则引擎。

通俗地讲，之所以使用规则引擎，就是因为要解决频繁修改规则导致的低效问题。对于业务逻辑复杂或规则增长、变化迅速的场景，才需要将复杂多变的规则从硬编码中解放出来，以规则文件的形式存放，使得规则的变更不再或尽量避免以修改代码、重启服务的形式上线。

1.2.2 规则引擎的优缺点

规则引擎的优缺点也是选择规则引擎的重要参考指标。

Drools规则引擎的优点如下：

❑ 声明式编程：简化对复杂问题的逻辑表述和验证，提高逻辑的可阅读性。业务分析师和运营人员也可参与此部分操作。

❑ 逻辑和数据分离：业务逻辑原本分散在多个对象或服务当中，通过规则引擎可将业务逻辑抽离，放置于规则当中，通过一条或多条规则来呈现，既方便跨域关联逻辑，也方便集中管理和维护。分离的最终呈现形式为数据位于“域对象”中，业务逻辑位于“规则”文件中。

❑ 性能：基于增强的Rete算法，能够高效实现业务对象与规则的匹配。

❑ 可扩展性：规则的新增、修改变得容易，具有较强的可扩展性。

❑ 知识集中化：所有的规则逻辑集中于知识库当中，方便统一管理，同时也可对系统的整体规则进行鸟瞰。

Drools规则引擎的缺点如下：

❑ 系统复杂度：Drools规则引擎整体偏重量级，被引入之后，将规则与数据分离，新增的框架、系统交互等，都会增加系统的复杂度。

❑ 增加学习成本：要掌握规则语法、框架、集成以及规则管理系统，需要学习成本的投入。

❑ 引入新组件的风险：一旦新的组件被引入系统中，该组件自身的风险也成为整个系统的风险。

1.2.3 举例分析

下面举两个例子来说明规则引擎的使用场景，大家也可以参考上面提到的两个前提条件。

1.电商平台优惠

在电商的优惠活动当中经常会出现如下业务场景：今天可能全场满100元减10元，明天可能部分商品满100元送10元优惠券，后天可能调回原价。在这些满减过程中，不同等级的VIP会员还可能有不同的额外折扣。

想象一下上面的业务场景，随着优惠维度的增多，判断的工作量会成倍增长，此时业务已具备一定的复杂度，简单的if…elseif…else…或数据库配置参数阈值已经无法满足业务需求。另外，这种优惠活动的时效性往往极强，变化具有快速和不确定性。如果每次都经过一个完整的需求、开发、测试、发布的流程，不仅会浪费资源，也会带来时效性问题。所以，此场景适合使用规则引擎。

2.风控系统

以金融或借贷的风险控制（简称风控）系统为例。在此类系统中重点要把控两个因素：人和交易。不同的人有不同的信用等级，也就对应不同的借贷或交易额度。风控系统把控的便是不同人的交易行为，也就是说对于风控系统来说，输入的业务数据是基本不变的，而业务规则、政策、风控模型等会随时发生变化。

这种基于有限输入拓展无限规则模型的场景，非常适合使用规则引擎。以此种场景中用户信用评级为例，当新用户加入，输入证件、年龄、收入等基本信息之后，通过各项数据的权重便可给用户一个初始的信用等级。随着交易行为的发生，信用等级可能有所增减，进而随着信用等级的增减，用户的日交易限额、单笔交易限额、月累计交易限额等都会发生变化。

在上述过程中，用户初始信用等级评定时各项数据的权重可能会随着业务数据的分析、反馈进行变化和调整，用户信用等级与交易之间的关系也会随着平台整体业务数据的分析而变动。特别是通过各个维度以及历史交易情况来分析和预测用户的当前交易是否有风险，判断是否需要进行阻断等操作，都离不开规则引擎。

除了上述电商平台优惠和风控系统两个场景外，规则引擎在实践中还会用于IoT（物联网）、保险、消费贷、财务计算、日志分析处理等业务场景。