conductor介绍

https://netflix.github.io/conductor/

https://github.com/Netflix/conductor

编译版： https://jcenter.bintray.com/com/netflix/conductor/

-----------------------------------------------------

Motivation

我们建立了Conductor，以帮助我们在Netflix上编制基于微服务的流程，具有以下特点：

允许创建复杂的流程/业务流程，其中单个任务由微服务器实现。
基于JSON DSL的蓝图(blueprint)定义了执行流程。
为这些流程提供可见性和可追溯性。
围绕暂停，恢复，重新启动等方式展现控制语义，从而实现更好的体验。
允许更多地重用现有的微服务器，为onboarding提供更简单的路径。
用户界面可视化流程。
能够在需要时同步处理所有任务。
能够扩展数以百万计的同时运行的流程。
由客户抽象的排队服务支持。
能够在HTTP或其他传输（如gRPC）上运行。

Why not peer to peer choreography?

通过对等任务编排，我们发现随着业务需求和复杂性的增长难以扩展。 Pub / sub模式为最简单的流程工作，但很快突出了与该方法相关的一些问题：

流程在多个应用程序的代码中被“嵌入”。
通常，关于输入/输出，SLA等的紧耦合和假设，使其难以适应不断变化的需求。
几乎没有办法系统地回答“我们对过程X做了多少工作”？

API和存储层可插拔，并提供与不同后台和队列服务提供者合作的能力。

-----------------------------------------------------------------------------------------------

git clone git@github.com:Netflix/conductor.git

启动server

方法1：进入server目录
执行../gradlew server
此命令会自动下载gradle
此脚本最终执行的是如下命令

(java -Dorg.gradle.appname=gradlew -classpath /root/conductor/gradle/wrapper/gradle-wrapper.jar org.gradle.wrapper.GradleWrapperMain server)

方法2：手动下载gradle工具，进入server目录

gradle build

进入/root/conductor/server/build/libs 目录下

java -jar conductor-server-VERSION-all.jar

实现此接口

https://github.com/Netflix/conductor/blob/dev/client/src/main/java/com/netflix/conductor/client/worker/Worker.java

例子：

https://github.com/Netflix/conductor/blob/dev/client/src/main/java/com/netflix/conductor/client/task/WorkflowTaskCoordinator.java

https://github.com/Netflix/conductor/blob/dev/client/src/test/java/com/netflix/conductor/client/sample/SampleWorker.java

启动ui：

cd ui

gulp watch

访问 http://localhost:3000/运行模式：
conductor遵循基于RPC的通信模式，其中worker与server在单独的机器上运行。 worker通过基于HTTP的端点与服务器通信，并使用轮询模型来管理工作队列。

worker是远程系统，并通过HTTP（或任何支持的RPC机制）与conductor server进行通信。
     任务队列用于为worker安排任务。我们在内部使用了dyno-queue，但是它可以很容易地与SQS或类似的pub-sub机制进行交换。
     conductor重新持久化模块使用Dynomite存储状态和元数据以及Elasticsearch用于索引后端。
     请参阅扩展后端部分，以实现对不同数据库的支持以进行存储和索引。

要注册并执行新工作流所需的步骤：

1. 定义工作流的任务定义。
2. 创建工作流定义
3. 创建定期轮询调度任务的任务worker.

触发工作流执行

POST /workflow/{name}

{

    ... //json payload as workflow input

}

轮询任务

GET /tasks/poll/batch/{taskType}

更新任务状态

POST /tasks

{

    "outputData": {

        "encodeResult":"success",

        "location": "http://cdn.example.com/file/location.png"

        //any task specific output

     },

     "status": "COMPLETED"

}

工作流定义：

工作流使用以DSL为基础的JSON定义的，包括一组要执行的任务,这些任务组成了工作流，任务是远程机器上的控制任务(fork, conditional等等)，

或应用程序任务（e.g. encode a file）

任务定义：

所有的任务必须在活动的工作流使用之前注册.

一个任务可以被多个工作流重复使用，任务分成两类：

System Task
Worker Task

System Tasks：

系统任务在Conductor服务器的JVM内执行，由Conductor管理，用于其执行和可扩展性。

DYNAMIC ：基于对任务的输入表达式导出的工作任务，而不是静态定义为blueprint的一部分

DECIDE：决策任务 - 实现案例...开关式fork

FORK：fork一组并行的任务。每组计划并行执行

FORK_JOIN_DYNAMIC：FORK_JOIN_DYNAMIC与FORK类似，但不是并行执行blueprint中定义的任务集，基于此任务的输入表达式生成并行任务

JOIN：完成FORK和FORK_JOIN_DYNAMIC。用于合并更多的并行分支*

SUB_WORKFLOW：将另一个工作流作为子工作流任务。执行后，实例化子工作流程，等待完成

EVENT：在支持的事件系统（例如conductor，SQS）中产生事件

conductor提供了一个API来创建在与引擎相同的JVM中执行的用户定义的任务。有关详细信息，请参阅WorkflowSystemTask界面。

Worker Tasks

worker tasks由应用程序实现，并在独立于Conductor的环境中运行。 worker tasks可以用任何语言实现。这些任务通过REST API端点与Conductor服务器进行通信，以轮询任务并在执行后更新其状态。

worker tasks由blueprint中的任务类型SIMPLE标识。

Lifecycle of a Workflow Task