本文讲述了作者在重构工单系统后，为满足业务需求，如何设计和实现一个基于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，但是如果只是让人通过手工去保
最低0.47元/天 解锁文章
扫一扫
160
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
