cloud-foundry - Spring Cloud Dataflow 有什么好处？

Question

根据我所见，在 Spring Cloud Dataflow (SCDF) 中创建流将部署底层应用程序、绑定(bind)通信服务(如 RabbitMQ)、设置 Spring Cloud Stream 环境变量并启动应用程序。这一切都可以使用 cf push 命令轻松手动完成。

同时，我遇到了 Spring Cloud Dataflow 的一些缺点:

SCDF 服务器是 PCF 上的内存占用者(我有一个只有 6 个应用程序的流，但我需要大约 10GB 的服务器)

在应用程序命名、内存、实例等方面没有灵 active 。(您通常会在 manifest.yml 中设置的所有内容)

与构建工具(如 Bamboo)的集成将需要额外的工作，因为我们必须使用 SCDF CLI 而不仅仅是 PCF CLI

无法修改现有流。要进行蓝绿部署，您必须手动部署应用程序(绑定(bind)服务并手动设置环境变量)。然后，一旦完成蓝绿部署，SCDF 将流显示为失败，因为它不知道底层应用程序之一已更改。

我遇到的各种错误，例如尝试重新部署失败的流时出现 MySQL 主键约束错误

那么我错过了什么？为什么使用 Spring Cloud Dataflow 有利于手动部署应用程序？

Answer 1

Based on what I've seen, creating a stream in Spring Cloud Dataflow (SCDF) will deploy the underlying applications, bind the communication service (like RabbitMQ), set the Spring Cloud Stream environment variables, and start the applications. This could all be done manually easily using a cf push command.

是的 - 您可以单独编排流应用程序，这样做有好处。但是，当您尝试使用 channelName 手动连接每个流应用程序时, destination以及绑定(bind)特定属性，您必须处理更多簿记。这一切都成为 Spring Cloud Data Flow (SCDF) 编排层的幕后工作。

特别是，当您的流管道涉及“缩放”或“分区”时，您必须注意 instanceCount , instanceIndex以及相关的属性。这些也通过 DSL 语义在 SCDF 中实现自动化。

SCDF Server is a memory hog on PCF (I have a stream with only 6 applications, and yet I'm needing about 10GB for the server)

根据我们的实验，当您处于“开发”状态并在一天内多次重复创建 > 部署 > 销毁流时，通常会观察到这种情况。一般来说，服务器应该只需要1G。

人们普遍认为 PCF 中的 JVM 会报告它并没有真正使用的内存。这与java的 rt.jar有关. PCF 中围绕“内存使用报告”功能进行了一些新的内核更改，因此在 JVM 启动后(它使用了大量资源)它不会继续报告错误数据。我们正在密切跟踪这一点。

也就是说，我们还在分析服务器以确保没有任何内存泄漏。照原样，服务器没有任何内存状态 - 服务器需要的最小元数据状态(例如:流定义)被持久化在 RDBMS 中。请关注 #107为事态发展。

No flexibility on application naming, memory, instances, etc. (All the things that you would typically set in the manifest.yml)

目前尚不清楚“应用程序命名”是什么意思。如果这必须处理服务器名称，您可以通过 manifest.yml 轻松更改它。或通过其他方式。如果它与流应用名称有关，它们会以“流名称”作为前缀自动部署，因此当您从 CF CLI 或 Apps-Mgr 查看应用时很容易识别。

至于内存和磁盘的使用，您可以通过 SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_STREAM_MEMORY在每个应用程序级别进行控制。和 SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_STREAM_DISK token 。更多详情 here .

Integration with build tools (like Bamboo) are going to require extra work because we have to use the SCDF CLI rather than just the PCF CLI

您将在流/任务应用程序上运行 CI 构建，因为它们是您的开发工作流程的一部分。 SCDF 只是提供编排机制来管理这些应用程序。我们还致力于与 Netflix's Spinnaker 的本地集成。工具可在不久的将来提供开箱即用的体验。

Existing streams cannot be modified. To do a blue-green deployment, you have to deploy the application manually (binding the services and setting the environment variables manually). And then once a blue-green deployment is done, SCDF shows the stream as Failed, because it doesn't know that one of the underlying applications has changed.

你可以像 rolling upgrades 一样执行蓝绿分别在应用程序上。在 SCDF 中也有一个事件的 w-i-p 来适应不断变化的流/任务应用程序状态。顺便说一句，Spinnaker 集成将进一步简化自定义应用程序位的滚动升级，并且 SCDF 将适应动态变化——就这一要求而言，这是最终目标。

Various errors I've run into, like MySQL Primary Key Constraint errors when trying to redeploy a failed stream

我们很乐意倾听您的反馈;具体来说，请考虑在 backlog 中报告这些问题。 .非常感谢这方面的任何帮助。

So what am I missing? Why would using Spring Cloud Dataflow be beneficial to just manually deploying the applications?

architecture section涵盖一般能力。如果您要拥有大量流或任务应用程序(就像任何其他微服务设置一样)，您需要一个中央编排工具来在云设置中管理它们。 SCDF 提供 DSL、REST-API、Dashboard、Flo，当然还有开箱即用的安全层。流和任务之间的互操作性是涉及闭环分析的用例的另一个重要要求 - 围绕此有 DSL 工具。当 Spinnaker 集成成为一等公民时，我们预计将通过数据管道实现端到端的持续交付。最后，Cloud Foundry 的 SCDF-tile 将与 Spring Cloud Services 互操作。进一步自动化供应方面以及全面的安全覆盖。

希望这可以帮助。