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

什么是流程/规则编排？

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

首先，我们需要对既有业务做一定程度的抽象，以一个例子开始：
一个简单的国庆节充值活动：

活动时间 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节点)，更改其中一个，另一个也会被更新(因为他们是同一个对象，不存在多个复用节点同步问题)，避免了到处修改时间

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

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