我想了解您作为 Stack Overflow 读者使用工作流引擎解决的具体问题，如果您没有自己开发，那么使用了哪些库/框架。我还想知道在何时工作流引擎不是最佳选择，以及如何选择更简单的状态机类型的任务列表/工作列表/任务管理应用。
问题： 我正在寻找第一手经验。
我查看过一些资源：
问题： 我正在寻找第一手经验。
我查看过一些资源：
8个回答
64
我有偏见，因为我是StonePath的主要作者。
我曾为美国国务院、日内瓦人道主义除雷中心、数家财富500强企业以及最近的华盛顿特区公立学校系统开发工作流应用程序。每次我看到一款试图成为业务流程的主要参考工具的“工作流引擎”，我都会看到组织机构在与工具周旋的情况。这可能是因为这些解决方案一直是由供应商或产品驱动的，然后最终出现了一个战术性团队的“顾问”，不断地向应用程序提供反馈…但正因为如此，当我听到基于流程的工具承诺“将工作流定义集中在一个地方并使其可重复”时，我倾向于产生消极反应。
我非常喜欢Ruote - 我已经关注该项目有一段时间了，如果我需要那种解决方案，它将是我愿意尝试的下一个工具。StonePath的目的与Ruote完全不同。
Ruote对Ruby普遍有用，
StonePath针对的是Ruby编写的Web框架Rails。
Ruote是关于长期经营的业务流程及其相关定义（备注-
ruote的活跃开发已停止）。StonePath是关于管理基于状态的工作流和任务的。
坦白地说，我认为从外部看这种区别可能微妙 - 许多时候相同类型的业务流程可以以任一方式表示 - 基于状态和任务的模型往往映射到我的思维模型。
让我描述一下基于状态的工作流的亮点。
状态
想象一个围绕类似抵押贷款或护照续期处理的工作流。随着文件在“办公室”中移动，它会从一个状态转移到另一个状态。
如果您负责此文档，您的老板要求您提供状态更新，您会说像这样的话：
- “正在录入数据”...
- “我们现在正在检查申请人的证书”...
- “我们正在等待质量审核”...
- “我们完成了”...等等。
这些是基于状态的工作流中的状态。我们通过转换从状态到状态移动，例如“批准”、“应用”、“退回”、“拒绝”等等。这些通常是动作动词。像这样的事情一直被建模为状态机软件。
任务
状态/任务型工作流的下一部分是任务的创建。
任务是一项工作单元，通常具有截止日期和处理说明，将工作项（例如贷款申请或护照续期）与用户的收件箱连接起来。
- 任务可以并行或依次发生
- 在进入状态时可以自动创建任务
- 当人们意识到需要完成工作时手动创建任务
- 要求在我们可以进入新状态之前完成任务。
此类行为是可选的，并且是工作流程定义的一部分。
这种行为可以比此更深入，我在《实用程序员杂志》第4期中写了一篇文章。请查看上面提供的存储库链接以获取更新后的PDF版本。
在过去几个月与StonePath合作中，我发现基于状态的模型非常适合RESTful Web架构 - 特别是任务和状态转换在嵌套资源上很好地映射。请期待我在这个主题上发布更多文章。
- bokmann
2
2太棒了！非常期待学习如ruote这样的工作流引擎和stonepath这样的状态/任务引擎之间微妙差别的更多知识，因为以前没有经历过，很难看清从何处开始。我已经阅读了所有关于stonepath和ruote以及其他白皮书的内容，所以像这样一些“第一手经验”般的知识将真正缩短上手时间。再次感谢。 - Lance
@bokmann为什么不直接将状态保存在表的单个列中呢？ - AminM
31
我很偏袒，我是ruote的作者之一。
变体1）状态机附加到一个资源（文档、订单、发票、书籍、家具等）。
变体2）状态机附加到名为任务的虚拟资源上。
变体3）解释工作流程定义的工作流引擎。
现在您的问题标记为“BPM”，我们可以扩展为“业务流程管理”。每个变体中的管理是如何发生的？
在变体1中，业务流程（或工作流程）分散在应用程序中。附加到资源的状态机强制执行与资源相关的工作流程的某些方面。可能会有其他资源具有自己的状态机，遵循相同的业务流程。
在变体2中，工作流可以围绕任务资源集中，并由该资源周围的状态机表示。
在变体3中，通过解释称为工作流定义（或业务流程定义）的资源来实施工作流。
业务流程更改时会发生什么？是否值得使用工作流引擎来管理业务流程？
大多数状态机库都具有1组状态+转换。大多数工作流引擎都是工作流程定义解释器，并允许多个不同的工作流同时运行。
更改工作流程的成本是多少？
这些变体不是相互排斥的。我看过许多例子，其中工作流引擎改变了多个资源的状态，其中一些受到状态机保护。
我也经常使用变体3 + 2，用于人类任务：在运行进程实例的某些点上，工作流引擎将任务（工作项）交给人员参与者（资源任务被创建并放置在“就绪”状态）。
您可以通过仅使用变体2（任务管理器变体）来完成很长一段路程。
我们还可以提到变体0），其中没有状态机、工作流引擎，业务流程分散或硬编码在应用程序中。
你可以问很多问题，但如果你不花时间阅读答案并不费力去尝试和实验，就不会走得太远，也永远无法获得何时使用这个或那个工具的技巧。
- jmettraux
3
非常感谢您的回答，它帮助我更好地理解了一些事情。对于新手来说，没有足够的区分来掌握正式的工作流建模并开始编写代码；似乎所有的资料都是90年代晚期的Java白皮书。您和Stonepath的David正在大力打破这个障碍。也许有一天，学习Rails就像学ABC一样容易。我将在几天内开始尝试任务管理器变体。谢谢。 - Lance
链接似乎已经失效了？ - rogerdpack
1该项目现在已经停止。 - user7401700
8
我是开源Temporal Workflow Engine的作者之一，最初我们在Uber开发了Cadence。Temporal与大多数现有的工作流引擎的区别在于它专注于开发人员，并且具有极高的灵活性和可扩展性（每秒更新数以万计，开放工作流程可达数十亿）。工作流程以面向对象的程序编写，引擎确保在主机故障的情况下完全保留工作流对象的状态，包括线程堆栈和局部变量。
“您使用工作流引擎解决了哪些问题？”
Temporal几乎用于任何超出单个请求回复范围的后端应用程序。使用示例包括：
“你使用了哪些库/框架？”
Temporal是一个自包含的服务，用Go编写，并配备了Go、Java、Typescript、Python、.NET和PHP客户端SDK。唯一的外部依赖是存储。支持Cassandra、MySQL和PostgreSQL。Elasticsearch可用于高级索引。
Temporal还支持异步跨区域（使用AWS术语）复制。
什么时候一个更简单的状态机/任务管理系统就足够了呢？
开源的Temporal服务可以自行托管，也可以使用temporal.io提供的云服务。因此，构建任何自定义的状态机/任务管理系统的开销总是比使用Temporal要高。在公司外部，需要设置服务和存储。如果您已经有一个SQL数据库，通过docker镜像进行服务部署非常简单。docker还可用于在个人计算机或笔记本上运行本地Temporal服务进行开发。
“您使用工作流引擎解决了哪些问题？”
Temporal几乎用于任何超出单个请求回复范围的后端应用程序。使用示例包括：
- 分布式CRON作业
- 管理ML/数据流水线
- 对业务事件做出反应。例如Uber的行程事件。工作流可以根据接收到的事件累积状态，并在必要时执行活动。
- 将服务部署到Mesos / Kubernetes
- CI流水线实施
- 确保在收到请求时多个服务调用完成。包括SAGA模式实现
- 管理人类工作任务（类似于Amazon MTurk）
- 媒体处理
- 客户支持票务路由
- 订单处理
- 类似于ChaosMonkey的测试服务
和其他许多任务
另一组用例是基于将现有的工作流引擎移植到Temporal上运行。实际上，几乎任何现有的引擎工作流规范语言都可以移植到Temporal上运行。这样，一个后端服务就可以支持多个特定领域的工作流系统。“你使用了哪些库/框架？”
Temporal是一个自包含的服务，用Go编写，并配备了Go、Java、Typescript、Python、.NET和PHP客户端SDK。唯一的外部依赖是存储。支持Cassandra、MySQL和PostgreSQL。Elasticsearch可用于高级索引。
Temporal还支持异步跨区域（使用AWS术语）复制。
什么时候一个更简单的状态机/任务管理系统就足够了呢？
开源的Temporal服务可以自行托管，也可以使用temporal.io提供的云服务。因此，构建任何自定义的状态机/任务管理系统的开销总是比使用Temporal要高。在公司外部，需要设置服务和存储。如果您已经有一个SQL数据库，通过docker镜像进行服务部署非常简单。docker还可用于在个人计算机或笔记本上运行本地Temporal服务进行开发。
- Maxim Fateev
2
1现在您已经使用过Temporal IO，我很感兴趣听听您对它的另一个看法...Temporal IO是一个好的库（实际上是工作流服务器）来管理以人为中心的任务，例如审批工作流程（多个人员在多个步骤中批准请求）。还是更适合像微服务编排、SAGA模式实现等事物？ - SoftwareSavant
1人类任务是 temporal.io 的一个非常常见的用例。请参阅具有人类任务组件的 checker 案例研究。https://docs.temporal.io/blog/how-temporal-simplified-checkr-workflows - Maxim Fateev
4
在之前的项目中，我为医疗保健行业的一组政府表单添加了一些工作流类型的规则。需要由最终用户填写表单，根据一些答案会安排在以后的日期填写其他表单。还有一些外部事件会取消已安排的表单或安排新的表单。
示例流程如下： 患者入院 -> 安排初始评估表格 -> 安排季度审查表格 -> 患者死亡 -> 取消审查 -> 安排出院评估表格。
许多其他规则是基于患者年龄、入院地点等因素的。这是一个ASP.NET应用程序，规则基本上是数据库中的一个表。我添加了脚本，以便在表单完成时运行脚本来确定下一步该做什么。这是一个可怕的设计，完全可以使用适当的工作流引擎来解决。
示例流程如下： 患者入院 -> 安排初始评估表格 -> 安排季度审查表格 -> 患者死亡 -> 取消审查 -> 安排出院评估表格。
许多其他规则是基于患者年龄、入院地点等因素的。这是一个ASP.NET应用程序，规则基本上是数据库中的一个表。我添加了脚本，以便在表单完成时运行脚本来确定下一步该做什么。这是一个可怕的设计，完全可以使用适当的工作流引擎来解决。
- Ben Dempsey
3
我是Imixs-Workflow的作者之一。Imixs-Workflow是一个基于BPMN 2.0并完全集成到Java EE技术堆栈中的开源工作流引擎。
我已经独立开发工作流引擎超过10年了。我会尝试简要回答您的问题：
我已经独立开发工作流引擎超过10年了。我会尝试简要回答您的问题：
>您使用工作流引擎解决了哪些问题？
我开始考虑工作流引擎的个人目标是避免在应用程序中硬编码业务逻辑。企业应用程序中的许多东西都可以重复使用，因此保持可配置是有意义的。例如：
- 发送通知
- 查看未完成任务
- 将任务分配给某个人
- 描述当前任务
从这个功能列表可以看出，我谈论的是人类中心的工作流。简而言之：人类中心的工作流引擎回答以下问题：谁负责任务，下一个需要被通知的人是谁？这些是业务需求中的典型问题。
>您使用了哪些库/框架？
5年前，我们开始重新实现Imixs-Workflow引擎，重点关注BPMN 2.0。BPMN是流程建模的通用标准。让我惊讶的是，我们突然能够描述甚至高度复杂的业务流程，这些流程可以被可视化和执行。我建议每个人都使用BPMN来建模业务流程。
>在什么情况下，一个简单的状态机/任务管理系统就足够了？
如果您只想跟踪业务对象的状态，则简单的状态机就足够了。这种情况发生在您开始将“状态”属性引入您的对象模型时。但是，如果您需要具有责任、日志记录和流程控制的业务流程，则状态机不再足够。
>额外问题：您如何区分任务管理和工作流引擎？
这正是许多提到的工作流引擎之间的差异所在。对于人类中心的工作流，您通常需要任务管理来在人类参与者之间分配任务。对于流程自动化，这一点并不重要。引擎执行某些任务即可。无法比较任务管理和工作流引擎，因为任务管理始终是工作流引擎的功能之一。
- Ralph
2
我有用Activiti BPMN 2.0引擎处理高性能和高吞吐量数据传输过程的经验，在网络节点基础设施中进行。基本任务是允许配置和监控此类传输过程，并控制每个网络节点（即请求节点1通过特定的传输层向节点2发送数据文件）。
可能会有成千上万个进程同时运行，每天总共可能会有数万或几十万个进程。
有大量不同的流程定义，但并非必须要求系统操作员创建自定义工作流。因此，BPM引擎本身的主要用途是稳健、可扩展以及允许监控每个流程流程。
最终它基本上运作正常，但我们从那个项目中学到的是，BPMN平台，或者更确切地说是Activiti引擎，不是这样一个高吞吐量系统的最佳选择。
主要的挑战包括任务执行优先级、数据库锁定、执行重试等与BPM本身相关的问题。因此，我们不得不开发自定义的处理方式，例如：
可能会有成千上万个进程同时运行，每天总共可能会有数万或几十万个进程。
有大量不同的流程定义，但并非必须要求系统操作员创建自定义工作流。因此，BPM引擎本身的主要用途是稳健、可扩展以及允许监控每个流程流程。
最终它基本上运作正常，但我们从那个项目中学到的是，BPMN平台，或者更确切地说是Activiti引擎，不是这样一个高吞吐量系统的最佳选择。
主要的挑战包括任务执行优先级、数据库锁定、执行重试等与BPM本身相关的问题。因此，我们不得不开发自定义的处理方式，例如：
- 在BPM中处理重试的情况，当节点没有可用的工作人员来执行任务时，或者当节点根本没有运行时。
- 在单个过程中执行并行传输任务，并同步结果（成功/失败）。
我不知道其他BPMN引擎是否更适合这种场景，因为BPMN主要用于涉及用户交互的长时间运行的业务任务，性能可能不是我们案例中的主要问题。
- Adam Hošek
1
我自己开发了一个工作流引擎来支持文档的分阶段处理——编目、发送到图像处理（我们使用的是隐私保护软件），如果需要，发送到验证，然后发布，最后将其送回客户。在我们的情况下，我们有大量的文档需要处理，因此有时我们需要单独运行每个服务以控制交付和资源使用。这个概念很简单，但需要高性能和分布式处理，我们找不到任何现成的产品适合我们的需求。
- Otávio Décio
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接