类似办理业务,一个业务有很多步骤,像数据录入,上级审核,创建账户等等,就像一个个节点一样。我们公司现在采取的办法是直接把这些节点保存在数据库里面,每一个业务都事先通过 SQL 定义好一系列的节点和之间的转移顺序,业务被实例化之后就往数据库的节点表格里面插入,然后通过 MoveNext()这类函数移动节点到下一个。目前碰到了非常多的坑,比如节点里面需要调用的函数是通过函数名字符串储存在表格里的,需要的参数也是,大概例如:
insert into Nodetable Values (Node1, "Callfunction: Dothis, Parameters: {1: getPara(1), 2: getPara(2)}")
调试困难,灵活性也比较低......想请教各位大神比较靠谱点的思路或者常用的技术应该是啥样的。
1
abelmakihara 2019-03-05 14:04:39 +08:00
并不是很能理解 就按照你这个写的逻辑也是很奇怪
直觉上也应该是 Node1 对应 getPara,1 Node2 对应 getPara,2 Node3 对应 Dothis,Node1,Node2 |
2
jaylee77 2019-03-05 14:14:09 +08:00
定义状态啊
|
3
tausi0661 2019-03-05 14:39:17 +08:00
"比如节点里面需要调用的函数是通过函数名字符串储存在表格里的,需要的参数也是"
陨石坑...重构 or 跳槽吧 |
4
KingPL 2019-03-05 14:42:02 +08:00
改成工作流吧
|
5
no1xsyzy 2019-03-05 16:03:21 +08:00 1
我觉得重构成异步 Actor 模型会好一点。
因为 JS 最后用了 Promise 模型导致很多人都知道了 Promise (模式: .then(function(it){}) ),而 Future 非常类似,最后也被 JS 和 Python 采用( async/await 可以视作一种 Future,装作它是同步的,只不过不会阻塞) 结果现在没见什么人提 Actor 模型了。(我因为之前没听说过甚至重新发明了一遍) Actor 模型由许多独立运行的模块( Actor )构成,每个 Actor 知道自己从哪些结点取数据,并将处理后的数据放到哪些结点。而具体的 Actor 数量、种类、它们连接哪些结点、甚至一些具体参数可以由配置文件( YAML )来定义。 你的情况我建议一个 Actor 表示一件需要人来处理的事,结点表示一个业务的状态。 上下游不同的同一件事 或者 相似但不完全相同的事 可以做成一个 Actor 的多个实例,或者同一个 Actor 的多组行为——大概算我多嘴了,这事程序员不可能不这么做。 |
6
zyingfei 2019-03-05 16:57:57 +08:00 via iPhone
赞同 Actor 如果不限框架 Uber Cadence 很好用
|
7
jingxyy 2019-03-05 17:17:51 +08:00
我去年做过一套类似的东西,我们的场景是有很多种不同的业务类型(workflow),各种业务的流程(step)不同,但是固定不变的,比如:
业务 1:先做流程 A,再做流程 B,最后做流程 C 业务 2:先做流程 W,再做流程 X,再做流程 Y,最后做流程 Z 其中每个流程都有一个结果状态,进而还支持一些简单的分支,比如: 业务 3:先做流程 A,若 A 成功(成功即一种结果状态)则做流程 B,否则做流程 C 上面说到,我们每种业务具体的流程是不变的,所以业务 x 的具体流程(workflow 由哪些 step 构成)我们写进了代码逻辑里,然后就有一个核心的函数 next_step 来实现业务流程的决策,大概就是 next_step(workflow_category, prev_step) 然后其实要拓展到完全自由的流程也挺方便,把下一步要做什么流程写进上一步流程的一个字段里就行。 |
8
Yifelse OP @abelmakihara 是这样的,这个语句表示的意思是插入 node1 这个节点,这个节点需要调用 Dothis 这个函数,而函数需要的 2 个参数再调用 getPara 获得
|
9
Yifelse OP @tausi0661 真的这么惨吗...我和几个新手确实都觉得这样做太坑了,但不知道业界好的解决方案是啥样的,话说我们公司已经开发了 4 年,投入也有千万了,现在刚进入 UAT 审核阶段
|
13
zyp0921 2019-03-05 21:20:03 +08:00
状态机啊
|