一个Netflix开发的微服务编排引擎,支持可视化工作流定义
source link: https://blog.51cto.com/u_15867943/6021086
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
一个Netflix开发的微服务编排引擎,支持可视化工作流定义
推荐 原创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语言。
Recommend
-
59
作者|赵钰莹 如今的很多应用架构都充斥着大量 API 和微服务,研发人员完成一项功能需要写很多代码才能调用对应 API,如果最初的设计文...
-
18
点击上方“蓝字”关注“AI开发者” 在去年 1 月,Uber 推出了一种与模型无关的机...
-
12
今天再重新整理下我对服务组合和服务可视化编排的一些思考。 从整个服务分层的角度来说,微服务最底层首先提供的是原子服务,再朝上则可以提供更加粗颗粒度的组合服务能力。 为何要进行服务组合和编排? 简单...
-
22
ASW 简介 应用与服务编排工作流(Application Services Workflow,ASW)是对腾讯云服务进行可视化编排,组合成工作流模板的应用程序集成类产品。可以更简单、更直观、更快速地构建和更新应用。 ASW 可以用拖拽组件...
-
10
I.内容提要 定时调度系统(定时任务、定时执行)算是工作中经常依赖的中间件系统,简单使用操作系统的 crontab,或基于 Quartz,xxl-job 来搭建任务调度平台,行业有很多优秀的开源产品和中间件。
-
7
如果你发现浏览你的 Git 仓库非常复杂,我已经为你准备好了工具,来了解一下 Tig。Tig 是一个
-
6
引言:全新的数据集成能力为物联网平台与应用提供高性能的实时数据处理与集成,一直是 EMQX 最重要的能力之一。最新发布的 EMQX 5.0 针对数据集成相关功能进...
-
3
感谢大家阅读本项目系列文章和对项目的支持。分享一下我对这个项目的新的改进。 之前项目做到了流程设计可视化和流程运行结果可视化。 本期发布的版本中实现了中间的运行过程的实时可视化,...
-
0
Nifi 官网地址 https://nifi.apache.org/ Nifi 官网文档...
-
5
编辑导读:业务逻辑的代码繁琐且无用,只能让程序员在做低水平的重复工作。有痛点就会有需求,一些低代码平台推出了可视化逻辑编排能力,能够很好地解决这个问题。本文作者对此进行了分析,希望对你有帮助。
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK