一. pipeline任务描述
在执行某序列化任务的时候，通常可将任务划分为多个stage分别进行模块化，每一个stage可抽象为一个处理方法、一个处理类或一个处理模块，最简单一个的流程任务（无分支），如下图：
对于一个完整的处理流程有如下说明：
1. 每个处理单元具有业务处理原子性特征，每个处理单元仅处理单一的功能需求
2. 每个处理单元可能有多个来自其他单元的输入数据，也可以向多个其他单元输出数据
3. 某单元的输入可依赖于上一个单元或多个单元的输出，需等待所有的前置单元都处理完才能执行此单元
二. 可能的执行场景
基于以上说明，可以将pipeline的流程简单概括为一下几种可能的执行场景：
样例01表示最简单的流线式模块处理，无分支，前一个节点处理结束再处理下一个节点。
样例02表示单个节点可能有0到N个输入，也可能有1到N个输出；同时，单节点的多个输入可来自不同的节点的任意输出或单节点的多个输出数据流向不同的后置节点。
样例03表示pipeline的处理流程节点不是一棵简单的树形结构，可能存在多个根节点。
三. 利用JSON对pipeline进行结构描述
如何设计一种通用的数据结构来描述一个pipeline,既可以实现以上样例的几种场景，也可以实现其他更复杂的pipeline场景。设计要点：
1. 对pipline中每个抽象节点的实例化描述
2. 对pipeline中每个节点的模块参数的描述（即节点执行需要的配置参数，而非input端口数据）
3. 对pipeline中每个节点的输入输入端口的描述
4. 对pipeline中每个节点的对其他节点输入输入端口依赖关系的描述
最终的实现方式如下(JSON数据)：
其中包括以下几点：
1. pipeline_id 每个pipeline都有一个唯一的ID，多个pipeline同时独立运行时会用到
2. pipeline_items是一个数组，里面每一个大括号都是一个特定类型的模块实例化时需要的信息
3. id为某模块实例化后的ID号，在一个pipeline中此id唯一
4. type为此模块的类型（整个pipeline中涉及到多个类型的模块）
3. parameters为该模块需要执行时需要的特定参数，每个模块的parameters定义可能不同
4. inputs的定义，inputs中定义了一个模块所需输入数据的来源，framNodeId和fromOutputId代表某输入是从哪一个前置模块的哪一个输出端口输出的数据
注：某模块的输入端口的描述名称（input_01，input_02）需要预先在模块对外接口中定义好，并且一一对应，否则可能会导致传递的数据值或者数据类型错乱。
三. PipelineFramework的实现概要
PipelineFramework程序框架用来加载pipeline JSON，组装、调度模块的顺序执行，其实现有以下几个问题需要解决：
1. 一个模块需要执行，如何保证其依赖的所有前置模块都已经执行结束
2. 如何在内存中将每个模块的每个输出端口缓存，提供给后置模块去使用
3. 如何定义所有模块统一的接口，然后使PipelineFramework通过统一的方式调用（类似类的多态性）
第一个问题的解决：
多次全流程模块扫描，每一次拿出尚未执行并且已经满足所有前置条件的模块进行运行，执行结束后将模块ID和执行后的结果保存到内存变量中。当某一次扫描中所有的模块已经被执行了则退出扫描，具体代码如下：
第二个问题的解决：
当每个模块执行结束后的返回结果是一个map类型的数据，key为该模块输出端口的ID（如output_01,output_02）,value为输出数据（由于python弱类型引用，因此value可以为任意类型）,部分代码如下：
第三个问题的解决：
1. 每个模块都封装成类，且包含都两个方法：__init__方法进行参数和输入数据的初始化， module_process进行具体的业务处理（如上图）。
2. 通过定义PipelineModuleFactory进行统一的模块接口获取和调用。
3. 在PipelineFramework中进行统一的调用执行
四. 后续的优化
1. 通过multiprocessing 实现多模块并行执行
2. 模块运行过程监控和重试机制
