Netflix内容平台工程团队支撑了许多业务，这些业务流程由微服务任务异步驱动的。其中一些任务是持续数天的长期进程。这些进程在为全球观众提供字幕方面发挥着至关重要的作用。

比如：

(资料图片仅供参考)

Studio合作伙伴内容集成来自合作伙伴的基于IMF的内容集成在Netflix中设置新标题接收内容，编码和部署到CDN

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

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

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

Conductor旨在满足上述需求，现在已在Netflix使用了将近一年。迄今为止，它调度超过260万个工作流，从简单的线性工作流到运行多天的非常复杂的动态工作流。

如今Conductor已经开源，我们希望Conductor可以服务于有类似需求的场景，并提升其能力。你可以在此处找到Conductor的开发人员文档。

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

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

流程分散在多个应用程序的代码中通常围绕输入/输出，SLA等存在紧密耦合和假设，PUB/SUB难以适应不断变化的需求几乎没有办法系统地回答“设置电影还有什么没完成”？

为什么是微服务？

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

架构总览

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

Decider与分布式队列一起使用来管理计划任务。我们使用dyno-queues作为分布式延迟队列，dyno-queues使用dynomite作为K-V存储。该队列已于今年早些时候开源，欲知详情请看这里。

Task Worker实现

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

API层

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

存储

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

关键概念

工作流定义

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

工作流定义概述：

{"name":"workflow_name","deion":"Deion 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}"}}

任务定义

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

任务定义：

{"name":"encode_task","retryCount":3,"timeoutSeconds":1200,"inputKeys": ["sourceRequestId","qcElementType"],"outputKeys": ["state","skipped","result"],"timeoutPolicy":"TIME_OUT_WF","retryLogic":"FIXED","retryDelaySeconds":600,"responseTimeoutSeconds":3600}

输入输出

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

任务输入定义：

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

具体例子

这里总共有3个worker任务和一个控制任务：

内容检查：检查输入文件是否正确/完整编码：生成视频编码发布：发布到CDN

这三个任务由不同的worker实现，这些worker使用任务API轮询待处理的任务。这些任务是幂等任务，worker根据给予任务的输入进行操作，执行处理流程并更新状态。

在完成每个任务时，Decider会根据蓝图（对应于工作流实例的版本）评估工作流实例的状态，并标识要调度的下一组任务，或者在完成所有任务后标记工作流为完成。

UI

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

任务调度的时间戳，worker接收并完成任务的时间戳。如果任务失败，失败的原因是什么。重试次数执行任务的主机。任务的输入和输出。

以下是UI展示：

其他方案AMAZON SWF

早期我们使用过AWS SWF。然而考虑到SWF的一些限制，我们选择构建Conductor：

需要基于蓝图的编排，而不是SWF要求的编程决策。用于工作流的可视化UI。更需要同步API（而不是纯粹基于消息的方式）需要为工作流和任务索引输入和输出，以及基于此索引的搜索工作流的能力。需要维护一个单独的数据存储来保存工作流事件以从故障，搜索等中恢复。

Amazon Step Function

最近宣布的AWS Step Functions添加了一些我们在编排引擎中需要的功能。Conductor有可能采用states语言(译者注：这也是一种基于Json的用于描述状态机的语言)来定义工作流程。

统计数据

以下是我们一年多来在生产环境运行Conductor的统计数据。内容平台工程中使用这些工作流来支持内容获取和编码等工作。

未来功能

支持AWS Lambda（或类似）功能，作为serverless 任务。与容器编排框架更紧密的集成，允许worker实例自动扩展。记录每个任务的执行数据，有助于故障排除。能够从UI创建和管理工作流蓝图。支持states语言。