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

什么是流程/规则编排区块链？

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

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

活动时间 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接收到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…

官方文档：/

GitHub：

Gitee：

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

END

这里有最新开源资讯、软件更新、技术干货等内容

点这里 ↓↓↓ 记得 关注✔ 标星⭐ 哦~