一个Netflix开发的微服务（api）编排引擎，支持可视化工作流定义

Netflix内容平台工程团队支撑了许多业务，这些业务流程由微服务任务异步驱动的。 其中一些任务是持续数天的长期进程。 这些进程在为全球观众提供字幕方面发挥着至关重要的作用。比如：Studio合作伙伴内容集成；来自合作伙伴的基于IMF的内容集成；在Netflix中设置新标题；接收内容，编码和部署到CDN。

传统做法中，这些进程是临时编排的，使用pub/sub 组合起来，直接进行REST调用，并使用数据库来管理状态。 然而，随着微服务数量和流程复杂性的增加，如果没有中央协调器，就无法了解这些分布式工作流（workflow）。

Netflix构建了"Conductor"作为编排引擎，以满足以下需求，在应用程序中消除了模板，并提供反应流：

• (1)使用基于JSON DSL 的蓝图定义执行流程。
• (2)跟踪和管理工作流。
• (3)能够暂停，恢复和重新启动进程。
• (4)用户界面可视化处理流程。
• (5)能够在需要时同步处理所有任务。
• (6)能够扩展到数百万个并发运行的流程。
• (7)由客户端提取出来的的队列服务支持。
• (8)能够通过HTTP或其他方式操作，例如GRPC。

Conductor旨在满足上述需求，现在已在Netflix使用了将近一年。 迄今为止，它调度超过260万个工作流，从简单的线性工作流到运行多天的非常复杂的动态工作流。如今Conductor已经开源，希望Conductor可以服务于有类似需求的场景，并提升其能力。

1.为什么不进行点对点编排？

随着业务需求和复杂性的增长，使用点对点任务编排会难以扩展。 发布/订阅模型适用于最简单的流程，也有一些问题：

(1)流程分散在多个应用程序的代码中

• (2)通常围绕输入/输出，SLA等存在紧密耦合和假设，PUB/SUB难以适应不断变化的需求
• (3)几乎没有办法系统地回答"设置电影还有什么没完成"？
• 2.为什么是微服务(api)？

在微服务领域，许多业务流程自动化都是通过协调服务来实现的。 Conductor支持跨服务的协调，同时提供交互式控制和可视性。 能够跨服进行微服务协调，有助于利用现有服务构建新流程或更新现有流程，从而非常快速地普及Conductor。

3.架构总览

引擎的核心是状态机服务，即Decider服务。 当工作流事件发生时（例如任务完成，失败等），Decider将工作流蓝图与工作流的当前状态相匹配，识别下一个状态，并安排适当的任务，或更新工作流的状态。

Decider与分布式队列一起使用来管理计划任务。我们使用dyno-queues作为分布式延迟队列，dyno-queues使用dynomite作为K-V存储。

4.Task Worker实现

task由worker应用程序实现，其通过API层进行通信。 worker实现了可由流程引擎调用的REST接口，或者通过定期检查挂起任务的状态来达到此目的。 Worker实际上是幂等的无状态函数。 轮询模型允许处理worker的压力，并在可能的情况下根据队列深度支持自动伸缩。 Conductor提供API以检查worker的工作负载大小。

5.API层

API通过HTTP公开 - 使用HTTP可以轻松地与不同客户端集成。 添加其他协议（例如gRPC）也是很简单的。

6.存储

我们使用Dynomite作为存储引擎，并使用Elasticsearch来索引执行流程。 存储API是可插拔的，可以适用于各种存储系统，包括传统的RDBMS或Apache Cassandra。

7.关键概念

（1）工作流定义

使用基于JSON的DSL定义工作流。 工作流蓝图定义了一系列需要执行的任务。 每个任务是控制任务（例如，fork，join，决策，子工作流等）或worker任务（译者注：提供具体的数据处理功能）。 工作流定义支持版本，可以灵活地管理升级和迁移。

工作流定义概述：

{"name": "workflow_name","description": "Description of workflow","version": 1,"tasks": [{"name": "name_of_task","taskReferenceName": "ref_name_unique_within_blueprint","inputParameters": {"movieId": "${workflow.input.movieId}","url": "${workflow.input.fileLocation}"},"type": "SIMPLE",... (any other task specific parameters)},{ }...],"outputParameters": {"encoded_url": "${encode.output.location}"}}

（2）任务定义

每个任务的行为都由其模板控制。 任务定义为每个任务提供控制参数，例如超时，重试策略等。任务既可以是由应用程序实现的worker任务，也可以是由编排服务执行的系统任务。 Conductor提供一些开箱即用的系统任务，例如Decision，Fork，Join，Sub Workflows，并且允许加入自定义系统任务的SPI。 我们已经添加了对HTTP任务的支持，这有助于调用REST服务。

任务的输入是一种映射，其作为工作流实例化的一部分或某些其他任务的输出。 允许将来自工作流或其他任务的输入/输出作为随后执行的任务的输入。 例如，可以将编码任务的输出作为输入提供给发布任务以部署到CDN。

任务输入定义：

{"name": "name_of_task","taskReferenceName": "ref_name_unique_within_blueprint","inputParameters": {"movieId": "${workflow.input.movieId}","url": "${workflow.input.fileLocation}"},"type": "SIMPLE"}

8.具体例子

这里总共有3个worker任务和一个控制任务：内容检查：检查输入文件是否正确/完整；编码：生成视频编码；发布：发布到CDN。这三个任务由不同的worker实现，这些worker使用任务API轮询待处理的任务。 这些任务是幂等任务，worker根据给予任务的输入进行操作，执行处理流程并更新状态。在完成每个任务时，Decider会根据蓝图（对应于工作流实例的版本）评估工作流实例的状态，并标识要调度的下一组任务，或者在完成所有任务后标记工作流为完成。

9.UI

UI是监视和排除工作流程执行故障的主要手段。 通过基于各种参数（包括输入/输出参数）的搜索，UI实现了处理流程的可视化，并提供蓝图和其采取的执行路径的可视化表示，以更好地理解流程执行的过程。 对于每个工作流实例，UI提供每个任务执行的详细信息，并提供以下详细信息：

（1）任务调度的时间戳，worker接收并完成任务的时间戳。