开源规则引擎——ice:致力于解决灵活繁复的硬编码问题

开源规则引擎——ice:致力于解决灵活繁复的硬编码问题_第1张图片

背景介绍

业务中是否写了大量的 if-else?是否受够了这些 if-else 还要经常变动?

业务中是否做了大量抽象,发现新的业务场景还是用不上?

是否各种调研规则引擎,发现不是太重就是接入或维护太麻烦,最后发现还是不如硬编码?

接下来给大家介绍一款全新的开源规则引擎——ice,以一个简单的例子,从最底层的编排思想,阐述 ice 与其他规则引擎的不同;讲述 ice 是如何使用全新的设计思想,契合解耦和复用的属性,还你最大的编排自由度。

规则引擎的应用场景

规则引擎在很多业务场景中都有应用,例如:

会员营销:由多种条件、流程、奖励组合而成,时间线复杂,代码复用率不高,调整频繁。

风控规则:由多种条件组合并返回决策,条件量大且复杂,变动频繁。

数据分析:将数据通过分析师自己编排的规则产出想要的数据,千人千面。

以上场景往往都存在一些共同痛点:

灵活业务(变动频繁,时效性明显,测试逻辑复杂)

追求灵活花里胡哨:产品和运营一直在探索新鲜玩法,导致很多抽象出来的模块往往扛不过两个迭代。

今天上线又要调整:因为一些偶发情况,如线上用户参与度不高,及时调整用户参与门槛等(当然也可以在开发前把所有情况考虑到位,但是为了小概率事件做大量的工作,成本过高)。

研发测试心力交瘁:研发硬编码,测试验证复杂重复逻辑,久而久之变的愈发疲惫。

时间线(多条时间线交织混乱)

研发编排错了再来:一般营销类型的会涉及很多时间线,而在当前,测试一个未来要上线的具有不同时间节点属性的活动,硬编码时往往由研发编排时间,测试进行测试,但是当 bug 发生并打乱时间线时,就需要重新编排时间(没有经历过的不用太了解,后面会说)。

测试并行孔融让梨:当时间线发生冲突并有多个测试在冲突位置上并发测试,往往由测试自行协调测试顺序,当一方出现问题往往导致后续测试进度不可控。

其他问题

依赖挂了难以为继:测试环境为非稳定环境,一旦依赖出了问题难免影响进度,如何能做到简单高效 mock?

修复数据苦不堪言:当线上问题产生时,受影响的客户如何快速高效的补偿?

开源规则引擎 ice 的设计思路

为了方便理解,设计思路将伴随着一个简单的充值例子展开。

举例

X 公司将在国庆放假期间,开展一个为期七天的充值小活动,活动内容如下:

活动时间:(10.1-10.7)

活动内容:

充值 100 元 送 5 元余额 (10.1-10.7)

充值 50 元 送 10 积分 (10.5-10.7)

活动备注: 不叠加送(充值 100 元只能获得 5 元余额,不会叠加赠送 10 积分)

简单拆解一下,想要完成这个活动,我们需要开发如下模块:

开源规则引擎——ice:致力于解决灵活繁复的硬编码问题_第2张图片

如上图,当用户充值成功后,会产生对应充值场景的参数包裹 Pack(类 Activiti/Drools 的 Fact),包裹里会有充值用户的 uid,充值金额 cost,充值的时间 requestTime 等信息。我们可以通过定义的 key,拿到包裹中的值(类似 map.get(key))。

模块怎么设计无可厚非,重点要讲的是后面的怎么编排实现配置自由,接下来将通过已有的上述节点,讲解不同的规则引擎在核心的编排上的优缺点,并比较ice是怎么做的。

流程图式实现

类 Activiti、 Flowable 实现:

开源规则引擎——ice:致力于解决灵活繁复的硬编码问题_第3张图片

流程图式实现,应该是我们最常想到的编排方式了~ 看起来非常的简洁易懂,通过特殊的设计,如去掉一些不必要的线,可以把 UI 做的更简洁一些。但由于有时间属性,其实时间也是一个规则条件,加上之后就变成了:

开源规则引擎——ice:致力于解决灵活繁复的硬编码问题_第4张图片

看起来也还好。

执行树式实现

类 Drool s实现(When X Then Y):

开源规则引擎——ice:致力于解决灵活繁复的硬编码问题_第5张图片

这个看起来也还好,再加上时间线试试:

图片

依旧比较简洁,至少比较流程图式,我会比较愿意修改这个。

计划永远赶不上变化

上面两种方案的优点在于,可以把一些零散的配置结合业务很好的管理了起来,对配置的小修小改,都是信手拈来,但是真实的业务场景,可能还是要锤爆你,有了灵活的变动,一切都不一样了。

理想

不会变的,放心吧,就这样,上!

现实

① 充值 100 元改成 80 吧,10 积分变 20 积分吧,时间改成 10.8 号结束吧(微微一笑,毕竟我费了这么大劲搞规则引擎,终于体现到价值了!)

② 用户参与积极性不高啊,去掉不叠加送吧,都送(稍加思索,费几个脑细胞挪一挪还是可以的,怎么也比改代码再上线强吧!)

③ 5 元余额不能送太多,设置个库存 100 个吧,对了,库存不足了充 100 元还是得送 10 积分的哈(卒…早知道还不如硬编码了)

以上变动其实并非看起来不切实际,毕竟真实线上变动比这离谱的多的是,流程图式和执行树式实现的主要缺点在于,牵一发而动全身,改动一个节点需要瞻前顾后,如果考虑不到位,很容易弄错,而且这还只是一个简单的例子,现实的活动内容要比这复杂的多的多,时间线也是很多条,考虑到这,再加上使用学习框架的成本,往往得不偿失,到头来发现还不如硬编码。

怎么办?

让我们看看 ice 是怎么做的?

引入关系节点

关系节点为了控制业务流转。

AND

所有子节点中,有一个返回 false 该节点也将是 false,全部是 true 才是 true,在执行到 false 的地方终止执行,类似于 Java 的 &&。

ANY

所有子节点中,有一个返回 true 该节点也将是 true,全部 false 则 false,在执行到 true 的地方终止执行,类似于 Java 的 ||。

ALL

所有子节点都会执行,有任意一个返回 true 该节点也是 true,没有 true 有一个节点是 false 则 false,没有 true 也没有 false 则返回 none,所有子节点执行完毕终止

NONE

所有子节点都会执行,无论子节点返回什么,都返回 none。

TRUE

所有子节点都会执行,无论子节点返回什么,都返回 true,没有子节点也返回 true(其他没有子节点返回 none)。

引入叶子节点

叶子节点为真正处理的节点。

Flow

一些条件与规则节点,如例子中的 ScoreFlow。

Result

一些结果性质的节点,如例子中的 AmountResult,PointResult。

None

一些不干预流程的动作,如装配工作等,如下文会介绍到的 TimeChangeNone。

有了以上节点,我们要怎么组装呢?

开源规则引擎——ice:致力于解决灵活繁复的硬编码问题_第6张图片

如上图,使用树形结构(对传统树做了镜像和旋转),执行顺序还是类似于中序遍历,从 root 执行,root 是个关系节点,从上到下执行子节点,若用户充值金额是 70 元,执行流程:

[ScoreFlow-100:false]→[AND:false]→[ScoreFlow-50:true]→[PointResult:true]→[AND:true]→[ANY:true]

这个时候可以看到,之前需要剥离出的时间,已经可以融合到各个节点上了,把时间配置还给节点,如果没到执行时间,如发放积分的节点 10.5 日之后才生效,那么在 10.5 之前,可以理解为这个节点不存在。

变化的灵活快速应对

对于 ① 直接修改节点配置就可以。

对于 ② 直接把 root 节点的 ANY 改成 ALL 就可以(叠加送与不叠加送的逻辑在这个节点上,属于这个节点的逻辑就该由这个节点去解决)。

对于 ③ 由于库存的不足,相当于没有给用户发放,则 AmountResul 返回 false,流程还会继续向下执行,不用做任何更改。

再加一个棘手的问题,当时间线复杂时,测试工作以及测试并发要怎么做?

一个 10.1 开始的活动,一定是在 10.1 之前开发上线完毕,比如我在 9.15 要怎么去测试一个 10.1 开始的活动?在 ice 中,只需要稍微修改一下:

开源规则引擎——ice:致力于解决灵活繁复的硬编码问题_第7张图片

如图,引入一个负责更改时间的节点 TimeChangeNone(更改包裹中的requestTime),后面的节点执行都是依赖于包裹中的时间即可,TimeChangeNone 类似于一个改时间的插件一样,如果测试并行,那就给多个测试每人在自己负责的业务上加上改时间插件即可。

ice 的特性

为什么这么拆解呢?为什么这样就能解决这些变动与问题呢?

其实,就是使用树形结构解耦,流程图式和执行树式实现在改动逻辑的时候,不免需要瞻前顾后,但是 ice 不需要,ice 的业务逻辑都在本节点上,每一个节点都可以代表单一逻辑,比如我改不叠加送变成叠加送这一逻辑就只限制在那个 ANY 节点逻辑上,只要把它改成我想要的逻辑即可,至于子节点有哪些,不用特别在意,节点之间依赖包裹流转,每个节点执行完的后续流程不需要自己指定。

因为自己执行完后的执行流程不再由自己掌控,就可以做到复用:

开源规则引擎——ice:致力于解决灵活繁复的硬编码问题_第8张图片

如图,参与活动这里用到的 TimeChangeNone,如果现在还有个 H5 页面需要做呈现,不同的呈现也与时间相关,怎么办?只需要在呈现活动这里使用同一个实例,更改其中一个,另一个也会被更新,避免了到处改时间的问题。

同理,如果线上出了问题,比如 sendAmount 接口挂了,由于是 error 不会反回 false 继续执行,而是提供了可选策略,比如将 Pack 以及执行到了哪个节点落盘起来,等到接口修复,再继续丢进 ice 重新跑即可(由于落盘时间是发生问题时间,完全不用担心活动结束了的修复不生效问题),同样的,如果是不关键的业务如头像服务挂了,但是依然希望跑起来,只是没有头像而已,这样可以选择跳过错误继续执行。这里的落盘等规则不细展开描述。同样的原理也可以用在 mock 上,只需要在 Pack 中增加需要 mock 的数据,就可以跑起来。

引入前置节点

开源规则引擎——ice:致力于解决灵活繁复的硬编码问题_第9张图片

上面的逻辑中可以看到有一些 AND 节点紧密绑定的关系,为了视图与配置简化,增加了前置(forward)节点概念,当且仅当前置节点执行结果为非 false 时才会执行本节点,语义与 AND 相连的两个节点一致。

Talk is cheap. Show me the code…

github:https://github.com/zjn-zjn/ice

gitee:https://gitee.com/waitmoon/ice

欢迎大家使用体验开源的规则/流程引擎 ice。如果有遇到问题,欢迎提 issue 来交流。大家也可以添加作者微信:lwaitmoonl ,备注“ice”,进入交流群。

Dev for Dev专栏介绍

Dev for Dev(Developer for Developer)是声网Agora 与 RTC 开发者社区共同发起的开发者互动创新实践活动。透过工程师视角的技术分享、交流碰撞、项目共建等多种形式,汇聚开发者的力量,挖掘和传递最具价值的技术内容和项目,全面释放技术的创造力。

你可能感兴趣的:(开源规则引擎)