导读：相对于传统架构,微服务架构下更需要通过各微服务之间的协作来实现一个完整的业务流程,可以说服务编排是微服务架构下的必备功能。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难以适应不断变化的需求
- 几乎没有办法系统地回答“设置电影还有什么没完成”？
为什么是微服务？
架构总览
引擎的核心是状态机服务，即Decider服务。 当工作流事件发生时（例如任务完成，失败等），Decider将工作流蓝图与工作流的当前状态相匹配，识别下一个状态，并安排适当的任务，或更新工作流的状态。
Decider与分布式队列一起使用来管理计划任务。我们使用dyno-queues作为分布式延迟队列，dyno-queues使用dynomite作为K-V存储。该队列已于今年早些时候开源，欲知详情请看这里。
Task Worker实现
task由worker应用程序实现，其通过API层进行通信。 woker实现了可由流程引擎调用的REST接口，或者通过定期检查挂起任务的状态来达到此目的。 Worker实际上是幂等的无状态函数。 轮询模型允许处理worker的压力，并在可能的情况下根据队列深度支持自动伸缩。 Conductor提供API以检查worker的工作负载大小。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/24157.html