微服务编排NetflixConductor(7.4)

，这就是服务编排要做的事情。如果无法满足上面的核心，那谈不上服务编排。

今天谈下开源的微服务编排Netflix Conductor，先说下具体的场景，这个是Netflix内容平台工程团队运行由微服务上执行的任务的异步编排驱动的多个业务流程。其中一些是长期运行的流程，跨越几天。这些流程在准备好标题流式传输给全球的观众上发挥关键作用。这些流程的几个实例是：

• 用于内容提取的Studio合作伙伴集成
• 基于IMF的内容提取我们的合作伙伴
• 在Netflix中设置新标题的过程
• 内容提取、编码和部署到CDN

传统上，这些流程中的一些已经以ad-hoc方式使用pub/sub的组合来编排，进行直接REST调用，并使用数据库来管理状态。然而，随着微服务数量的增长和进程的复杂性增加，在没有中央编排器的情况下，获得对这些分布式工作流的可见性变得困难。我们将Conductor构建为一个编排引擎，以满足以下要求，取出在应用程序中需要的样板，并提供一个反应流：

• 基于蓝图。基于JSON DSL的蓝图定义执行流程。
• 跟踪和管理工作流。
• 能够暂停、恢复和重新启动进程。
• 能够扩展到数百万个并发运行的进程流。
• 由从客户端抽象的排队服务支持。
• 能够通过HTTP或其他传输方式进行操作，如 gRPC。

基于上面介绍可以看到Netflix Conductor最重要的还是实现了基本的工作流定义，任务定义，任务的连接，整个工作流的任务调度和监控等基本能力。

官方参考文档 ： https://netflix.github.io/conductor/

实例参考文档 ： https://cloud.tencent.com/developer/article/1367734

对于具体的功能说明和介绍参考上面两篇文章即可，在此不再重复进行描述，只对看完了整个Netflix Conductor功能实现后做一下简单总结。

1. 任务节点的定义虽然可以定义详细的输入和输出，但是任务节点并不是服务引用节点，任务节点具体需要开发实现类来进行实现。那么我们场景里面说的任务节点即服务节点，任务的输入或输出就是服务的输入或输出是无法实现的，如果要实现也需要进行大量的定制开发才能够支持。

2. 微服务编排完成后可以形成一个新的Http Rest服务接口，这个是我们需要的。同时对于编排完成的workflow本身是可以实现灵魂的任务监控和任务调度的，满足基本的流程引擎该有的功能。

3. 没有看到可以进行可视化服务编排设计的地方，但是对于编排完成的模型文件可以展现为可视化的流程图展示，这个也是很多编排软件常用的做法。由于没有可视化设计，当前的输入输出数据项映射也在手工编写流程模板文件的时候完成数据映射工作。但是可以实现前面多个节点的输出朝后续节点传递的需求。

4. 工作流设计完成后，可以看到仍然需要写大量的代码和实现类才能够完成工作流的运行，因此可以看到该开源软件并不能实现完全的面向业务或开发人员的可配置零编码的效果。

基于以上初步分析可以看到，Netflix Conductor开源微服务编排框架并不满足我们前面描述的微服务编排场景，如果要实现服务和服务之间的编排，实际上对该开源软件的定制和改造工作量相当大。因此在我们实现微服务编排的时候并不建议选择该开源软件。其次，在整个微服务架构体系中，也不建议采用Netflix Conductor，至少在前期的改造过程中使用的场景很小，完全可以用其他方式来替代。