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

编排流程/规则,编排本身也需要很深的逻辑思考所谓编排 就是让已有的节点通过不同的组织方式完成不同的需求

大家好,欢迎来到IT知识分享网。

什么是流程/规则编排?

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

活动时间 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,流程还会继续向下执行,不用做任何更改

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

特性

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

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

Code

Talk is cheap. Show me the code…

官方文档:http://waitmoon.com/zh/

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

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

有更好想法或者更多应用场景或者想一起探讨的小伙伴~ 欢迎交流~

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://haidsoft.com/125572.html

(0)
上一篇 2025-09-25 22:20
下一篇 2025-09-25 22:33

相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注微信