转载

Netflix Conductor: 微服务编排器

Netflix Content Platform Engineering团队运行着很多商务流程，这些流程由在微服务上执行的异步编排驱动。其中一些是会运行好几天的长流程。这些流程在准备好视频流以供全球观众观看的过程中起着至关重要的作用。

这些流程包括：

为了内容吸收的Studio合作伙伴的集成
来自合作伙伴的基于 IMF 的内容吸收
在Netflix里搭建新字幕的流程
内容吸收，编码，以及部署到CDN上

传统上，这些流程中的一些是使用pub/sub（发布/订阅）模式，直接调用REST以及使用数据库管理状态这些方法的组合来实现，以ad-hoc的方式完成整体编排。但是，随着微服务数量的增加，以及流程复杂度的提高，如果没有中央式的编排，理解这些分布式工作流会变得非常困难。

我们将Conductor构建为“编排引擎”，来解决如下需求，代替应用中对样板文件的需要，同时提供交互式流程：

基于Blueprint。基于JSON DSL的blueprint定义执行流。
跟踪并且管理工作流
能够暂停，恢复以及重启流程
视图化流程流的用户接口
能够在需要时同步处理所有任务
能够扩展为百万级并发运行流程流。
对由客户抽象出的队列服务支撑
能够做基于HTTP或其他传输协议，比如gRPC的操作。

构建Conductor是为了满足上述需求，至今已经在Netflix使用了大概一年时间。到目前为止，它已经帮助编排了超过260万流程，这些流程包括简单的线性工作流，也包括非常复杂的运行数天的动态工作流。

现在，我们将 Conductor 开源，放到了社区里，希望能够从有类似需求的其他公司学习，并且加强它的功能。可以在这里找到Conductor的开发人员文档。

为什么不使用点对点编排？

我们发现，使用点对点任务编排很难随着增长的业务需求和复杂度而完成扩展。Pub/sub模型适用于最简单的流程，但是很快你就会发现该方案的一些问题，包括：

流程流被“嵌入到”多个应用程序的代码里
通常，围绕输入/输出，SLA等存在很强的耦合以及假定，这使得更加难以适应变化的需求
几乎没有办法系统性地回答“某个电影的搭建还剩下什么任务有待完成的”？
###为什么选择微服务？
在微服务的世界里，很多业务流程自动化是由跨服务的编排驱动的。Conductor在启用跨服务的编排的同时，能够提供对微服务之间交互的控制和洞察。拥有跨微服务的编排能力还帮助我们利用已有服务构建新的流，或者更新已有流让其非常快速地就可以使用Conductor，高效地提供了引入Conductor的快捷方式。

架构概览

该引擎的核心是状态机服务，也称为Decider服务。随着工作流事件的发生（比如，任务完成，失败等），Decider将工作流blueprint和该工作流的当前状态组合起来，确定下一个状态，并且调度合适的任务，并且/或者更新该工作流的状态。

Decider和一个分布式队列协同工作来管理调度的任务。我们在 Dynomite 之上使用 dyno-queues 来管理分布式延迟队列。该队列的recipe在今年早些时候已经开源了，这里是相关的博客文章。

任务Worker的实现

任务，通过worker应用程序实现，通过API层通信。Worker有两种实现方式，要么通过可以被编排引擎调用的REST端点来实现，要么通过池循环来周期性检查待定任务实现。Worker想要设计成幂等的无状态功能。池模型允许我们处理worker上的反压力，并且可以提供基于队列深度的自动扩展能力。Conductor提供API监督每个worker的工作负载大小，可以用来自动扩展worker实例。

Worker和引擎的通信

API层

API通过HTTP暴露——使用HTTP使得可以轻松地和不同的客户端集成。同时，添加另一种传输协议（比如，gRPC）应该是可能的并且相对直接。

存储

我们使用 Dynomite “作为存储引擎”，以及Elasticsearch索引执行流。存储API是可插拔的，并且能够适应多种不同的存储系统，包括传统的RDBMS或者Apache Cassandra这样的no-sql存储。

核心观点

工作流定义

工作流定义使用基于DSL的JSON来定义。工作流blueprint定义需要执行的一系列任务。每个任务要么是一个控制任务（比如，fork（分支），join（合并），decision（决策），sub workflow（子工作流）等等），要么是一个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 Workflow，以及一个SPI，允许集成自定义的系统任务。我们也增加了对HTTP任务的支持，可以辅助调用REST服务。

任务定义的JSON片段：

{

"name": "encode_task",

"retryCount": 3,

"timeoutSeconds": 1200,

"inputKeys": [

"sourceRequestId",

"qcElementType"

],

"outputKeys": [

"state",

"skipped",

"result"

],

"timeoutPolicy": "TIME_OUT_WF",

"retryLogic": "FIXED",

"retryDelaySeconds": 600,

"responseTimeoutSeconds": 3600

}

输入/输出

任务的输入是一个map，可能是工作流初始化的一部分，或者其他任务的输出。这样的配置允许在工作流里路由输入/输出，或者允许其他任务作为输入，这样该任务可以在之上执行操作。比如，编码任务的输出可以提供给发布任务作为部署到CDN的输入。

定义任务输入的JSON片段：

{

  "name": "name_of_task",

  "taskReferenceName": "ref_name_unique_within_blueprint",

  "inputParameters": {

    "movieId": "${workflow.input.movieId}",

    "url": "${workflow.input.fileLocation}"

  },

  "type": "SIMPLE"

}