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

作者：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 元，则执行流程为：

从根节点开始，先执行 ANY
充值时间在 ANY 生效时间内，继续执行
ANY 有两个子节点，先执行第一个子节点 AND
AND 有两个子节点，先执行第一个子节点 ScoreFlow-100
ScoreFlow-100 判断并返回 true
AND 接收到 true，继续向下执行 AmountResult
AmountResult 发放余额并返回 true
AND 子节点执行完毕，接收到两个 true，自己也返回 true
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 节点)，更改其中一个，另一个也会被更新(因为他们是同一个对象，不存在多个复用节点同步问题)，避免了到处修改时间