写点什么

编排流程 / 规则,编排本身也需要很深的逻辑思考!

作者:waitmoon
  • 2022 年 9 月 13 日
    上海
  • 本文字数:2275 字

    阅读完需:约 7 分钟

编排流程/规则,编排本身也需要很深的逻辑思考!

什么是流程/规则编排?

所谓编排,就是让已有的节点通过不同的组织方式完成不同的需求。


首先,我们需要对既有业务做一定程度的抽象,以一个例子开始:

一个简单的国庆节充值活动:

活动时间 10.1-10.7

充值≥100 元,送 5 元余额

充值≥50 元,送 10 积分,10.5 之后开始

不叠加送,即充 100 元只送 5 元余额不会叠加再送 10 积分


当充值发生时,我们拥有:充值用户-uid,充值金额-cost,充值时间-time


再有一些制作好的抽象节点,如:

判断充值≥100 的条件节点 ScoreFlow-100,cost≥100 返回 true,否则返回 false

判断充值≥50 的条件节点 ScoreFlow-50,cost≥50 返回 true,否则返回 false

发放 5 元余额的结果节点 AmountResult,结果也可以有返回,比如正常发放了返回 true,库存不足了等原因导致的没有发放(不是 error),可以返回 false

发放 10 元积分的结果节点 PointResult


那么,为什么要编排,如何编排才是最优的?

为什么要编排?

屏蔽代码影响:比如编排者只需要知道 AmountResult 是发放余额的节点,然后在适当的位置运行这个节点即可,不需要关心真实的代码逻辑


提升效率:结合可视化给非研发人员编排实现业务逻辑,支持动态修改与生效配置,比如充值条件 100 元改成 200,结合可视化工具直接修改,解放研发,提升生产效率

如何编排?

流程图式编排


脑海里最先出现的编排方式,也是最常见的编排方式

执行树式编排

When X Then Y


以上两种基本代表了传统的编排思想,在简单的例子下,看起来也是非常直观,但,当变动发生时,尤其是需要灵活调整的场景,他们的表现又如何呢?

变动

①简单配置修改

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

②简单逻辑变动

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

③进阶逻辑变动

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


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


那么,有没有更好的编排逻辑?

ice 是如何编排的


如图,ice 使用关系节点作为逻辑传递的桥梁,用树图方式呈现逻辑

关系节点(逻辑节点)

控制业务流转,如:

AND:从上到下执行子节点,遇到第一个 false 中断并返回 false,全部为 true 则返回 true,类似于 Java 的 &&

ANY:从上到下执行子节点,遇到第一个 True 中断并返回 true,全部为 false 则返回 false类似于 Java 的 ||

ALL:从上到下执行所有子节点

叶子节点(业务节点)

真正做事情的节点,如:

Flow:一些条件与规则节点,如 ScoreFlow

Result:一些结果性质的节点,如 AmountResult,PointResult

None:一些不会干预流程的节点,如下文会介绍到的 TimeChangeNone

执行流程

图中,如果 10 月 4 日,充值 100 元,则执行流程为:

  1. 从根节点开始,先执行 ANY

  2. 充值时间在 ANY 生效时间内,继续执行

  3. ANY 有两个子节点,先执行第一个子节点 AND

  4. AND 有两个子节点,先执行第一个子节点 ScoreFlow-100

  5. ScoreFlow-100 判断并返回 true

  6. AND 接收到 true,继续向下执行 AmountResult

  7. AmountResult 发放余额并返回 true

  8. AND 子节点执行完毕,接收到两个 true,自己也返回 true

  9. ANY 接收到 true,不再继续执行子节点并返回 true


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

变动的解决

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


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


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


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


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


增加了个子节点 TimeChangeNone(用于更改测试环境请求里的充值时间,可以改成任意想要的测试时间)

特性

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


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


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


如图,参与活动这里用到的 TimeChangeNone,如果现在还有个 H5 页面需要做呈现,不同的呈现也与时间相关,怎么办?只需要在呈现活动这里使用同一个节点对象(在 ice 后台配置中为同 id 节点),更改其中一个,另一个也会被更新(因为他们是同一个对象,不存在多个复用节点同步问题),避免了到处修改时间

Code

Talk is cheap. Show me the code…

官方文档:

http://124.221.148.247/zh/

github:

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

gitee:

https://gitee.com/waitmoon/ice


有更好想法或者更多应用场景或者想一起探讨的小伙伴~ 欢迎交流(官方文档有`加入群聊`菜单,QQ 群:587368939,公众号:waitmoon)~~

发布于: 19 小时前阅读数: 131
用户头像

waitmoon

关注

致力于解决灵活繁复的硬编码问题~ 2020.03.30 加入

来都来了,坐下喝茶~看看ice~~

评论 (1 条评论)

发布
用户头像
赞👍
19 小时前 · 上海
回复
没有更多了
编排流程/规则,编排本身也需要很深的逻辑思考!_规则引擎使用_waitmoon_InfoQ写作社区