陆小曼|从ESB服务组合编排到NetflixConductor微服务编排( 四 ) 作者：人月神话

基于蓝图。基于JSON DSL的蓝图定义执行流程。

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

基于上面介绍可以看到Netflix Conductor最重要的还是实现了基本的工作流定义，任务定义，任务的连接，整个工作流的任务调度和监控等基本能力。
官方参考文档：
实例参考文档：
对于具体的功能说明和介绍参考上面两篇文章即可，在此不再重复进行描述，只对看完了整个Netflix Conductor功能实现后做一下简单总结。

在Netflix Conductor中任务节点的定义虽然可以定义详细的输入和输出，但是任务节点并不是服务引用节点，任务节点具体需要开发实现类来进行实现。那么我们场景里面说的任务节点即服务节点，任务的输入或输出就是服务的输入或输出是无法实现的，如果要实现也需要进行大量的定制开发才能够支持。
微服务编排完成后可以形成一个新的Http Rest服务接口，这个是我们需要的。同时对于编排完成的workflow本身是可以实现灵活的任务监控和任务调度，满足基本的流程引擎该有的功能。

没有看到可以进行可视化服务编排设计的地方，但是对于编排完成的模型文件可以展现为可视化的流程图展示，这个也是很多编排软件常用的做法。由于没有可视化设计，当前的输入输出数据项映射也在手工编写流程模板文件的时候完成数据映射工作。但是可以实现前面多个节点的输出朝后续节点传递的需求。
工作流设计完成后，可以看到仍然需要写大量的代码和实现类才能够完成工作流的运行，因此可以看到该开源软件并不能实现完全的面向业务或开发人员的可配置零编码的效果。
基于以上初步分析可以看到， Netflix Conductor开源微服务编排框架并不满足我们前面描述的微服务编排场景，如果要实现服务和服务之间的编排，实际上对该开源软件的定制和改造工作量相当大。因此在我们实现微服务编排的时候并不建议选择该开源软件。其次，在整个微服务架构体系中，也不建议采用Netflix Conductor ，至少在前期的改造过程中使用的场景很小，完全可以用其他方式来替代。
欢迎关注@人月聊IT 分享SOA ，微服务， DevOps平台规划和建设。