Spring Dataflow 概念说明答案

【问题标题】：Spring Dataflow concepts clarificationSpring Dataflow 概念说明
【发布时间】：2017-04-21 04:45:54
【问题描述】：

我开始使用 Spring Dataflow，发现自己遇到了一些我无法回答的问题，阅读了文档并进行了一些测试。欢迎任何澄清（如果您不能一次回答所有问题，请回答您可以回答的问题，如果需要，我会合并完整的答案）

Spring Dataflow 旨在编写应用工作流，例如：app A 的输出是app B 的输入，等等。工作流不需要是线性的，因为app A 的输出可能是app B 和app C 的输入。 准确吗？
流程管道中的应用程序以“消息驱动”方式进行通信，这一点写得很好。 App A 向代理（例如 RabbitMQ 或 Kafka）发送消息，app B 从中消费消息。我们的流程中可以有多个不同的代理。但是消息传递是在应用程序之间发送信息的唯一方式吗？ 例如，app A 是否有可能通过 HTTP REST 请求调用 app B？如果是，怎么做？
由于应用程序依赖于异步消息传递（见上述问题），Dataflow 的附加值是什么？我的意思是，如果您将app A 配置为向foo 主题发送消息，并将app B 配置为使用来自同一主题的消息，您可以分别部署两者（没有Dataflow），它会起作用。据我了解，Dataflow 只提供了一种一次性部署和取消部署它们的方法，而不是一个接一个。 正确吗？
与上一个问题一样，异步消息传递将您从定义流顺序中抽象出来（即您可以在 app A 之前开始 app B）。整个系统只有在两个应用程序都启动时才能工作，但它们甚至不需要相互了解。唯一需要的是他们使用相同的代理和主题，一个发送消息，另一个获取消息。那么为什么在 Spring Cloud Dataflow 中绝对需要将一个应用程序的输出链接到另一个应用程序的输入？这是一种强制两个应用程序使用相同主题的方法，但仅此而已？

【问题讨论】：

【解决方案1】：

Spring Dataflow 旨在编写应用工作流

Spring Cloud Data Flow (SCDF) 是一种编排服务，可让您将微服务应用程序组合成一个连贯的管道。接受的应用程序（今天）基于 Spring Cloud Stream (SCSt) 或 Spring Cloud Task (SCT) 编程模型，因此您可以分别编排流和任务/批处理管道。根据要求，您可以操作线性或复杂的 DAG 类型的工作流。

但是消息传递是在应用程序之间发送信息的唯一方式吗？

现在，是的。 SCSt 提供的当前绑定器抽象支持消息传递通道，我们正在推广绑定模型。下一代正在演变为添加对作为输入/输出的 KStream 以及作为输入/输出的 Reactor 的 Flux 的支持。我们还不支持 RESTful 绑定机制。

由于应用程序依赖于异步消息传递（参见上述问题），Dataflow 的附加值是什么？

您可以编排各个 SCSt/SCT 应用。独立应用程序包括诸如“绑定器连接信息”、“通道绑定目标”等属性 - 您需要提供它们。一旦您有了分区和扩展等要求，您就必须保留更多这些应用程序属性。这就是 SCDF 的编排层增加价值的地方。除了可用于更快创建流/批处理管道的 DSL、REST-API、Dashboard/Flo 之外，SCDF 还可以自动创建那些已知属性，以使用明确定义的命名约定连接应用程序。

Dataflow 仅提供一种一次性部署和取消部署它们的方法，而不是一个一个地部署。对吗？

如果您使用一组应用部署流，SCDF 会按顺序部署它们。您可以取消部署、销毁和查询由应用程序组成的流的聚合状态。而且，对于Tasks，您可以启动、销毁和查询执行状态等。

为什么在 Spring Cloud Dataflow 中绝对需要将一个应用程序的输出链接到另一个应用程序的输入？

这还不清楚。对于流处理，您需要在 SCDF 的上下文中至少有 2 个应用程序（source 和 sink）。但是，您也可以使用 SCSt 构建 aggregate application 并将聚合（源、处理器（s）和接收器）编排为一个单元。

【讨论】：

感谢您提供的出色答案，Sabby，这绝对有帮助。虽然，我仍然不清楚某些点：在事件驱动的架构中，为什么需要按特定顺序部署应用程序？如果我的应用程序注册了一个接收器绑定（通过@EnableBinding 和@ServiceActivator 机制），为什么我不能在SCDF 中单独部署它（这实际上是你说的最后一点不够清楚）？据我了解，它会定期轮询消息服务，而不需要 SCDF。那么为什么我需要添加一个水龙头作为源才能保存流呢？
我们按顺序部署应用程序（即：首先是消费者，然后是生产者）只是为了确保消费者准备好并且可以尽快处理消息生产者上来。在消息传递架构中不必采用这种方式，但它实际上只是为了更清晰的处理和方便。

【解决方案2】：

值得一提的是，新的 SCDF 执行模型和整体架构限制了我们大多数人所属的一些用例（至少是我们操作的电信环境）。换句话说，在容器引擎之上运行的 SCDF 是不久的将来——某个地方。我们在生产中使用 SpringXD，它与 Zookeeper（分布式）一起工作就像一个魅力。现在，对于 SCDF 概念，我必须考虑其他一些事情，尽管我已经设法在 Kubernetes 集群上（在我的实验室中）安装和运行了 SCDF。

【讨论】：