总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 cnblogs.com/duck-and-duck/p/14436373.html 「MCTW」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

第1关

一天，老板找到我，说要做个简单的工作流引擎。 我查了一天啥是工作流，然后做出了如下版本：

图片

  • 按顺序添加任意个审批人组成一个链表，最后加一个结束节点
  • 记录当前审批人，当审批完后，审批人向后移动一位
  • 当审批人对应结束节点时，流程结束

老板：简陋了点。

第2关

老板又来了：要支持会签节点。

我又查了一天啥是会签节点，发现会签节点就是一个大节点，里面有很多审批人，当这个大节点里的所有人都审批通过后，才能进入下一个节点。

我想了一个星期，推翻了原来的链表式设计：

图片

结构上我做了如下调整:

  • 把节点分为两大类：简单节点(上图中长方形)和复杂节点(上图中圆形)。
  • 用一棵树表示整个流程，其中叶子节点都是简单节点，简单节点都是叶子节点。
  • 每个简单节点里都有且仅有有一个审批人。
  • 复杂节点包含若干个子节点。
  • 加入会签节点: 会签节点激活后，所有的子节点都可以审批，当所有的子节点都审批完毕后，会签节点完成。
  • 加入串行节点：子节点只能从左到右依次进行审批，当最后一个子节点审批完成后，串行节点完成。
  • 所有的工作流最外层都是一个串行节点，该节点完成后代表整个工作流完成。 为了控制审批流程，我设计了一些节点状态:
  • Ready : 可以进行审批操作的简单节点是Ready状态。
  • Complete : 已经审批完成的节点状态。
  • Future: 现在还没有走到的节点状态。
  • Waiting : 只有复杂节点有该状态，表示在等待子节点审批。

借助上述规则，一次带会签节点的工作流审批过程如下：

图片

图片

老板：有点意思。

第3关

老板来了：要支持并行节点。

我查了一下午啥是并行节点，发现并行节点是一个包含很多审批人的大节点，这个大节点里任何一个人审批通过，则该节点就完成。 然后很快就加入了并行节点：

  • 并行节点是一个复杂节点，该节点激活时，任何一个子节点都可以进行审批，且任何一个子节点是完成状态时，该节点完成。 加入新状态 Skip :
  • 当一个并行节点的子节点状态为非( Ready , Waiting )时，其它兄弟节点及其子节点的状态被置为 Skip 。 举个栗子🌰：

图片

老板：这个设计添加新节点还挺方便的。

第4关

老板又来了：节点要支持嵌套，比如会签节点里有个并行节点，并行节点里又有个复杂节点，要可以嵌套任意层的那种。 我：其实已经支持了~

图片

  • 能无限扩展的树形结构可以支持任意复杂流程。

老板：小伙子有点东西！

第5关

老板又来了：要支持条件节点。

工作流附带一个表单，要根据表单的内容确定下一步进入哪个分支。

经过几天的冥思苦想，我加入了条件节点：

  • 条件节点类似并行节点，只不过只有满足条件的子节点才能进入接下来的审批。

图片

老板：已阅。

第6关

老板又来了：审批人多加两种类型，比如可以从表单中选择下一个审批人，还有根据发起人不同选择不同的审批人。 经过一番考虑，我把简单节点分成了3类：

  • 第一种：审批人是写死的。
  • 第二种：审批人从表单中读取。
  • 第三种：根据发起人和一个映射函数，算出审批人。比如 get_主管("钱某") 得到钱某的主管 李某。

图片

老板：嗯。

第7关

老板又来了：节点可以从前往后审批，那能不能从后往前驳回？ 我: ……

首先实现了驳回到发起人的功能，相当于一切从头开始：

  • 只有Ready状态的节点有权利驳回。（就像只有Ready状态的节点有权利审批一样）

图片

老板：你小子偷懒。

第8关

老板又来了：先实现驳回到上一个审批人吧。

驳回到上一个审批人其实是个很复杂的逻辑，因为工作流中的节点可以无限嵌套，所以如何确定上一个状态有哪些审批人并不简单。 牺牲了一些头发，我终于实现了驳回上一级的功能：

图片

老板：阅。

第9关

老板又来了：实现一个驳回到任意节点的功能。 我发现这个需求并不难实现：

  • 不断的驳回上一级，直到Ready状态的节点包含要驳回到的节点为止。 老板：嗯。

第10关

老板又来了：在普通节点加一个时间限制，要是在规定时间内没完成就显示已超时。 我：还有这种需求? 不过还是实现了。

图片

此时我明白了需求和头发呈负相关，需求越多，头发越少。

第11关

老板又来了：加一个代理功能，比如有件事让你审批，但是你拿不准，那就转给拿得准的人审批。 马上我发现这个需求跟以往有本质的不同，以往的工作流的节点关系一开始就是固定的，就是在发起流程之前确定的，但是现在要在审批过程中更改。

无非是加了一些班，掉了一些头发，最终设计了如下方案：

  • 代理操作的本质是，新建一个并行节点作为本节点的父节点，再新建一个兄弟节点放代理人，这样自己和代理人都能审批通过。
  • 代理操作可以无限嵌套，即代理人也可以找人代理。

图片

第12关

老板又来了：能不能再加一个取消代理的功能？ 。。。我已经宠辱不惊了，加就加：

  • 取消代理是代理的逆操作
  • 如果代理人审批过了那就不能取消代理

图片

第13关

老板又来了：给每个节点加个前后置条件吧，满足前置条件才能进入该节点，满足后置条件该节点才能审批完成。 我的内心：啊老板再见，啊老板再见吧再见吧再见吧！ 我的嘴：好的老板，收到收到。 后来：后来我真的给每个节点加了前后置条件，与此同时审批逻辑的相关代码增加了一倍。

第14关

老板又来了：现在有的工作流已经非常复杂了，审批起来耗时较长，能不能对每个进行中的工作流计算一个指标：直观的显示目前审批进行的百分比。 我：收到。 其实跟之前的需求比起来这个并不复杂，因为不涉及核心逻辑的改动，本质只是输入一棵树形结构然后根据不同节点的状态输出一个整数。 经过测试思考，最终敲定的方案如下：

  • 工作流完成的百分比指的是树中最右侧Ready状态的节点到最左侧节点的距离 / 最右侧节点的距离。

第15关

老板又来了：能不能给每个节点挂两个可以执行的脚本，分别在开始审批该节点和审批完成该节点后执行？ 我：收..到。 后来我当然实现了这个功能，同时也发现正值壮年的我已经秃了。

后记

老板是清华毕业的高才生，不然大概想不出这么多巧夺天工的需求，后来老板把这一套工作流系统卖给了广*证券等公司，我也去别的公司各奔前程，当然那个时候我以为我还有前程。

开始做这个工作流的时候我刚刚本科毕业，后来从这家公司公司离职的时候看镜子已经垂垂老矣。这已经是3年前的事情了，现在回想起那些加班改工作流的日子，仍然心惊。

最后愿天下的同行们都没有bug，身心健康，攒的钱够在一线城市买两套房，在若干年后能无病无灾的过上领养老金的休闲退休生活。

文章目录
  1. 1. 第1关
  2. 2. 第2关
  3. 3. 第3关
  4. 4. 第4关
  5. 5. 第5关
  6. 6. 第6关
  7. 7. 第7关
  8. 8. 第8关
  9. 9. 第9关
  10. 10. 第10关
  11. 11. 第11关
  12. 12. 第12关
  13. 13. 第13关
  14. 14. 第14关
  15. 15. 第15关
  16. 16. 后记