文章来源：DROOLS 8 FINAL – TOWARD A MODULAR AND CLOUD NATIVE RULE ENGINE （by Mario Fusco - October 17, 2022）
介绍：原文来自是KIE group的官方博客网站。KIE group是一个专注于推广和应用业务规则管理系统的组织，其成员包括一些大型企业和组织。
目录
Drools 8系列是7.x-stream的自然演变，结合了许多功能和经验教训，集成了Kogito（是一种云原生业务自动化技术，脱胎于jbpm+drools而生的云原生工作流引擎框架。它被设计用于构建云就绪业务应用程序）和许多云原生用例。
本文的目的是对这个新版本中的主要特征进行概述，并告知我们的下一步开发工作。
在您使用Drools8的新功能时请向我们反馈您的使用情况，因为我们会基于这些反馈更新我们的未来开发计划！
开发者体验
完全用Java编写规则（或自己喜欢的语言）！
在我们知道您已经喜欢上了我们专属于Drools的开发语言（DRL）的同时，我们也明白从头学习一门语言的难度，尽管这门语言类似于Java
因此，在Drools8中，我们引入了一种全新的完全类型化（fully typed）、基于Java的DSL，无需离开舒适的传统集成开发环境即可编写规则。事实上，这允许您使用自己最喜欢的JVM语言（如Scala和Kotlin）来编写规则！
拥抱云原生：Drools Quarkus扩展
我们还开发了一款新的以Drools为中心的Quarkus拓展；该扩展用于将 Drools 核心引擎用作 Quarkus 应用程序的一部分。
请注意，这个新的 Drools Quarkus 扩展并不是 Kogito 的替代品。对于云原生场景中更全面的功能（如自动生成 REST 端点），我们邀请开发者继续使用和探索 Kogito。
由于其实验性质，它目前还不能在主要的 Quarkus 频道上使用，但你可以通过这些链接在 Drools 存储库中找到快速入门式的示例和 Quarkus 式的指南。
不只是规则：AI的模块化引擎
在第 7 版及以前，Drools 是一个单一的规则引擎，其所有功能都在一个核心模块中实现（并且紧密相连）。在 Drools 8 中，为了使其更加模块化，对引擎进行了大量修改，将非核心功能，如真相维护系统（TMS，Truth Maintenance System）、基于 protobuf 的序列化以及对特质和不同信念系统的实验性支持，分离到不同的模块中，用户只有在特别需要时才可将其带入自己的项目中。
但是，模块化的努力并没有止步于此。它的主要目标是让 Drools 成为一个容器，让许多其他人工智能相关技术（如 DMN 和 PMML）在其中共存与合作。为了实现这一目标，Drools 开发了一个内部框架，代号为 Efesto，可以插入不同的引擎，让它们以松散耦合的方式相互利用。
代码名EFESTO：一个可扩展的编译时和运行时协调框架
多年来，我们的引擎出现了一个共同的模式。从广义上讲，它们都有一个将源模型（source model）转化为可执行单元的阶段（编译）；它们都有一个使用可执行单元进行实际评估的阶段（运行时）。此外，其中一些模型可能还需要调用其他模型进行全面评估，例如，一些决策模型会调用预测模型，而一些预测模型则会使用规则引擎。Efesto 是我们为内部框架设计的代号，目的是提供一个通用、稳定、统一的应用程序接口（API）来支持这些阶段，并允许在编译时或运行时对不同模型进行链式处理。这样做的好处是提高了代码的可重用性，并全面简化了此类处理阶段。我们计划使用这一新的应用程序接口来实现引擎之间的集成（当源模型需要引用不同的源模型时），并在不同环境中轻松扩展当前实现的使用。
有关整体设计的更多详情，请参阅《Efesto 重构–简介》，而更深入的技术解释，请参阅《Efesto 重构–技术细节》。
规则单元：一种新的规则模块化编程模型
在定义大型规则库时，显然需要将其分割成逻辑上独立的子部分。在过去，Drools 通过几种不同的方式满足了这一需求：可以将多个 KieBase 中的规则分割开来，并使一个 KieBase（KieBase在Drools中是一个知识仓库，它包含了若干的规则、流程、方法等。KieBase本身并不包含运行时的数据，如果需要执行规则，需要创建KieSession）包含其他规则；可以将同一 KieBase 中的规则进一步组织成议程组；还可以将工作内存分割成不同的入口点。
规则单元是一个统一的、自上而下的模块，描述了一组规则；通过引入 "数据源 "抽象概念，将工作内存划分为类型化的入口点，规则单元还描述了这些规则能够处理的数据的形状。换句话说，一个规则单元封装了规则的执行单元和与规则匹配的数据。有关规则单元和数据源的更多信息，请点击此处。
新的基于 Java 的 DSL 建立在规则单元概念的基础上，但您仍然可以使用传统的 DRL 来定义规则单元！
实验特点和下一步
Drools 团队一直在尝试新的功能，以便为引擎带来新的功能或改善整体用户体验。目前，这些实验主要集中在两个方面。
影响分析（IMPACT ANALYSIS）
影响分析功能可分析规则之间的关系，生成一个定向图，显示哪些规则会受到另一条规则的影响。这样，当需要分析对某一特定规则的变更所产生的影响时，就可以很容易地直观确定这一变更会对规则集的哪一部分产生影响。
DRL代码编辑器
目前正在开发基于语言服务器协议（LSP）的 DRL 代码编辑器。LSP 可通过扩展、插件或配置应用于各种集成开发环境和编辑器，如 VS Code 和 Neovim。目前尚未发布，敬请期待！
从DROOLS 7到8
尽管在 Drools 8 的开发过程中引入了所有的新功能，但基于旧的 KieContainer/Base/Session 的旧 API 仍然可以正常工作并得到支持，所以如果您不愿意立即迁移您现有的基于 Drools 7 API 的代码库，这并不妨碍您升级到 Drools 8。尽管如此，我们还是强烈建议您了解一下新的基于规则单元的编程模型，并评估它是否能更好地满足您的需求。如果您仍有疑问，请尝试基于 Java 的 DSL 并告知我们！
这些迁移指南对于支持您从 Drools 7 到 Drools 8 的迁移计划非常有帮助，其中包括如何将基于 KIE Server 的应用程序迁移到 Kogito 的指导。
JDK 11 现在是运行 Drools 的最低要求，而从源代码构建 Drools 或使用 kie-ci 模块提供的 maven 集成功能至少需要 3.8.6版本。有关这方面的更多信息，包括在Drools 8中已弃用或已退役的功能的最小列表，可在发行说明中获得。
关于版本编号的说明
可能令您感到惊讶的是，我们部署了Drools 8 Final的第一个稳定版本Drools 8.29.0.Final。我们这样做有两个原因，一是继续在Drools 8还处于测试阶段时开始的小版本编号，二是避免与其他与相同小版本对齐的下游项目(如Kogito和OptaPlanner)混淆。
参考文献
您可以在此链接中找到Drools 8文档。