golang公式引擎_[golang]一个流程引擎的诞生记

缘起

背景

2020年过年时重构了一下组内数据管理平台的工单系统，相关文章可参考：工单系统重构过程。

工单系统重构前，不同类型工单在工单生命周期的每个节点都需要有一个接口实现，这样每加入一种新类型的工单，接口数量就会增加一倍。重构工单系统后，不同类型的工单调用统一的接口，前后端交互时只需要前端传入工单type，后端根据type去调用不同工厂的工单实例，非常方便。

此时，工单系统的uri大概长这样：

/worksheet/add

/worksheet/modify

/worksheet/info

/worksheet/submit

...

这几个接口在线上运行了一段时间非常稳定(这能有啥问题呢~) ，不过随着业务迭代，一些新的需求需要在管理平台上实现：

由于组内的 UFS在线数据服务系统 是一个配置化的系统，其支持业务的方式有两种：

1. 如果业务比较简单，通过配置直接就可以支持；

2. 如果业务过于定制化，需要通过通过配置+定制化开发支持。

而配置是放在数据库里面的，所以很多时候只一条SQL就能支持没有定制业务逻辑的需求。但是这样一来就有了不可控的地方，公司对于代码上线有一套完整的SOP，并通过上线系统来规避可能出现的风险。但是对于数据库里面的配置，没有一套上线系统来保证，如果哪个同学小手一抖，数据库里的配置写错了，且服务集群导入了错误的配置，那整个线上服务可能就炸了。没错，我想说的是配置和代码上线一样，也需要有个灰度的过程。比如说需要有个SOP，定义清楚当db中的配置更新后，先加载到某集群的某一台server上运行一段时间，确定无问题后再把配置加载到集群中的其他机器上，如果服务是多集群的，其他集群也应如此。

组内的 UFS 的数据生产来源有多种，可以是用户读写、离线数据导在线和消息队列等。对于离线数据导在线和消息队列，是需要和外部系统通过RPC做一些交互的。没错，这里想说的是 数据生产的过程需要一些和外部的交互：可能是RPC操作，可能是操作在一些非工单表，此时一个form表单满足不了需求，系统需要一个pipline的模型。

而单一的pipline还是满足不了全部的需求：承接的业务有不同的重要程度和复杂程度。对于比较复杂或重要的业务需要QA同学的支持。而简单且不重要的业务可能在QA同学评估后由业务RD自己把关就可以了。而对于不同的数据来源，这条pipline中需要经过的节点也是不同的。我们可以针对不同数据源的业务分别建立不同的上线SOP的wiki，但是如果只是让人通过手工去保