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

Netflix内容平台工程团队支撑了许多业务，这些业务流程由微服务任务异步驱动的。 其中一些任务是持续数天的长期进程。 这些进程在为全球观众提供字幕方面发挥着至关重要的作用。
比如：

• Studio合作伙伴内容集成
• 来自合作伙伴的基于IMF的内容集成
• 在Netflix中设置新标题
• 接收内容，编码和部署到CDN

传统做法中，这些进程是临时编排的，使用pub/sub 组合起来，直接进行REST调用，并使用数据库来管理状态。 然而，随着微服务数量和流程复杂性的增加，如果没有中央协调器，就无法了解这些分布式工作流（workflow）。
我们将Conductor“作为编排引擎”构建，以满足以下需求，在应用程序中消除了模板，并提供反应流：

• 使用基于JSON DSL 的蓝图定义执行流程。
• 跟踪和管理工作流。
• 能够暂停，恢复和重新启动进程。
• 用户界面可视化处理流程。
• 能够在需要时同步处理所有任务。
• 能够扩展到数百万个并发运行的流程。
• 由客户端提取出来的的队列服务支持。
• 能够通过HTTP或其他方式操作，例如GRPC。

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

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

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

• 流程分散在多个应用程序的代码中
• 通常围绕输入/输出，SLA等存在紧密耦合和假设，PUB/SUB难以适应不断变化的需求
• 几乎没有办法系统地回答“设置电影还有什么没完成”？

为什么是微服务？

在微服务领域，许多业