一个Netflix开发的微服务（api）编排引擎，支持可视化工作流定义

发布时间: 2020-10-15

       Netflix内容平台工程团队支撑了许多业务，这些业务流程由微服务任务异步驱动的。 其中一些任务是持续数天的长期进程。 这些进程在为全球观众提供字幕方面发挥着至关重要的作用。比如：Studio合作伙伴内容集成；来自合作伙伴的基于IMF的内容集成；在Netflix中设置新标题；接收内容，编码和部署到CDN。

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

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

       (1)使用基于JSON DSL 的蓝图定义执行流程。

       (2)跟踪和管理工作流。

       (3)能够暂停，恢复和重新启动进程。

       (4)用户界面可视化处理流程。

       (5)能够在需要时同步处理所有任务。

       (6)能够扩展到数百万个并发运行的流程。

       (7)由客户端提取出来的的队列服务支持。

       (8)能够通过HTTP或其他方式操作，例如GRPC。

       Conductor旨在满足上述需求，现在已在Netflix使用了将近一年。 迄今为止，它调度超过260万个工作流，从简单的线性工作流到运行多天的非常复杂的动态工作流。如今Conductor已经开源，希望Conductor可以服务于有类似需求的场景，并提升其能力。

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

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

       (1)流程分散在多个应用程序的代码中

       (2)通常围绕输入/输出，SLA等存在紧密耦合和假设，PUB/SUB难以适应不断变化的需求

       (3)几乎没有办法系统地回答“设置电影还有什么没完成”？

2.为什么是微服务(api)？

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

3.架构总览

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

       Decider与分布式队列一起使用来管理计划任务。我们使用dyno-queues作为分布式延迟队列，dyno-queues使用dynomite作为K-V存储。

4.Task Worker实现

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

5.API层

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

6.存储

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

7.关键概念

       （1）工作流定义

       使用基于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}"
   }
   }

       （2）任务定义

       每个任务的行为都由其模板控制。 任务定义为每个任务提供控制参数，例如超时，重试策略等。任务既可以是由应用程序实现的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
       }

       （3）输入输出

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

任务输入定义：

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

8.具体例子

       这里总共有3个worker任务和一个控制任务：内容检查：检查输入文件是否正确/完整；编码：生成视频编码；发布：发布到CDN。这三个任务由不同的worker实现，这些worker使用任务API轮询待处理的任务。 这些任务是幂等任务，worker根据给予任务的输入进行操作，执行处理流程并更新状态。在完成每个任务时，Decider会根据蓝图（对应于工作流实例的版本）评估工作流实例的状态，并标识要调度的下一组任务，或者在完成所有任务后标记工作流为完成。

9.UI

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

       （1）任务调度的时间戳，worker接收并完成任务的时间戳。

       （2）如果任务失败，失败的原因是什么。

       （3）重试次数

       （4）执行任务的主机。

       （5）任务的输入和输出。

       以下是UI展示：

本文内容转载自：CSDN论坛 blog.csdn.net

原文作者：Sqdmn

原文地址：https://blog.csdn.net/Sqdmn/article/details/104505320

作者: Sqdmn