非全自研可视化表达引擎-RuleLinK
说在前面
工作中经常会遇到这样的场景:
-
帮忙把小贝拉门店 商品金额在5w以内,产康订单最多95折。
-
帮忙把圣贝拉门店 开业时间在6个月内,折扣低于7折要发起审批
-
帮忙把宁波太平洋店设置独立合同模板
-
帮忙把节假日成本变成1000
-
...
有些三五月变一次,有些一月变一次,有些一周变几次,每次修改都是去巴拉代码,不胜其烦。
系统中的规则分散在各各PRD,有些人脑袋里也存了一份,但是随着人员的迭代,需求的迭代,最新永远散落在各初的代码中。这会带来诸多问题:
-
学习成本高
-
维护成本高
-
开发成本高
-
测试成本高
于是有了创建一个规则的管理与运营平台,以及支撑规则的解释与执行的框架的想法。用以消除样板式代码,解放生产力,让规则的变化变得的简单。
RuleLink的定位
RuleLink是一款可视化表达式引擎。致力于解决业务开发过程中,规则变化成本高, 规则管理分散,维护成本高,学习成本高,大量样板式代码等一系列的问题。
RuleLink名称的由来
用规则连接业务逻辑,让研发专注业务逻辑,让规则的配置变得的简单。
RuleLink 是基于 Aviatorscript 实现 规则的解析,基于开源项目 "rule-engine-builder-ui"实现表达式生成与渲染。(我只是代码搬运工,所以取名非全自研)
基于当下我们的业务规则量,RuleLink并未使用性能更好的 Rete算法,而是使用了传统的模式匹配。
为什么要建RuleLink
除了前面介绍的之外,另一个原因则是想弥补一下上一份的工作中的一点点小遗憾。
可视化表达式引擎的建设有两个难点:
-
表达式的解释与执行
-
表达式的生成与解析
第1点相对简单,于是在1月份时,捣鼓了一些基础代码,做了一些尝试,当时还因为部署Drools 的workbench 搞得停服20分钟,拿了人生第一C绩效。
到4月份接到这样一个需求,某业务线不同订单订单需要接不同的聚合支付账号。因为原来就换过一次了,为了支持快速切换,我们开始在Q1的代码基础做了一些调整,开始有了RuleLink的雏形。后来又陆续接入了一些场景:
-
新业务支付支持不同主体
-
订单折扣配置
-
...
更多的场景的接入,让可视化配置的需求变得比较必要。于是开始正式着手构建RuleLink,解决这一类的问题。
整体结构
目前主要使用Aviatorscript 解析表达式,并支持SpE
这是从其他复制的一张图(忘记出处),因为和自己的场景几乎一模一样,就直接引用了。
存储模型
Rule_Scene 规则场景
定义场景,目前场景是固定,现在只支持支付,未来有新场景再加入
RuleFactObj 事实对象
RuleFactObjfield 事实对象字段
定义场景下的事实字段,主要用于将来前端可可视化操作。
RuleBase 规则库
定义规则,目前只支持表达式(未来考虑支持 特定脚本,比如groovy),目前只是定义规则命中返回 简单或者复杂数据类型,未来可以考虑执行某个运行(action)。
日期格式处理
日期格式原来的实现是SpEL的方式,这会引发一些问题,所以修改了其源码并重新编译生成支持Aviatorscript 支持的自定义函数方式
表达式解析
使用Aviatorscript解析比较简单,直接上代码
交互界面
写在最后
虽然现在的版本距离真正让运营同学能直接用起来了,可能还有一定的距离。比如各种枚举支持选项,门店等动态数据支持选项,返回结果支持动态渲染和选择等都还不不具备。但是1.0版本比原来硬编码,甚至nacos配置已经强上许多了。毕竟还是和两个小伙伴挤压业余时间开发,实为不易,于是来一次简单的聚餐,于是我们预定了未来每次大的版本升级,都来一次
上一份工作时,就有要构建一个简单易用的规则引擎,一直没能实现,有些许遗憾,今天算是给补上了。
微信:jijunjian
成为一名优秀的程序员!