什么是流程/规则编排？
所谓编排，就是让已有的节点通过不同的组织方式完成不同的需求。
首先，我们需要对既有业务做一定程度的抽象，以一个例子开始： 一个简单的国庆节充值活动：
活动时间 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://124.221.148.247/zh/
GitHub：https://github.com/zjn-zjn/ice
Gitee：https://gitee.com/waitmoon/ice
微信公众号： waitmoon
有更好想法或者更多应用场景或者想一起探讨的小伙伴~ 欢迎交流~
