kelnos参与了工作流引擎的评估并在工作中采取了Conductor，但总体上对此并不满意。默认数据存储区是此基于Netflix特定产品（Dynomite），它是基于Redis构建定制的。普通公司在运营上将其集成到非Netflix基础架构中并不是一件容易的事，而Conductor本身就很难依赖多种服务。
用于工作流/任务的编程模型有些笨拙，在深入研究Java SDK / Client之后，我对代码质量没有深印象（质量一般）。
确实在Netflix有一些联络人来帮助我们，但是在某些方面（例如，dyomite 本身以及它的辅助工具dynomite-manager）却被反应迟钝的维护者抛弃了。
最近，我们开始使用Temporal [0]（néeCadence），虽然它还没有投入生产，但是可以很好地工作，并且同样重要的是，在我们的基础架构中非常容易处理。Temporal的人大多是以前的Uber开发人员，他们曾在Cadence上工作，由于他们围绕Temporal建立业务，因此他们更加专注和反应迅速。
https://temporal.io/
freeqaz：工作流程和编排是我的难题-这就是我们试图简化的 https://refinery.io
Conductor是一项很酷的技术，并且在快速增长的工作流引擎空间中是行之有效的参与者。
我曾经在Uber工作，而那家公司曾有一段时间出现过微服务。他们建立了项目Cadence [0]来减轻这种情况。它在许多方面与导体类似。
一个值得关注的项目是Argo [1]，它是CNCF支持的项目。
也有一些尝试[2]标准化工作流程规范。
Serverless在业务流程引擎必须管理的内容中增加了全新的生机，我很好奇未来的发展趋势。Kubernetes也增加了问题空间的复杂性。
如果有人有兴趣于微服务地狱或用于业务逻辑的复杂状态机，我会很高兴进行聊天。我一直在寻找更多现实世界中的问题来帮助解决（作为一家早期创业公司的创始人），而更多地接触他人正在苦苦挣扎的事情会有所帮助！
0： https://github.com/uber/cadence
1： https://argoproj.github.io/argo/
2： https://serverlessworkflow.github.io/
dap问：感谢您的资源！似乎许多实现都希望在某些微服务体系结构中作为独立管理的服务运行。您是否知道任何应用程序库中实现为库的工作流引擎，可能是由外部数据库支持的存储？我认为，只要数据库支持该模型，您仍然可以拥有一个高度可用的模型。
manyxcxi回：有趣的是，即使Conductor并非旨在如此-这正是我们使用它的方式。尽管如此，在Kotlin和Spring Boot代码库中！
theptip: 略读文档的快速注意事项：
* Conductor实现了一个工作流程编排系统，该系统看起来在最高层次上类似于Airflow，但有一些重要的细节。
*没有“worker”，而是由现有的微服务执行任务。
* Orchestrator不会将工作推送给工作人员（例如，气流触发操作员执行DAG），而是客户端轮询Orchestrator的任务并在找到任务时执行。
我的观点：
如果您已经拥有非常庞大的协作微服务网格，并希望在其任务之上提取业务流程层，那么该系统可能是一个很好的选择。
您在此处执行的大多数操作也可以使用HTTPOperator或GRPCOperator在Airflow中实现，该操作会触发服务来启动其任务。但是，您不会得到诸如暂停之类的东西。另一方面，您确实能够在Airflow操作员中运行简单/一次性任务，而不必构建服务来运行简单的Python函数。
我不确定推/拉是否更好。我认为这在很大程度上取决于您的情况。我倾向于说，在大多数情况下，让Orchestrator通过HTTP推送任务是更好的默认设置，因为您可以简单地负载均衡那些请求并水平扩展您的工作池，并且手动测试管道更容易（例如（对于开发环境）），如果工作人员响应简单的HTTP请求，而不必提供协调器的存根/测试实现。（特别是我正在考虑“在k8s中在本地计算机上运行prod env” －尽管这在Netflix规模上不切实际。）
tupac：我们已经在我的工作场所使用Conductor大约一年了。扎扎实实的基础，但是一旦您深入了解它，文档就很不错了。我们必须求助于github问题，以找到尚未真正记录的相当基本的功能。我觉得Conductor是Netflix开源的东西，然后就被OS社区抛弃了。
例如，没有关于如何使用其Java客户端实现Worker的示例，我们必须挖掘一个博客文章来做到这一点，尽管这非常简单，但是一个非常基本的实现Worker接口的示例将是不错的选择。
他们也没有清楚地说明任务和工作流程之间的确切关系，很难找到互联网上可用的相对复杂的工作流程和任务定义的良好示例，除了Netflix的准系统和他们提供的厨房水槽工作流程之外，这是很糟糕的。默认情况下在当前API上。
配置还提到了很多未记录的字段，例如您可以将持久层换成其他东西，但是我不知道它是如何工作的。
TheColorYellow：惊讶地看到Camunda在这里没有更多提及。
具有成功历史的开源BPMN兼容工作流处理。据推测，高盛（Goldman Sachs）用它来管理他们的内部组织。
目标用例略有不同，但是Camunda确实在微服务编排中大放异彩，我发现实现复杂的工作流和管理任务依赖性非常容易。
MrSaints：我已经在接近生产产能中使用了Conductor，Zeebe和Cadence。这只是我的个人经历。
在我看来，Conductor的JSON DSL有点像噩梦。但除此之外，它的工作还可以。感觉更类似于步进功能。
可以说，一旦您克服了BPMN的最初障碍，Zeebe是最容易上手的。他们的工作处理模型非常简单，因此，以任何语言为其编写SDK都非常容易。最大的缺点是，它还没有准备好投入生产，他们的Slack聊天中一直抱怨它缺乏稳定性，并且性能相对较差。Zeebe不需要外部存储，因为工作流是临时的，可以使用自己的RocksDB和Raft设置进行复制。如果要保留工作流程的历史记录，或者甚至要对其进行管理，则需要导出工作流程并为其编制索引。这最终是一致的。
但是，对于Conductor和Zeebe来说，如果您有足够复杂的在线工作流程，则很难在各自的DSL中对它们进行建模。特别是在您具有动态工作流程的情况下。而且这种复杂性可以转化为业务流程级别的错误，除非运行不同的场景，否则您不会发现这些错误。
Cadence（Temporal）可以很好地处理此问题。您实际上是使用编程语言本身，带有适当的包装器/装饰器和辅助器来编写工作流的。本身无需学习新的DSL。但是，结果是，用一种特定的编程语言为其构建SDK并非易事，目前，稳定的实现是在Java和Go中进行的。性能和可靠性方面，它很棒（依赖于Cassandra，但是有SQL适配器，但是还不成熟）。
我们已经与Temporal合作了一段时间，我们已经对Temporal有了一些解决。我们还探讨了Lyft的Flyte，但它似乎更适合于数据工程和脱机处理。
就像在其他地方提到的那样，我们也使用Argo，但是我认为它与我提到的这些工作流引擎不在同一空间内（它可以更好地处理复杂业务逻辑的编排，而不是像CI这样的简单管道。 / CD或ETL）。
还值得一提的是，我们使用了工作流引擎来减少样板，并减少编写业务流程逻辑/粘合代码所需的时间/精力。您在许多项目中都不知道要执行此操作。我们绝对觉得我们已经成功实现了这一目标。我觉得这是一个令人兴奋的空间。
jiehong：我们在2016年左右开始在我工作的公司中使用它。我们决定使用它来自动为每个产品手动进行新客户的手动设置。它逐渐发展为使用我们自己的安全和权限系统，并且我们还添加了其他数据库支持（我们正在开发开源软件）。我们还更改了Jason API以符合我们公司范围内的标准。
当时，我们希望我们可以托管，维护，开源并且可以正常工作的东西！
如今，内部团队也使用它来自动化他们自己的流程。
我们可能会选择“基于推送”的工作流引擎，也许是基于事件的，主要是出于延迟和负载的原因，但是到目前为止，我们还是可以接受的（尽管有些方法可以监听事件，但这不是那么容易）
如果我没记错的话，Netflix会使用它来自动对节目进行视频编码，但这可能已经过时了。
总体而言，我们对此感到高兴。但是这有一些缺点：我们希望可以将某些服务分离出来（例如只读服务，或者从执行中分离出工作流定义，等等），但是代码并不是如此容易拆分的架构：例如，推送工作者执行任务计算的结果会触发当前工作流，以确定要调度的下一个任务，但是它是在内部完成的，而不是通过定义的接口进行的）api的安全性并不那么容易，因为它不是真正的模块化（不同于数据库实现，这很棒）。尽管这一点正在研究中，所以对未来充满希望。