国产开源工作流引擎，什么情况下，需要使用工作流引擎？

「本文重点介绍关于工作流引擎。」

什么情况下，需要使用工作流引擎？

1、工作流具有的特性  

这篇文章递进式地介绍工作流除了在业务流程抽象和控制的作用外，还可以实现其他细分领域的赋能。

首先工作流拥有以下几个特性：

流程的逻辑控制和可编排性

流转状态的持久化和可视化

节点功能的自由度

分布式异步执行能力

流程的逻辑控制和可编排性，这个本身就是工作流的初衷，是为了解决复杂的行业流程而抽象出的一套协议，他是工作流的根基，也是目前业界（金融、保险领域等）使用最多的特性。

流转状态的持久化是说整个流程图就是一个巨型且复杂的状态机，并且他是存在硬盘上的，服务的重启都会重新恢复它当前的状态，可视化则是可以直观的明白当前流转的进程。

节点功能的自由度，工作流其本质就是节点和其连线的流转，流转方向由连线条件控制，流程的阻塞和并行由网关控制。节点的功能可以任意实现，不用拘泥于“人工任务”、“HTTP任务”等。

分布式异步执行能力，这一点非常重要，也是后续赋能细分领域的根基。工作流提供一种节点异步执行的能力，工作流本身的部署是多实例无状态的，所有实例都会去“抢占”任务列表来执行，所以只要任务丢入队列中，它将来会在哪个实例上执行是无从知晓且等价的。

以上简单解释了一下工作流的4个重要特性，那么从第4点“分布式异步执行能力”出发，我们可以做到具有“分布式特性”、“状态持久可追溯”、“可编排”的任何事情，下面我就递进式地说一下几个可探索的方向。

2. 工作流赋能分布式计算编排上面讲到，工作流具有节点逻辑自由+异步分布式执行的特点，利用这两个特点，我们可以编写无数个计算类型的节点，把他组合在一起，通过一定的编排，实现计算，下面用流程图举一个例子。整

个流程是一个完全的异步服务任务，服务任务带着计算逻辑，任务被丢入到一个持久化的任务池当中，每个应用实例都会去获取任务来执行，理论上讲，一个完整的流程实例的每个节点的计算和执行会被打散到不同实例上去执行，从而实现了分布式计算。

3. 工作流+无服务函数计算增强分布式计算编排第2个标题中，利用异步服务任务实现了分布式简单计算，但缺点是：每增加一个逻辑就需要新增加一个节点工作流的本质是推动状态流转和状态持久化，对于计算资源的管理不是专业的所以，在当下Serverless推动的情况下，工作流可以结合函数计算的轻量和弹性容器的特性，实现计算能力的外包。当用户是内嵌式的工作流，那么实现新的节点相对来说比较简单，如果说工作流作为云服务，那么要让用户自由实现新节点的逻辑脚本是非常麻烦的。如果把计算逻辑外包给Serverless容器，就相对容易得多，用户侧实现逻辑自由度提高了（语言多样，触发方式多样），工作流服务侧的压力也会减小很多，业务执行的结果（或错误结果）工作流只需要转告就行了。使用Serverless扩展工作流，可以使工作流的计算能力近乎无限大。

大数据计算     

如果使用到了函数式计算，小数据量可以通过HTTP或者MQ的方式来传输并启动工作流的推动，但如果是巨量数据（大数据计算），则会带来一个I\O瓶颈，所以在函数式计算的底部，通常会配置一个数据存储组件，而流程的启动往往是从数据的读取（按分布式模块Block读取）开始，而非通过IO传输。

4. 工作流赋能微型服务处理链工作流通过Serverless得到了强大的计算能力后，可以赋能微型服务，下面举两个例子。中小微型门店解决方案

上图是小商家“菜鸟相馆”的服务，对于小商家来说，这些服务自己是不能实现的，就算能实现，加上部署服务器和维护，成本是不划算的。如果是云上提供一种轻量函数+工作流的编排，可以使用户低成本、几乎0门槛的方式展开寸照打印的自动服务，其节约的人力和时间成本是非常可观的。

低代码

工作流在微型应用领域同样可以赋能另一个巨无霸-“低代码平台”。低代码平台号称几乎无代码完成业务逻辑。其无非就是囊括了表单引擎即支持数据的变动和传递，再一个就是配合门户引擎的展示控件拖拽+报表引擎的统计能力，可以快速搭建一个大屏式的门户网站。但业务终究是会由流程来体现的，它作为核心来推动工作或者功能的继续，配合上常用的功能插件和链接中心的数据收发，几乎可以讲一个很大的故事。

5. 工作流+DevOps

最近突然听到很多DevOps的词，我大概看了看定义，心想难道不就是CI（持续继承）么，为什么又冒出来这么一个词。DevOps是老故事换新词，并不新鲜，就是Development和Operations的合并，直白点就是把开发和运维利用自动化的方式结合了，当初说的CI持续集成其实只是一个核心部分（优化了提交->编译->部署的过程），而DevOps又把不是讲得更大了，在各个阶段实现自动化，持续继承->运维反馈->持续继承....无限循环，其最终目的还是敏捷开发。下面我拿图举个简单的例子，说明工作流配合DevOps的理念。

上图就大概表现了一下工作流是如何自动化地串联起来所有角色，实现DevOps，从而达到敏捷开发的（有些细节不要纠结，大概就是这个意思）。从需求产生的开端，到开发人员的完成，一直到线上的代码更新都全部交由工作流人工审批功能和服务任务来实现，极大地减少了沟通成本和角色立场不同所带来的矛盾。

6. 工作流实现微服务编排微服务的概念已经提出很多年了，说白了他就是把各种模块拆分开来单独部署成服务，一是利于功能的专注和维护人员的专一性、易替换性，第二个是微服务更容易把控性能和成本的粒度，重要的甚至可以做成集群或给予更加重要和昂贵的资源，其他的就不多赘述。但是微服务随之也带来很多恶心的东西：消息如何传递，同步调用还是异步调用？调用链的监控和问题的定位事务性把握困难长流程业务需要状态持久化针对以上问题，工作流天然解决这些问题，工作流的同步天然支持事务，异步支持重推。工作流支持流程流转状态的查看，对于流程流转节点的统计和问题的定位非常简单。工作流本身作为状态管理，他的状态肯定是持久化的，所以这一点也支持。除此之外，工作流还支持异常状态捕获、边界时间补偿、超时时间处理等，下面就拿电商这个经典的例子大概讲一下。

上图是使用事件总线来联系微服务的方式和工作流编排微服务的方式来对比，虽然说事件总线的方式并不确切，但我想表达的意思是，微服务虽然解耦了很多东西，也很灵活，但付出的代码是交流起来非常复杂。而用工作流来编排的微服务，看起来就清爽得多（当然，服务任务需要额外的处理和加持，才能实现微服务的功能）。

7. 工作流+Serverless+大数据赋能机器学习的模型训练机器训练模型是一个数据量频率高，数据杂乱且持续性强的强计算应用，利用上面讲到的工作流+Serverless的模型可以极大的利用计算资源来帮助训练模型。这个大家可以去看看Netflix弄的meson，以下是我扒的图。

可以看出，工作流控制着数据接收、数据清洗、训练模型、输出模型的流程流转。

8. 工作流赋能细分领域可能需要准备的新特性流程逻辑控制的增强，循环，打断，边界事件的增强流程实例的重复利用（流程实例池），即一开始初始化流程实例池，不能手动启动流程实例，只能从池里拿出可用的。流程流转历史的取舍，避免无效资源占用流程启动和流程结束功能的增强（接收数据和下发数据）以上的特性只是临时想到的一些，如果要实现本文章所说的领域赋能，需要扩展和增强的东西还有很多。

「上述就是小编为大家整理的工作流引擎」

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。