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

对于定义的服务编排产生的新服务，拖拽到设计器后应该产生输入和输出两个独立节点，这个在我们做单服务的ESB服务设计器的时候思路是一致的。
b. 服务之间的连接，本质是服务输入和输出之间的连接和映射
要明白服务之间的连接本质是输入和输出之间的连接和映射。以三个原子服务全部是查询服务，我们希望组装一个新服务，一次返回A ， B ， C三个服务查询结果，这个场景来举例说明。
我们需要拖拽A ， B ， C三个原子服务节点到设计器里面，然后将新服务的输入连线到A ， B ， C三个原子服务节点。在连接完成后，我们需要将新服务的输入和ABC三个服务的输入之间进行数据映射。
其次我们需要将ABC三个服务的输出连接到新服务的输出。对于新服务的输出，我们同样需要完成数据项之间的映射。但是这里的复杂性体现在ABC三个服务输出的三个结果集之间究竟是并行关系，还是父子层次关系，在进行数据映射和合并返回的时候，我们需要提前进行三个结果集的层次关系定义。这里面场景包括

结果集并行结构返回多个
结果集返回层一个层次结构的结果集返回
对多个结果集类似Sql一样进行查询关联，返回一个结果集作为结果

以上三种则是我们场景的对服务查询结果进行处理，合并或关联的方式。
c. 对服务流程式的串联和顺序处理，重点需要解决跨多节点数据映射问题
这个前面已经讲过，即将A ， B ， C三个服务进行串联方式编排的时候，实际我们看到B结果的输入只能够是A节点的输出，但是服务C的输入却可以同时是A或B的输出。因此在编排完成后进行数据映射的时候，一定需要支持C节点的输入可以同时映射到A或B的输出数据项元素。
d. 对于规则计算节点的两种可能，简单规则节点和复杂规则节点
对于规则节点需要考虑两种可能性，一种是常见的简单规则节点，即进行简单的加减乘除运算得出一个规则，基于规则判断后能够走不同的分支对结果进行处理。另外一种可能即将输入送入到规则引擎进行处理，处理完成后返回一个结果，如果在不连接规则引擎的情况下，我们可以设计一个专门的WS服务节点，即该节点可以去调用外部服务并返回输出结果，并基于输出结果情况进行判断，基于判断走不同的分支。
注意这种规则WS服务节点仅仅是进行规则处理，而非整个服务编排的主体输入和输出。实际我们在进行服务编排设计的时候，最好不要将这类节点放在主体服务编排路径上面。
NetflixConductor微服务编排

对于服务编排的可视化设计，其中最核心的还是服务编排本身任务或活动节点对应的是原子服务，连线对应的是服务输入输出之间的映射，整个编排完成是形成一个新的接口服务能力，这就是服务编排要做的事情。如果无法满足上面的核心，那谈不上服务编排。
今天谈下开源的微服务编排Netflix Conductor ，先说下具体的场景，这个是Netflix内容平台工程团队运行由微服务上执行的任务的异步编排驱动的多个业务流程。其中一些是长期运行的流程，跨越几天。这些流程在准备好标题流式传输给全球的观众上发挥关键作用。
这些流程的几个实例是：

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

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