缘起
背景
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，但是如果只是让人通过手工去保证，难免会出现一些问题，如果有一个流程系统把这些SOP流程像代码上线系统一样也落实下来，那么整个在线系统服务的稳定性也会大大增强。
为什么要造轮子
因此就有了在数据管理平台上加入流程引擎的需求，流程系统在业内是一个非常常见的需求，业内有标准的建模标准，公司内部也有公共的流程系统，但是在捋清了业务需求之后还是决定自己做一个。原因大概有这些：
前期调研了业界的BPMN(Business Process Modeling Notation: 业务流程建模与标注)，它是BPM及workflow的建模语言标准之一，定义了业务流程图。一般BPMN的模型是一个图模型，但我们的业务需求更贴近一个链表模型(pipline)。在BPMN中，用网关这个对象做为不同条件分支，而我们的业务中没有网关的概念，条件分支这个概念下沉到了工单状态中。
image.png
由来
模型设计
那么，如何从0到1实现一个能用的流程系统，并和之前的工单系统结合起来使用呢~
首先抽象一下需求：
对于不同的业务，需要建立不同的上线SOP(也就是不同的流水线)，一个流程会包含多个节点(也就是链表中的元素)
一个工单有若干种状态，一个流程实例中不同节点在不同工单状态下对于不同身份的用户可执行不同动作。 这句话比较绕，举个例子 :对于一个新建的工单来说，工单的状态为初始化，此时普通用户可以执行的动作为填写工单。当用户填写完工单之后，工作流节点进行流转，工单的状态为未审批，此时对于管理员可以执行的动作为通过/拒绝工单以及查看工单，而对于普通用户可以执行的动作只有查看工单。流程中当一个动作的结果为某个状态时，工单的当前节点需要进行流转(可能是向前流转，可能是向后流转)
用户可以根据对应id查询到自己创建的流程实例信息
明确了需求之后，就可以进行模型设计了~
对于需求1：一个流程涉及到的节点是固定的。不同业务需要的流程不同，所以这块需要灵活配置，我们组的习惯是把配置写到数据库里，这样的好处是不需要上线，这次同样把流程的元信息写入了数据库的表里，一个流程对应多条记录，一条记录代表一个流程的一个节点。后续如果流程特别多，这里也可以考虑搞个接口通过前端托拉拽来配置流程节点元信息。
对于需求2：数据库做一个json结构的字段去处理 在不同工单状态下对应不同角色可执行的动作不同这个需求，json的schema大概是如下所示，其中 event 用来判断工单当前的状态是否满足条件，action用来表示满足event时用户可执行的动作。与前端交互时，当用户执行一个动作之后工单的状态发生变化，最新的状态下用户可执行那些动作用display字段展示，如果满足event，display字段为true,前端展示对应的action，反之不展示此action。而对于流转的需求，无非就是得到链表的nextNode，preNode和headNode, 在元信息里配好即可。
{
"user":[
{
"event":"{{status}} == 0",
"action":"AddWorksheet"
},
{
"event":"{{status}} == 1 || {{status}} == -1",
"action":"GetWorksheetInfo"
},
{
"event":" {{status}} == -1",
"action":"ModifyWorkSheet"
}],
"admin":[
{
"event":"{{status}} == 0",
"action":"AddWorksheet"
},
{
"event":"{{status}} == 1 || {{status}} == -1",
"action":"GetWorksheetInfo"
}]
}
对于需求3：需要一个getworkflowInstanceInfo的接口，根据数据库里流程实例的id，结合流程元信息表，拼接出一个完整的流程链表给前端。这里同样给前端返回一个大json结构，schema大概是这样：
{
"id": 666,
"workflow_ins": [
{
"name": "aaa",
"cname": "开始",
"next": "bbb",
"activity": "xxx",
"description": "开始的描述"
},
{
"name": "bbb",
"cname": "新建xx工单",
"next": "ccc",
"activity": "[{\"event\":\"\",\"action\":\"GetWorksheetInfo\",\"caction\":\"查看\",\"display\":true}]",
"description": "新建xx工单的描述"
},
{
"name": "ccc",
"cname": "结束",
"next": "",
"activity": "yyy",
"description": "结束的描述"
}
],
"cur_node": "xxx",
"worksheet_type": "hzhzh",
"user_name": "xiaoming",
"status": "wait",
"create_time": "2020-05-20 00:00:00",
"update_time": "2020-05-21 00:00:00"
}
这样捋下来，模型涉及到对象就比较清晰了：
对于流程节点，用链表来表示；
对于工单状态，是一个有限状态机(FSM)的模型；
对于用户角色，我们系统中的用户角色比较简单，直接用白名单表示管理员用户即可；
对于可执行动作，这块是对应之前的工单系统的接口，复用即可；
代码设计
对照着需求，三个api就可以完成流程引擎和前端交互的需求， 第一个API用来 初始化流程引擎 ，根据用户传入的参数调用不同的流程引擎实例；第二个API用来 执行流程动作; 第三个API用来查看当前流程引擎实例的信息。
对于执行流程动作这个接口，首先根据前端传入的actionParam确认需要执行的动作，这里对应之前的工单系统中的动作，而各个动作有一些公共的前置后置操作，这里实现了一个动作工厂(ActionFactory)，拿到工厂实例之后再根据工单类型去调用不同工单所执行的操作，这里需要一个工单工厂(WorksheetFactory)，同样会执行一些公共操作。交互逻辑如图所示：
image.png
工单工厂的UML图：
image.png
动作工厂的UML图：
image.png
在Get(Action/Worksheet)Ins这个方法中，由于后续工单和动作可能会很多，没有用if-else 或者是switch-case，用一个Map来得到实例。在DoAction的具体实现中，由于传入的参数是一个map, 各种工单参数是struct，所以这里还需要用点反射把map转换为struct(吐槽一下, golang的反射好难用....)。
这样，如果需要引入新类型的工单，在工单工厂注册实例并实现工单动作即可，如果要引入新的工单动作，需要在动作工厂描述好对应的行为。
交互设计
有了流程系统之后，前后端交互方式也发生了变化，从api上看，原来的5个api是围绕工单的生命周期进行前后端交互的，后续有新的工单动作加入，则需要加入新的api。
image.png
而新的API是围绕流程引擎而来的，只需要三个就可以和前端进行交互了(初始化流水线、执行动作、查看流水线信息)。前后端交互变得简单，后续即使工单需要加入新的动作，也不需要引入新的API。
image.png
反思
目前这套流程引擎已经上线跑了一段时间，对这套流程引擎做一个小总结：
优点
有了这套系统，可以解决业务上线过程中，流程不规范，信息没有及时同步到上下游等问题，同时整个pipline直观的展示给用户，用户对整个业务上线流程会更熟悉，这套系统是可以提高稳定性和提升效率的~
缺点
对于工单状态的流转，更多是和动作绑定在一起。比如执行一个接口后，系统用一条SQL去修改工单的状态，这样代码里有一些当前状态的检查，这样大量的if不是太美观，后续考虑用一个模型统一管理工单的状态，比如说行为树(BehaviourTree)。
参考
欢迎关注我的个人公众号： 薯条的自我修养
网友评论