Orkes Conductor 是一个工作流编排平台，可以运行用户定义的任务并在它们之间路由数据。我们测试了 Orkes Conductor 版本 5.3.2 到 5.5.0-rc2，发现个别任务意外频繁并发执行，这一个问题可能会显著延迟工作流执行，另外还有四个与 startWorkflow 错误或空 ID 相关的小问题，以及三个严重问题，导致 Conductor 永久放弃或忘记工作流执行，或者标记为完成，即使其任务从未运行过。Orkes 已发布版本 5.5.6，修复了所有严重安全问题，同时减少了并发执行和修复了两个 startWorkflow 错误。其他两个 startWorkflow 错误正在调查中。延迟执行与 Conductor 的设计参数一致，不必加以解决。Orkes 已发布一篇与此工作相关的博客文章。这项研究由 Orkes Inc. 资助，并根据 Jepsen 伦理政策进行。背景 工作流编排器是一个执行由小任务组成计算的软件系统。任务在工作流中连接，将某些任务的输出路由到其他任务的输入，决定哪些任务可以被调度以及何时进行，等等。编排器管理工作流及其特定执行，运行任务，持久化状态，并试图使每个执行完成。Conductor 是一个最初由 Netflix 构建并于 2016 年开源的工作流系统。开源版本 Conductor OSS 现在由 Conductor OSS 基金会维护。该基金会由 Orkes 领导，其创始人帮助在 Netflix 构建了 Conductor。Orkes 还提供一个名为 Orkes Conductor 的托管版本，具有附加功能。此分析集中于 Orkes Conductor，简称 Conductor。在 Conductor 中，工作流定义是一个 JSON 结构，定义了必须执行的任务、它们的顺序、输入和输出应是什么，等等。每个工作流定义都有一个名称和版本。例如，工作流定义可以指明，为了收养一只猫，必须首先完成申请，然后安排兽医访问，并从兽医那里收到疫苗接种记录。工作流还可能接受一个输入（例如猫的名字）并生成一个输出（例如收养证书）。一个工作流定义可以被多次运行——比如为每只要收养的猫运行一次。每个实例称为工作流执行，但我们通常简称执行为“工作流”。每个执行都有一个唯一的工作流 ID。在执行期间，一个任务也可能被多次尝试（例如，在发生故障时），每次尝试都会获得一个唯一的执行 ID。有些任务内置于 Conductor。一些是系统任务，例如发出 HTTP 请求或向日志系统（如 Kafka）提交事件。其他被称为操作符——这些提供了控制流，如条件、分叉/合并、循环等。操作符可以执行 ECMAScript 代码以实现用户定义的逻辑。最后还有用户编写的工作任务，以执行系统的“业务逻辑”。要开始执行工作流，可以向 Conductor 发出 API 调用，或者通过消息代理提交事件，或使用 Conductor 内置的定时任务调度器。一旦被确认，Conductor 就会调度工作流的任务并尝试使其完成。架构 Conductor 有五个主要组件。Conductor 服务器是无状态进程，管理工作流和调度执行。它们提供 API 和用户界面，与外部服务交互并跟踪状态。工作流的定义、执行状态和任务结果存储在数据库中，如 Postgres、Cassandra 或 Redis。Conductor 还使用队列——通常是 Redis——将工作分发到各个进程，并存储短期状态。最后，有两个无状态工作者池：标准工作者执行 Conductor 的内置任务，自定义工作者由用户使用各种语言的 SDK 编写。所有工作者连接到 Conductor 服务器，轮询服务器以获取任务，执行任务，然后将结果发送回服务器。每个组件均可独立扩展。任意数量的服务器和工作者可以并发运行，节点可以在任何时间被终止和重新启动。在版本 5.3.2 中，数据库和队列都需要保留所有已确认的写入。然而，版本 5.4.0 引入了一个新选项，使所有队列（除了主要决策队列）可以使用有损存储系统。保证 Conductor 保证“至少一次消息投递”，确保所有消息都是持久的，并将被传递给任务工作者一次或多次。Conductor 还保证工作流最终会终止。“如果工作流已经启动，它将运行到完成，只要所有任务都已完成。”这并不一定意味着……