导读：相对于传统架构,微服务架构下更需要通过各微服务之间的协作来实现一个完整的业务流程,可以说服务编排是微服务架构下的必备功能。Netflix Conductor作为服务编排的佼佼者，从推出就引起很大关注。本文深入浅出的介绍了起基本功能和设计。
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","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}"}}
任务定义
每个任务的行为都由其模板控制。 任务定义为每个任务提供控制参数，例如超时，重试策略等。任务既可以是由应用程序实现的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语言。
