本文讲的是Netflix Conductor：一个微服务编排工具【译者的话】这篇文章介绍了Netflix Conductor，一个微服务编排工具，为微服务执行复杂业务流程提供了一种思路，希望对读者有一定的启发。
【深圳站｜3天烧脑式Kubernetes训练营】培训内容包括：Kubernetes概述、架构、日志和监控，部署、自动驾驶、服务发现、网络方案等核心机制分析，进阶篇——Kubernetes调度工作原理、资源管理及源码分析等。
Netflix内容平台工程团队运行许多业务流程，这些业务流程是通过在微服务上执行异步编排任务来驱动的。其中一些流程运行时长多达数天。这些流程在让一切准备好，以呈现给全球用户的过程中，起到了至关重要的作用。
这些流程的几个例子：
按照传统做法，这其中一些进程已经使用发布/订阅模式，直接进行REST调用以及使用数据库来管理状态的组合进行了自组织的编排。然而，随着微服务数量的增长和流程的复杂性不断增加，如果没有中央协调人员，这些分布式工作流程的可见性将变得困难。
我们构建了“作为业务流程引擎”的Conductor，以满足以下要求，消除在应用程序中对模板的需求，并提供流程相关的执行动作：
Conductor是为满足上述需求而建立的，目前已在Netflix上使用。到目前为止，它已经帮助协调了260多万个流程流程，从简单的线性工作流程到跨越多天运行的非常复杂的动态工作流程。
今天，我们是开放Conductor给更广泛的社区，希望从具有相似需求的其他人那里学习，增强其能力。您可以在 这里 找到 Conductor 的开发人员文档。
在发动机的核心是一个状态机服务又名的决策服务。随着工作流事件的发生（例如任务完成，故障等），决策者将工作流程蓝图与工作流程的当前状态相结合，识别下一个状态，并安排适当的任务和/或更新工作流的状态。
决策者使用分布式队列来管理计划任务。我们一直在 Dynomite 之上使用 dyno-queue 来管理分布式延迟队列。队列“食谱”今年早些时候开放， 这里 是博客文章。
共有3个工作任务和一个控制任务（错误）涉及：
这三个任务由不同的worker实现，这些worker使用任务API轮询待处理的任务。这些是理想的幂等任务，对任务的输入进行操作，执行工作并更新状态。
每个任务完成后，决策者根据蓝图（对应于工作流实例的版本）评估工作流实例的状态，并标识要排定的下一组任务，如果完成所有任务，则完成工作流。
下图是UI的一个样例：
【深圳站｜3天烧脑式Kubernetes训练营】培训内容包括：Kubernetes概述、架构、日志和监控，部署、自动驾驶、服务发现、网络方案等核心机制分析，进阶篇——Kubernetes调度工作原理、资源管理及源码分析等。
Netflix内容平台工程团队运行许多业务流程，这些业务流程是通过在微服务上执行异步编排任务来驱动的。其中一些流程运行时长多达数天。这些流程在让一切准备好，以呈现给全球用户的过程中，起到了至关重要的作用。
这些流程的几个例子：
- 整合工作室合作伙伴的内容摄取
- 从我们的合作伙伴摄入基于IMF的内容
- 在Netflix中设置新的标题的过程
- + 内容摄取，编码和部署到CDN
按照传统做法，这其中一些进程已经使用发布/订阅模式，直接进行REST调用以及使用数据库来管理状态的组合进行了自组织的编排。然而，随着微服务数量的增长和流程的复杂性不断增加，如果没有中央协调人员，这些分布式工作流程的可见性将变得困难。
我们构建了“作为业务流程引擎”的Conductor，以满足以下要求，消除在应用程序中对模板的需求，并提供流程相关的执行动作：
- 以蓝图为主，基于JSON DSL的蓝图定义了执行流程；
- 跟踪和管理工作流；
- 能够暂停，恢复和重新启动流程；
- 用户界面可视化流程；
- 能够在需要时同步处理所有任务；
- 能够扩展到数百万个同时运行的流程；
- 由客户抽象的排队服务提供后端支持；
- 能够通过HTTP或其他传输操作，例如gRPC；
Conductor是为满足上述需求而建立的，目前已在Netflix上使用。到目前为止，它已经帮助协调了260多万个流程流程，从简单的线性工作流程到跨越多天运行的非常复杂的动态工作流程。
今天，我们是开放Conductor给更广泛的社区，希望从具有相似需求的其他人那里学习，增强其能力。您可以在 这里 找到 Conductor 的开发人员文档。
为什么不对等编排?
通过对等任务编排，我们发现随着业务需求和复杂性的增长难以扩展。发布/订阅模式为最简单的流程工作，但很快突出了与该方法相关的一些问题：- 流程“嵌入”在多个应用程序的代码中；
- 通常，关于输入/输出，SLA等的紧耦合和不确定性，使其难以适应不断变化的需求；
- 不清楚当前执行的任务属于整个流程的哪个阶段；
为什么是微服务?
在微服务世界中，许多业务流程自动化是通过协调服务来驱动的。Conductor可以在服务之间进行协调，同时提供对它们的相互作用的控制和可见性。有能力在微服务之间进行协调，也帮助我们利用现有服务来构建新流程或更新现有流程，以便使用Conductor非常快速，有效地提供了更容易采用的方法。架构概览
在发动机的核心是一个状态机服务又名的决策服务。随着工作流事件的发生（例如任务完成，故障等），决策者将工作流程蓝图与工作流程的当前状态相结合，识别下一个状态，并安排适当的任务和/或更新工作流的状态。
决策者使用分布式队列来管理计划任务。我们一直在 Dynomite 之上使用 dyno-queue 来管理分布式延迟队列。队列“食谱”今年早些时候开放， 这里 是博客文章。
任务执行者的实现
由Worker实现的Tasks通过API层进行通信。Worker通过实现可由业务流程引擎调用的REST端点或实现定期检查待处理任务的轮询机制来实现此目的。Worker是幂等无状态的功能。轮询模型允许我们处理worker背后的压力，并在可能的情况下根据队列深度提供自动可扩展性。Conductor提供API来检查可用于自动调整工作实例的每个工作人员的工作负载大小。
API层
API通过HTTP协议公开 - 使用HTTP允许轻松地与不同的客户端集成。然而，添加另一个协议（例如，gRPC）应该也是可能的并且相对简单。存储
我们使用Dynomite“作为存储引擎”以及Elasticsearch来索引执行流程。存储API可插拔，可适用于各种存储系统，包括传统的RDBMS或Apache Cassandra，如no-sql存储。核心概念
工作流
工作流程使用基于JSON的DSL进行定义。工作流程蓝图定义了一系列需要执行的任务。每个任务都是控制任务（例如，分支，连接，决策，子工作流程等）或工作任务。工作流定义被版本化，提供管理升级和迁移的灵活性。一个工作流定义：{
"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}"
}
}
任务定义
每个任务的行为由其称为任务定义的模板控制。任务定义为每个任务提供控制参数，例如超时，重试策略等。任务可以是由应用程序实现的工作任务或由业务流程服务器执行的系统任务。Conductor提供开箱即用的系统任务，如决策，叉，连接，子工作流程以及允许插入自定义系统任务的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个工作任务和一个控制任务（错误）涉及：
- 内容检查：检查输入位置的文件是否正确/完整
- 编码：生成视频编码
- 发布：发布到CDN
这三个任务由不同的worker实现，这些worker使用任务API轮询待处理的任务。这些是理想的幂等任务，对任务的输入进行操作，执行工作并更新状态。
每个任务完成后，决策者根据蓝图（对应于工作流实例的版本）评估工作流实例的状态，并标识要排定的下一组任务，如果完成所有任务，则完成工作流。
UI
UI是监控和排除工作流执行的主要机制。 UI通过允许基于包括输入/输出参数在内的各种参数的搜索来提供对流程的非常需要的可见性，并提供蓝图的可视化呈现以及所采用的路径，以更好地了解流程执行。对于每个工作流实例，UI提供每个任务执行的详细信息，具体如下：- 任务安排的时间戳，由worker获取并完成。
- 如果任务失败，失败的原因。
- 重试次数
- 执行任务的主机。
- 在任务完成后提供给任务和输出的输入。
下图是UI的一个样例：
原文链接：Netflix Conductor : A microservices orchestrator（翻译：付辉）
原文发布时间为：2017-04-29
本文作者：付辉
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：Netflix Conductor：一个微服务编排工具
