泥瓦匠 · 2019年09月09日

规则引擎解决方案浅析

一、规则引擎使用场景:

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

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

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

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

file

二、什么是规则引擎

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

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

规则引擎由三部分

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

两个重要模块:

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

file

三、实践总结

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

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

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

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

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

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

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

推荐阅读
关注数
2
文章数
32
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息