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

导读：相对于传统架构,微服务架构下更需要通过各微服务之间的协作来实现一个完整的业务流程,可以说服务编排是微服务架构下的必备功能。Netflix Conductor作为服务编排的佼佼者，从推出就引起很大关注。本文深入浅出的介绍了起基本功能和设计。

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。

关键概念