来源:InfoQ
作者:The Netfix Tech Blog
译者:刘志勇
Netflix内容平台工程团队运行由微服务上执行的任务的异步编排驱动的多个业务流程。其中一些是长期运行的流程,跨越几天。这些流程在准备好标题流式传输给全球的观众上发挥关键作用。
这些流程的几个实例是:用于内容提取的Studio合作伙伴集成
基于IMF的内容提取我们的合作伙伴
在Netflix中设置新标题的过程
内容提取、编码和部署到CDN
传统上,这些流程中的一些已经以ad-hoc方式使用pub/sub的组合来编排,进行直接REST调用,并使用数据库来管理状态。然而,随着微服务数量的增长和进程的复杂性增加,在没有中央编排器的情况下,获得对这些分布式工作流的可见性变得困难。
我们将Conductor构建为一个编排引擎,以满足以下要求,取出在应用程序中需要的样板,并提供一个反应流:基于蓝图。基于JSON DSL的蓝图定义执行流程。
跟踪和管理工作流。
能够暂停、恢复和重新启动进程。
能够扩展到数百万个并发运行的进程流。
由从客户端抽象的排队服务支持。
能够通过HTTP或其他传输方式进行操作,如 gRPC。
Conductor是为满足上述需求而开发的,并且在Netflix已经使用了将近一年。到目前为止,它已经帮助编排超过260万个流程流,从简单的线性工作流到运行多天的非常复杂的动态工作流。
今天,我们为广泛的社区开源了 Conductor,希望从有类似需求的人那里学习,并增强其能力。你可以在这里找到Conductor的开发文档。
为什么不是点对点编排?
随着点对点任务编排,我们发现越来越多的业务需求和复杂性难以扩展。Pub/sub模型工作的最简单的流程,但很快强调了与该方法相关的一些问题:流程流“嵌入”多个应用程序代码中。
通常情况下,有关于输入/输出,SLA等的紧耦合和假设,使其更难适应不断变化的需求。
几乎没有办法系统地回答“What is remaining for a movie's setup to be complete”?
为什么是微服务?
在微服务世界中,许多业务流程自动化是通过跨服务编排来驱动的。Conductor可以跨服务实现编排,同时提供对其交互的控