根据我所见，在 Spring Cloud Dataflow (SCDF) 中创建流将部署底层应用程序、绑定通信服务（如 RabbitMQ）、设置 Spring Cloud Stream 环境变量并启动应用程序。这一切都可以使用 cf push 命令轻松手动完成。
是的 - 您可以单独编排流应用程序，这样做有好处。但是，当您尝试使用 和绑定特定属性手动连接每个流应用程序时channelName，destination您将不得不处理更多的簿记。这一切都成为 Spring Cloud Data Flow (SCDF) 编排层的幕后工作。
特别是，当您的流管道涉及“缩放”或“分区”时，您必须注意instanceCount,instanceIndex和相关属性。这些也通过 DSL 语义在 SCDF 中实现自动化。
SCDF 服务器是 PCF 上的内存占用者（我有一个只有 6 个应用程序的流，但我需要大约 10GB 的服务器空间）
根据我们的实验，当您处于“开发”状态并在一天内多次重复创建 > 部署 > 销毁流时，通常会观察到这种情况。一般来说，服务器应该只需要1G。
人们普遍认为 PCF 中的 JVM 会报告它并没有真正使用的内存。这与 java 的rt.jar. PCF 中围绕“内存使用报告”功能进行了一些新的内核更改，因此在 JVM 启动后（它使用了大量资源），它不会继续报告错误数据。我们正在密切跟踪这一点。
也就是说，我们还在分析服务器以确保没有任何内存泄漏。照原样，服务器没有任何内存状态 - 服务器需要的最小元数据状态（例如：流定义）被持久化在 RDBMS 中。请密切关注#107的进展。
应用程序命名、内存、实例等方面没有灵活性。（您通常会在 manifest.yml 中设置的所有内容）
目前尚不清楚“应用程序命名”是什么意思。如果这必须处理服务器名称，您可以通过您的manifest.yml或其他方式轻松更改它。如果它与流应用名称有关，它们会以“流名称”作为前缀自动部署，因此当您从 CF CLI 或 Apps-Mgr 查看应用时很容易识别。
至于内存和磁盘的使用，您可以通过SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_STREAM_MEMORY和SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_STREAM_DISK令牌在每个应用程序级别进行控制。更多细节在这里。
与构建工具（如 Bamboo）的集成将需要额外的工作，因为我们必须使用 SCDF CLI 而不仅仅是 PCF CLI
您将在流/任务应用程序上运行 CI 构建，因为它们是您的开发工作流程的一部分。SCDF 只是提供编排机制来管理这些应用程序。我们还致力于与Netflix 的 Spinnaker工具进行本地集成，以便在不久的将来提供开箱即用的体验。
无法修改现有流。要进行蓝绿部署，您必须手动部署应用程序（绑定服务并手动设置环境变量）。然后，一旦完成蓝绿部署，SCDF 将流显示为失败，因为它不知道底层应用程序之一已更改。
您可以在应用程序上单独执行蓝绿色滚动升级。在 SCDF 中也有一个活动的 wip 可以适应不断变化的流/任务应用程序状态。顺便说一句，Spinnaker 集成将进一步简化自定义应用程序位的滚动升级，并且 SCDF 将适应动态变化——就这一要求而言，这是最终目标。
我遇到的各种错误，例如尝试重新部署失败的流时出现 MySQL 主键约束错误
我们很乐意倾听您的反馈; 具体来说，请考虑在backlog中报告这些问题。非常感谢这方面的任何帮助。
那么我错过了什么？为什么使用 Spring Cloud Dataflow 有利于手动部署应用程序？
架构部分涵盖了一般功能。如果你有大量的流或任务应用程序（就像任何其他微服务设置一样），你需要一个中央编排工具来在云环境中管理它们。SCDF 提供 DSL、REST-API、Dashboard、Flo，当然还有开箱即用的安全层。流和任务之间的互操作性是涉及闭环分析的用例的另一个重要要求 - 围绕此有 DSL 工具。当 Spinnaker 集成成为一等公民时，我们预计将通过数据管道实现端到端的持续交付。最后，Cloud Foundry 的 SCDF-tile 将与Spring Cloud Services互操作进一步自动化供应方面以及全面的安全覆盖。
希望这可以帮助。