Conductor 作为任务编排的地方

除了作为数据库代理和对象回移植的角色之外，Conductor 服务还充当了一个集中管理工作流执行的地方，这些工作流涉及调度器。重建、调整大小/迁移和构建实例都在这里管理。这样做是为了更好地分离计算节点应该处理的内容和调度器应该处理的内容之间的责任，并清理执行路径。选择 Conductor 是因为为了以同步方式查询调度器，需要在 API 返回响应之后发生，否则 API 响应时间会增加。并且将调度器调用从异步更改为同步有助于清理代码。

为了说明这一点，构建实例的旧流程是

• API 接收构建实例的请求。

• API 向调度器发送 RPC cast 以选择计算节点。

• 调度器向计算节点发送 RPC cast 以构建实例，这意味着调度器需要能够与所有计算节点通信。

  • 如果构建成功，则在此处停止。

  • 如果构建失败，则计算节点决定是否达到了调度器重试的最大次数。如果是，则构建在那里停止。

    • 如果应该重新安排构建，则计算节点向调度器发送 RPC cast 以选择另一个计算节点。

这过于复杂，这意味着调度/重新调度的逻辑分散在整个代码中。对此的答案是将流程更改为以下流程

• API 接收构建实例的请求。

• API 向 Conductor 发送 RPC cast 以构建实例。（或者在 Conductor 配置为使用 local_mode 时本地运行）

• Conductor 向调度器发送 RPC 调用以选择计算节点并等待响应。如果调度器失败，则在 Conductor 处停止构建。

• Conductor 向计算节点发送 RPC cast 以构建实例。

  • 如果构建成功，则在此处停止。

  • 如果构建失败，则计算节点向 Conductor 发送 RPC cast 以构建实例。这是 API 发送的相同的 RPC 消息。

这个新流程意味着调度器只处理调度，计算节点只处理构建实例，而 Conductor 管理工作流。调度器和计算节点中的代码现在更清晰了。