说明

从工作的划分和复用上，这种模式是必须

还是积木拼凑的思维，之前的APIFunc实现时，已经发现有一些过程是会被经常复用的。这些连续的过程，可以称之为会话，或者说是链，都是一个意思。

APIFunc在定义的时候，需要在字典中定义若干不重名的函数，所以之前有一个思路是：将一个会话视为root，然后去修改在不同变量或者流程下的名称。

但是从另一个角度考虑，这样的改动会对原来的对象结构以及运行机制产生比较大的变化。另一个思路是，把APIFunc当成是一个可以嵌套的单元来设计，这样不用动目前的对象结构，只是要考虑怎么样增加一个连接的机制。

内容

1 APIFunc的结构

这里提到的APIFunc，更准确的说是是逻辑核心；APIFunc的数据基础(服务流)在之前的文章讨论了(模板镜像 + 自定义配置 + 自定义Worker)。

从顶层来看，APIFunc是一个瀑布图(有向无环图)

我们假设要处理一个表数据，那么这个表数据里有多个变量，每个变量会有长短不一的链，自上而下的看，就像瀑布。

从工作单元来划分，链(会话)是这个图的基础，链有两种类型(一字型、Y型)。其中Y可以进一步分为YMerge和YSplit两个类型。其中一字型是复用的关键，因为流程通常都比较长，是管道。YM和YS也很重要，但是其类型容易穷举，是连接件。

一字型与逻辑的深度，以及并行调度关系较