下载掌阅APP，畅读海量书库
立即打开
对于软件开发或产品人员来说，唯一不变的就是变化。市场在变，用户群体在变，用户行为在变，软硬件设备环境在变，系统风险因素在变，甚至“羊毛党”薅“羊毛”的方式也在变。面对这么多不断变化的因素，我们可以将一部分变化限定在一定范围内，将业务逻辑抽象为规则，与数据分离，形成特定的解决方案。用来管理和执行这些规则的系统，可称为“规则引擎”。
本章重点从以下方面介绍规则引擎：规则引擎的使用场景、规则引擎的基本使用流程、规则引擎家族（含Drools规则引擎家族）以及Drools规则引擎的主要版本。其中，前两项要重点关注，它们是技术选型和使用规则引擎的理论依据，决定了如何在项目中更好地使用规则引擎，以及如何更好地制作具体的规则。
世界运作皆有规则。以生活中的规则为例：过马路，要遵守交通规则；工作中，要遵从公司制度；家庭中，要遵从道德规范……
不同的人可选择不同的做法——遵守或不遵守规则，对应的选择就是具体的“决策”。如果选择遵守规则，可能的结果是自己和他人的人身安全得到保障、升职加薪、获得道德荣誉；反之，可能就会面临安全风险、事业失败、受到道德谴责。
面对形形色色的规则，不同的人有不同的决策，而不同的决策必然会得到不同的结果，这一系列场景、规则、参与者的决策、结果等便构成了规则引擎的整个运作过程。
在领域模型中，常见的做法是基于面向对象的编程思想，将业务逻辑抽象为对象、对象的属性和对象的方法。这个做法有一个明显的特征，那就是规则与业务系统是完全耦合的，你中有我，我中有你。一旦涉及规则的修改，必然引起软件工程的全流程操作（代码编写、测试覆盖、上线发布等），最直观的影响就是投入成本增加、效率变低。为了解决这类问题，规则引擎产品及相应的技术框架应运而生。
在软件世界中，最多的便是“是与非”“0和1”的判断，每个业务分支该如何走，如何处理，会有怎样的结果，都是通过业务规则来判断、处理和展示的。
面对简单的或相对固定不变的判断，我们通常通过if…else…逻辑判断来处理。但如果某部分业务逻辑随时都可能变化，或者说在频繁地变化，依旧采用这种传统模式来处理，那么面临的将是频繁的代码改动与系统发布。
这对企业运营、开发团队，甚至客户都意味着成本和折磨。那么是否可以将变化的部分抽离，当需要改变规则时只需要简单地修改一些参数或少量修改代码，即可完成业务规则的变更呢？
当然可以，规则引擎便是为解决此痛点而生的，同时出现了不同的技术解决方案，其中一种解决方案便是本书的主角——Drools规则引擎。
Drools是最早由JBoss开发、目前由Red Hat开源的规则引擎，属于Red Hat的KIE Group组件之一，可以比较方便地与Red Hat的其他产品集成。比如，可以与jBPM工作流相结合实现对复杂规则流的管理。另外，它也可以与机器学习（Machine Leaning，ML）、深度学习（Deep Leaning，DL）等外部类库相整合，实现Pragmatic AI相关功能。
Drools基于Java语言编写，是市面上主流的开源规则引擎框架。Drools的推理策略算法（Phreak规则算法）在经典的Rete算法上进行升级和增强，算法成熟，可以高效匹配规则。Drools允许使用声明方式表达业务逻辑，可以使用非XML（可扩展标记语言）的本地语言编写规则，既便于学习和理解，也便于业务人员查看和管理规则。同时，它还可以直接将Java代码嵌入规则文件当中，给开发人员提供了极大的便利。
通过Drools规则引擎，可以将复杂多变的业务规则抽离到Drools支持的存储介质（数据库、文本文件、JAR包等）当中。需要改变业务逻辑时，只需修改存储介质中的逻辑判断，便可达到快速修改业务规则且避免频繁发布系统的效果。
Drools官方除提供了规则引擎的核心功能外，还提供了一系列基于该开源框架的组件（KIE Server、Business Central Workbench、Kogito等），便于使用者直接集成使用。同时它还支持多种形式的规则构建，可根据客户的具体需要灵活生成、管理规则。
在Drools 6.x、7.x版本中，Drools的规则管理系统（Business Central Workbench）提供了可视化的操作界面，运营人员可直接通过界面来修改规则、发布规则及完成其他操作，从而减少开发、运营成本，提升效率。在Drools 8.x中以Kogito替代了KIE Server和Business Central Workbench相关的功能。
虽然本书主要围绕Drools规则引擎来展开，但市面上大多数规则引擎的使用和实现原理都类似。建议读者在学习和使用时尽量将规则引擎的使用方法抽象成模型，融会贯通于各类规则引擎的使用中。关于此部分，在后面的章节中我也会帮助大家进行提炼和总结。
在了解了什么是规则引擎，以及它能够解决什么问题之后，要理解为什么要使用规则引擎就变得简单了。本节重点从规则引擎的常见使用场景及简单的示例分析着手，来讲解使用规则引擎的原因、条件和场景。
在技术交流的过程中，常常有刚入门的人提问：“我们这样的业务是否适合使用规则引擎？”如果你有同样的疑问，建议先根据现有的业务场景问一下自己：“我们为什么要使用规则引擎？它能为我们解决什么问题？又能给我们带来什么问题？”
可以明确的一点是，一旦引入了规则引擎，系统的复杂性会增加，如果是重量级的规则引擎，复杂性会增加得更多。Drools算是一个比较重量级的框架，它的引入不但会增加系统的复杂性，还会增加相关人员的学习成本。如果再与KIE Server、Business Central Workbench、Kogito等进行整合，学习成本将更高。
因此，在使用一款规则引擎前，首先要考虑现有业务场景面临的问题是否值得引入规则引擎，而不是如何引入。
规则引擎本质上就是将业务逻辑中变化的部分抽离成一系列规则，使得原本通过硬编码实现的业务逻辑分离为规则和数据，然后围绕数据和规则提供一些管理和处理功能。
规则也可以被理解为一种脚本，脚本通常会包含两部分：条件判断和行为执行。当满足条件判断时，会触发行为的执行。对照Drools的规则脚本，就是：when和then部分。其中，条件判断（when部分）相当于代码中的if判断，行为执行（then部分）就是符合判断之后所执行的业务逻辑，相当于满足if之后要执行的代码。
理解了规则引擎的基本实现逻辑之后，使用规则引擎的场景就很明确了：当系统中出现大量if…elseif…else…时，就可以考虑将这些判断抽离到规则引擎当中。
但在抽离的过程中还要思考一个问题：值不值得？并不是说只要有if…elseif…else…就适合用规则引擎，引入规则引擎还要满足以下两个前提条件：
❑ 复杂度高 。业务流程分支非常复杂，判断变量庞大。
❑ 变化多 。判断具有不确定性，变更频率较高，同时需要做出快速响应和决策。
思考一下：用户注册时，用户名、密码参数校验是否适合使用规则引擎？答案是：不适合。虽然在此过程中也会用到if…elseif…else…，也能用规则引擎来替代它们，但它们的业务复杂度不高，所以没必要引入规则引擎。
上面的两个前提条件只是供使用者判断的参考维度，并不是强制条件，也不是说必须同时具备才能使用规则引擎。比如，业务系统有大量的阈值判断，这些阈值判断虽然都很简单，但业务需要运营人员进行不定时的配置，同样也可以考虑使用规则引擎。
通俗地讲，之所以使用规则引擎，就是因为要解决频繁修改规则导致的低效问题。对于业务逻辑复杂或规则增长、变化迅速的场景，才需要将复杂多变的规则从硬编码中解放出来，以规则文件的形式存放，使得规则的变更不再或尽量避免以修改代码、重启服务的形式上线。
规则引擎的优缺点也是选择规则引擎的重要参考指标。
Drools规则引擎的优点如下：
❑ 声明式编程 ：简化对复杂问题的逻辑表述和验证，提高逻辑的可阅读性。业务分析师和运营人员也可参与此部分操作。
❑ 逻辑和数据分离 ：业务逻辑原本分散在多个对象或服务当中，通过规则引擎可将业务逻辑抽离，放置于规则当中，通过一条或多条规则来呈现，既方便跨域关联逻辑，也方便集中管理和维护。分离的最终呈现形式为数据位于“域对象”中，业务逻辑位于“规则”文件中。
❑ 性能 ：基于增强的Rete算法，能够高效实现业务对象与规则的匹配。
❑ 可扩展性 ：规则的新增、修改变得容易，具有较强的可扩展性。
❑ 知识集中化 ：所有的规则逻辑集中于知识库当中，方便统一管理，同时也可对系统的整体规则进行鸟瞰。
Drools规则引擎的缺点如下：
❑ 系统复杂度 ：Drools规则引擎整体偏重量级，被引入之后，将规则与数据分离，新增的框架、系统交互等，都会增加系统的复杂度。
❑ 增加学习成本 ：要掌握规则语法、框架、集成以及规则管理系统，需要学习成本的投入。
❑ 引入新组件的风险 ：一旦新的组件被引入系统中，该组件自身的风险也成为整个系统的风险。
下面举两个例子来说明规则引擎的使用场景，大家也可以参考上面提到的两个前提条件。
1.电商平台优惠
在电商的优惠活动当中经常会出现如下业务场景：今天可能全场满100元减10元，明天可能部分商品满100元送10元优惠券，后天可能调回原价。在这些满减过程中，不同等级的VIP会员还可能有不同的额外折扣。
想象一下上面的业务场景，随着优惠维度的增多，判断的工作量会成倍增长，此时业务已具备一定的复杂度，简单的if…elseif…else…或数据库配置参数阈值已经无法满足业务需求。另外，这种优惠活动的时效性往往极强，变化具有快速和不确定性。如果每次都经过一个完整的需求、开发、测试、发布的流程，不仅会浪费资源，也会带来时效性问题。所以，此场景适合使用规则引擎。
2.风控系统
以金融或借贷的风险控制（简称风控）系统为例。在此类系统中重点要把控两个因素：人和交易。不同的人有不同的信用等级，也就对应不同的借贷或交易额度。风控系统把控的便是不同人的交易行为，也就是说对于风控系统来说，输入的业务数据是基本不变的，而业务规则、政策、风控模型等会随时发生变化。
这种基于有限输入拓展无限规则模型的场景，非常适合使用规则引擎。以此种场景中用户信用评级为例，当新用户加入，输入证件、年龄、收入等基本信息之后，通过各项数据的权重便可给用户一个初始的信用等级。随着交易行为的发生，信用等级可能有所增减，进而随着信用等级的增减，用户的日交易限额、单笔交易限额、月累计交易限额等都会发生变化。
在上述过程中，用户初始信用等级评定时各项数据的权重可能会随着业务数据的分析、反馈进行变化和调整，用户信用等级与交易之间的关系也会随着平台整体业务数据的分析而变动。特别是通过各个维度以及历史交易情况来分析和预测用户的当前交易是否有风险，判断是否需要进行阻断等操作，都离不开规则引擎。
除了上述电商平台优惠和风控系统两个场景外，规则引擎在实践中还会用于IoT（物联网）、保险、消费贷、财务计算、日志分析处理等业务场景。
上面我从概念和使用场景的维度介绍了规则引擎，这一节介绍规则引擎的使用流程及其可以带来的方便之处。
在未使用规则引擎的情况下，改动业务逻辑的基本步骤如图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中操作规则脚本的是开发人员，如果系统中规则管理平台设计得足够人性化，运营人员经过简单培训，便可直接修改、发布规则。此时，规则引擎的灵活性发挥到了极致，支持随时修改规则并发布，而不用修改业务系统代码和发布业务系统。
市面上的规则引擎比较多，通常分为商用版和开源版两类。常见的规则引擎有Drools、Ilog JRules（商用）、Easy Rules、Jess、Visual Rules（商用）、QLExpress等。在规则引擎选型时，企业可根据自身要求、是否付费，以及业务特性进行考量。
Drools是目前开源且比较活跃、比较主流的规则引擎，几乎每几个月就发布新的版本，它也是本书要讲解的规则引擎。Drools规则引擎采用Phreak算法（演绎法，在Rete算法上改进的算法），同时配套KIE系列（KIE Server、Business Central Workbench、Kogito等）辅助规则系统，支持多种形式的规则载体（比如.drl文本文件、字符串、Excel、DSL等），功能强大，成熟度高，社区活跃。但由于KIE系列的系统不仅支持Drools，还支持JBoss的其他功能，因此属于重量级的实现。如果技术团队有一定的实力，可以抛弃Drools提供的规则管理、发布等系统（重量级且不太符合国人操作习惯），直接用最核心的API配合自主研发的规则管理系统，以达到轻量级、定制化的目的。
Ilog JRules是一种商用规则引擎，所支持的功能比较全面，提供了比较完整的业务规则管理系统（Business Rule Management System，BRMS）。它是基于Java语言开发的，可以部署到任何J2EE项目，能够轻松集成到IDE（集成开发环境）中。
Ilog JRules提供了3种可选的运行模式：RetePlus、Sequential和FastPath。RetePlus模式也采用Rete算法，但对其进行了扩展和优化。该模式在计算和关联性类型的应用方面拥有卓越的性能，执行过程中会循环匹配规则，这一点与Drools规则引擎类似。顾名思义，Sequential模式即顺序运行模式，也就是规则引擎按照顺序判断执行规则，但不会修改工作内存（Working Memory）中的数据。该模式适用于校验和一致性等类型的应用。FastPath模式是增强的Sequential模式，顺序运行，可能会修改工作内存中的数据，但不会重复触发匹配。该模式综合了RetePlus和Sequential的特性，适合在关联性应用和校验类应用中使用。
Easy Rules是一种基于Java的开源规则引擎，其功能相当于Drools规则引擎最核心部分的简化版本，但使用起来非常简单，学习成本低，容易上手。Easy Rules通过对规则的抽象来创建包含条件和操作的规则，同时提供了用来评估规则条件和规则执行操作的RulesEngine API。整体而言，Easy Rules有以下特点：轻量级，API易于学习，基于POJO开发，通过抽象来定义业务规则并应用，支持创建复合规则，可基于MVEL和SpEL表达式语言来定义规则。但Easy Rules并未提供相关规则管理功能，不是一款完整的BRMS产品，可在规则比较简单的场景中使用，或自主研发相应的管理、发布等系统。
Jess是基于Java语言编写的规则引擎，使用Rete算法的增强版本来处理规则，具有体积小、速度快、脚本语言强大（可访问完整的Java API）等特点。Jess拥有向后链接和工作记忆查询等独特的功能。Jess采用的是CLIPS程序设计语言，需要专业的开发人员才能使用。Jess也只提供规则引擎部分，并非一套完整的BRMS产品。Jess可免费用于学术用途，也可被许可用于商业用途。
除了上述规则引擎之外，还有由我国科技部和财政部的创新基金支持的Visual Rules（完整的BRMS商用产品）、用于表达式动态求值的轻量级规则引擎Aviator（基于Java）、可嵌入应用的轻量级规则引擎QLExpress（基于Java）等。纵观市面上的这些规则引擎，一些是商业化版本，一些没有完整的BRMS支撑，同时还面临技术社区活跃度、文档丰富度、解决方案成熟度等方面的问题，因此企业在选型时一定要多维度综合考虑。
想要使用开源的规则引擎，通常可从以下方案中选择：方案一是采用Drools这类支持完整BRMS的产品，但它们比较重量级，门槛较高；方案二是采用Easy Rules、QLExpress等轻量级规则引擎，不向运营人员提供规则管理；方案三是基于Drools核心部分、Easy Rules、QLExpress等，自主研发规则管理系统；方案四是完全根据自身业务，自主实现规则引擎。对于中小企业，我推荐采用方案一或方案三。如果条件允许或为满足特定要求，企业当然也可以直接购买商用版本，支持和服务都会好一些。
在了解了规则引擎的整体情况之后，我在后面章节将基于Drools规则引擎进行实战讲解，并尽可能地抽象出规则引擎通用的模型、架构、思维、算法、实战经验等。在学习的过程中，大家也可以与其他规则引擎进行对照，达到融会贯通的效果。
上面介绍了市面上的一些主流规则引擎，后续章节便主要围绕Drools规则引擎来展开。在进入实战章节之前，先从整体上介绍Drools规则引擎。
Drools系列自6.0版本以后便引入了一个概念——KIE（Knowledge Is Everything，知识就是一切），它是JBoss的一组项目的总称，这个名字渗透到了GitHub源代码和Maven pom中。随后KIE也被用于统一构建、部署和使用这类系统的共享操作中。在后续Drools的使用过程中，大家会发现实现的上层接口基本上都是以KIE为前缀或在kie包下的。
Drools 8版本下KIE系列项目的结构图如图1-4所示。
图1-4 KIE系列项目的结构图
从图1-4中可以整体看到KIE所包含的项目组件以及Drools在其中的位置。在Drools 8之前，Drools、Drools-WB和KIE-WB是学习Drools的重点。但在Drools 8中，Drools-WB和KIE-WB已经退役，随之而来的是将相应的功能部署到Kogito（云原生组件）当中。
下面简单介绍图1-4中涉及的组件及其功能。
❑ Drools-WB和KIE-WB ：Drools、jBPM等提供了可视化资源部署、管理平台，通过该平台运营人员可进行规则的创建、编辑、发布等操作。鉴于在Drools 8版本中，Drools-WB和KIE-WB已经不再是Drools的组件，它们在低版本中依旧可用，因此对这部分的功能和使用将在本书的附录中进行介绍。
❑ Kogito ：一种开源的端到端业务流程自动化（BPA）技术，用于在现代容器平台上开发、部署和执行流程与规则的云原生应用。Kogito包含多个组件的支持，比如Drools、jBPM、OptaPlanner、UI建模工具等。Kogito针对混合云环境进行了优化，历经实战检验，可以使开发人员灵活地在其特定领域的服务上构建云原生应用，为业务流程管理（BPM）提供灵活的开源解决方案。
❑ OptaPlanner ：属于kiegroup的组别，目前已经是一个独立的项目了。它是一个基于Java的轻量级、可嵌入的规划调度引擎。比如，可以优化车辆路径规划问题、雇员排班问题、云计算资源调度问题、任务分配问题等商业资源规划的问题。值得注意的是，OptaPlanner在使用约束描述和收益函数计算时，以Drools作为工具为佳。
❑ UberFire ：一个功能类似Eclipse的全新的基础工作台项目，带有插件中的面板和页面，独立于Drools和jBPM。任何人都可以将它作为构建工作台的基础工具，它也是构建整个JBoss控制台和工作台的工具，Business Central Workbench便是通过UberFire和Guvnor插件构建的。
❑ jBPM（Java Business Process Management，业务流程管理） ：一款开源的业务流程管理系统，它覆盖了业务流程管理、工作流管理、服务协议等领域。其原开发团队离开JBoss之后，推出了功能类似的Activity框架。在图1-4中，因KIE-WB已经完美地整合了工作流，jBPM-WB对于KIE-WB便是多余的，因此显示为灰色。
关于Drools规则引擎的兄弟项目，几乎每一个都属于相对独立的领域，感兴趣的读者可以了解一下，我在本书中不再进行更深层次的介绍。
从功能和API使用方面来讲，Drools规则引擎主要经历了三个大的阶段。第一阶段为Drools 5.x版本，第二阶段为Drools 6.x/7.x版本，第三阶段为目前的Drools 8.x版本。下面简单介绍这三个阶段对应版本的功能及特性。
Drools 5.x作为早期Drools的一个相对成熟的版本，曾被广泛运用于生产当中，具有以下功能及特性：
❑ 提供了基础的声明式编程，可以使用DRL（Drools Rule Language，Drools规则语言）编写规则。
❑ 提供了基于Rete算法的规则匹配引擎。
❑ 支持决策表（Decision Table）、决策树（Decision Tree）等多种规则表示方式。
❑ 支持事件处理（Event Processing），可以处理复杂事件。
❑ 提供了Eclipse的开发插件等。
基本上，在Drools 5.x系列版本中，Drools已经满足了大多数需求，适用于大多数业务场景。
Drools 6.x和7.x版本，在Drools 5.x版本的基础上进行了优化和改进，特别是统一了新的API，且不再向下兼容Drools 5.x。Drools 6.x和7.x版本引入的主要特性如下：
❑ Drools 6.x引入了KIE的概念，统一管理规则、流程和其他知识资源。
❑ Drools 6.x提供了一个基于Web的规则管理系统（KIE Workbench），可以在线编写、测试和部署规则。
❑ Drools 6.x支持规则的动态加载和更新，可以在运行时修改规则而无须重启应用。
❑ Drools 6.x改进了规则引擎的性能，提供了更多优化选项。
❑ Drools 6.x支持与其他Java框架（如Spring）的集成。
❑ Drools 7.x支持DMN（Decision Model and Notation，决策模型和符号）标准，可以使用DMN模型表示和执行决策。
❑ Drools 7.x提供了一个基于Web的DMN模型编辑器，可以在线创建和编辑DMN模型。
❑ Drools 7.x支持GraalVM，可以将规则编译成本地代码，以提高运行速度。
❑ Drools 7.x改进了规则引擎的性能和稳定性，修复了一些已知问题。
❑ Drools 7.x支持与其他云平台（如OpenShift）的集成。
可以看出，除了Drools 6.x对API的大改动和引入Web规则管理系统之外，其他都是不断优化、迭代以方便用户使用的功能。因此，Drools 6.x和7.x版本也是目前使用的主流版本。
Drools 8.x版本是目前新的大版本，整个规则引擎的核心开始转型到云原生和微服务，以适应目前软件行业的发展。Drools 8.x的核心功能与6.x和7.x基本一致，其主要特性及变化如下：
❑ 移除了Drools 6.x提供的Web规则管理系统，具体来说就是KIE Server和Business Central Workbench。
❑ 由于所需Java版本等，移除了Security Manager功能，移除了OSGi的支持。
❑ 废弃了部分依赖类库，比如drools-mvel、drools-engine-classic等，对依赖类库进行了新的调整。
❑ 正式采用Kogito及相关云原生组件进行服务和规则的部署。
❑ 正式采用规则单元（Rule Unit）语法格式。
❑ 对性能和算法进行优化提升。
Drools 8.x对原有的Web规则管理系统的移除以及对云原生的全面支持都是比较重要的功能特性，对于项目的架构和语法实现都有非常大的影响。本书将以Drools 8.x的功能为核心进行讲解，同时也会兼顾Drools 6.x和Drools 7.x的传统语法及功能。
至此，关于规则引擎的基本介绍就告一段落了，后续章节将以示例来演示如何使用，并通过实战来总结经验和知识点，同时分析、汇总规则引擎的底层设计理念等。