我开始使用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 B之前启动app A）。整个系统只有在两个应用程序都启动时才能工作，但他们甚至不需要彼此了解。唯一需要的是他们使用相同的代理和主题，一个用于发送消息，另一个用于获取消息。那么为什么你绝对需要在Spring Cloud Dataflow中将一个应用程序的输出链接到另一个应用程序的输入？这是一种强制两个应用程序使用相同主题的方法，但是全部是？
答案 0 :(得分：3)
Spring Dataflow旨在编写适用的工作流程
Spring Cloud Data Flow（SCDF）是一种编排服务，允许您将微服务应用程序组合成一个连贯的管道。接受的应用程序（ today ）基于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个应用程序（源和接收器）。但是，您可以使用SCSt构建aggregate application并将聚合（源，处理器（ s ）和接收器）编排为单个单元。
答案 1 :(得分：0)
值得一提的是，新的SCDF执行模型和整体架构限制了我们大多数人所属的一些用例（至少我们运营的TELCO环境）。换句话说，在容器引擎顶部运行的SCDF即将到来 - 某处。我们在生产中使用SpringXD，它就像Zookeeper（分布式）的魅力一样。现在，有了SCDF概念，我必须考虑其他事情，尽管我已经设法在Kubernetes集群上安装并运行SCDF（在我的实验室中）。