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语言。