规则引擎解决方案浅析的问题(规则引擎原理解析)

导语：规则引擎解决方案浅析

一、规则引擎使用场景：

用于页面，流程，扩展点实现的选择；输出结果：实现的位置；编排无数的条件积木和行为积木，达到业务逻辑计算，券库存消减的目的；输出结果：商品重计算后的价格；通过订单，售后单，会员等信息编排和判断，达到多因子决策给出最佳答案的效果；输出结果：响应式回答/营销推荐，也或分步骤完成某类表单（售后申请，或工单提交）；过订单消息的触发，和商业化协议的元数据输入，形成结构化的计费记录；输出结果：计费凭证；

业务配置-条件积木，以及应用的授权逻辑，都有非常多的规则管理，由于业务的变化大，需求迭代快，需要不断的嵌套规则，硬编码开发。基于业务需要，希望能建立规则引擎，将规则代码从业务中抽离出来，降低规则迭代成本，降低if else等的规则嵌套，增强代码的维护性和复用性。开发人员不用过多的关注逻辑判断，可以专注与逻辑处理。

有很多规则，如校验是通过if else逻辑硬编码完成，商品目前支持电商、零售等业务部门，无非就是两种情况：一种是商品领域模型的变更，还有一种是规则的变更。可以说，支撑上层业务，业务规则占了需求的半边天。

通用的业务规则引擎，不和自己的业务藕合，提供一个通用的规则引擎是可行的。

二、什么是规则引擎

规则引擎是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。

规则本质上是一个函数，如y=f(x1,x2,..,xn)

规则引擎由三部分

事实（Fact）：就是用户输入的已经事实，可以理解为推理前的已知对象。LHS(Left Hand Side)：可以理解为规则执行需要满足的条件。RHS(Right Hand Sike)：可以理解为规则执行后的返回对象。

两个重要模块：

规则管理：可以理解为逻辑上管理规则，主要涉及规则、事实对象和规则集三个实体。涉及到规则变更时，最好对规则加个版本，可通过规则版本控制，可以平滑灰度地方式改变规则，也便于更有信心在测试规则正确性。规则执行：通过规则库数据，通过规则引擎的规则解析、规则编译将可执行代码缓存起来，避免每次和DB交互，然后每次规则的变更也通过ZK或者DCC实时通知给规则执行器。规则执行器的实现方式，可以多种多样，不依赖于规则库的存储方式，可以根据需求，选用Drools、Aviator等第三方引擎，甚至可以基于ANTLR定制。

三、实践总结

实践出真理。调研了一些 Java 的规则引擎框架：

drools比较重，适合风控金融，反欺诈。Avator、Fel、QLExpress 等不太适合搜索路由场景用基于 Apollo 或者 grovvy脚本等实现引擎，配置路由规则到 apollo 或者 脚本即可。

如果是简单的场景，我们只要定义好关键条件 key ，命中 key ，返回 key 对应的 result 即可。

如果复杂金融场景，drools 比较合适。

比如一个搜索场景，按照优先级由上到下：

如果带了某个店铺ID，路由到店铺分片的搜索索引如果带了某个买家ID，路由到买家分片的搜索索引如果状态是热状态，路由到热状态索引如果...

这种简单的，就用 apollo 定义好关键条件 json ，匹配即可。

免责声明:本站部份内容由优秀作者和原创用户编辑投稿，本站仅提供存储服务，不拥有所有权,不承担法律责任。若涉嫌侵权/违法的，请反馈，一经查实立刻删除内容。本文内容由快快网络小悦创作整理编辑！