Spring Cloud Dataflow 有哪些优势？
What are the Benefits of Spring Cloud Dataflow?
根据我所见，在 Spring 云数据流 (SCDF) 中创建流将部署底层应用程序，绑定通信服务（如 RabbitMQ），设置 Spring 云流环境变量，并启动应用程序。这一切都可以使用 cf push 命令轻松地手动完成。
与此同时，我 运行 发现了 Spring Cloud Dataflow 的一些缺点：
- SCDF 服务器是 PCF 上的内存大户（我有一个只有 6 个应用程序的流，但我需要大约 10GB 的服务器空间）
- 应用程序命名、内存、实例等没有灵活性（您通常会在 manifest.yml 中设置的所有内容）
- 与构建工具（如 Bamboo）的集成将需要额外的工作，因为我们必须使用 SCDF CLI 而不仅仅是 PCF CLI
- 无法修改现有流。要进行蓝绿部署，您必须手动部署应用程序（绑定服务并手动设置环境变量）。然后一旦蓝绿部署完成，SCDF 将流显示为失败，因为它不知道其中一个底层应用程序已更改。
- 我 运行 遇到的各种错误，例如 MySQL 尝试重新部署失败的流时出现主键约束错误
那我错过了什么？为什么使用 Spring Cloud Dataflow 比仅手动部署应用程序更有益？
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 和绑定特定属性手动连接每个流应用程序时，您将不得不处理更多的簿记工作。这一切都成为 Spring 云数据流 (SCDF) 编排层中的幕后琐事。
特别是，当您的流媒体管道中涉及 "scaling" 或 "partitions" 时，您必须注意 instanceCount、instanceIndex 和相关的特性。这些在 SCDF 中也通过 DSL 语义实现了自动化。
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)
根据我们的实验，当您处于 "development" 并在一天内多次重复创建 > 部署 > 销毁流时，通常会观察到这种情况。一般来说，服务器应该只需要1G。
普遍认为 PCF 中的 JVM 报告它并没有真正使用内存；这与 java 的 rt.jar 有关。 PCF 中围绕 'memory usage reporting' 功能进行了一些新的内核更改，因此在 JVM 启动后（ 使用了大量资源 ）它不会继续报告错误数据。我们正在密切跟踪此事。
也就是说，我们还在分析服务器以确保没有任何内存泄漏。按原样，服务器没有任何内存状态 - 服务器所需的最小元数据状态（例如：流定义）持久保存在 RDBMS 中。请密切关注 #107 的动态。
No flexibility on application naming, memory, instances, etc. (All the things that you would typically set in the manifest.yml)
不清楚您所说的 "application naming" 是什么意思。如果这必须处理服务器名称，您可以通过 manifest.yml 或其他方式轻松更改它。如果它与 stream-app 名称有关，它们会自动以 "stream name" 作为前缀进行部署，因此当您从 CF CLI 或 Apps-Mgr 查看应用程序时很容易识别。
至于内存和磁盘使用，您可以通过 SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_STREAM_MEMORY 和 SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_STREAM_DISK 令牌在每个应用程序级别进行控制。更多详细信息 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 构建在 stream/task 应用程序之上，因为它们是您开发工作流程的一部分。 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 来适应不断变化的 stream/task 应用程序状态。顺便说一句，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 covers the general capabilities. If you're to have numerous stream or task applications (like any other microservice setup), you'd need a central orchestration tooling to manage them in the cloud setting. SCDF provides DSL, REST-API, Dashboard, Flo and of course the security layer that comes out-of-the-box. Interoperability between streams and tasks is another important requirement for use-cases involving closed-loop analytics - there's DSL tooling around this. When Spinnaker integration becomes the first-class citizen, we foresee having an end-to-end continuous delivery over data pipelines. Lastly, the SCDF-tile for Cloud Foundry would interoperate with Spring Cloud Services 进一步自动化供应方面以及全面的安全覆盖。
希望对您有所帮助。
根据我所见，在 Spring 云数据流 (SCDF) 中创建流将部署底层应用程序，绑定通信服务（如 RabbitMQ），设置 Spring 云流环境变量，并启动应用程序。这一切都可以使用 cf push 命令轻松地手动完成。
与此同时，我 运行 发现了 Spring Cloud Dataflow 的一些缺点：
- SCDF 服务器是 PCF 上的内存大户（我有一个只有 6 个应用程序的流，但我需要大约 10GB 的服务器空间）
- 应用程序命名、内存、实例等没有灵活性（您通常会在 manifest.yml 中设置的所有内容）
- 与构建工具（如 Bamboo）的集成将需要额外的工作，因为我们必须使用 SCDF CLI 而不仅仅是 PCF CLI
- 无法修改现有流。要进行蓝绿部署，您必须手动部署应用程序（绑定服务并手动设置环境变量）。然后一旦蓝绿部署完成，SCDF 将流显示为失败，因为它不知道其中一个底层应用程序已更改。
- 我 运行 遇到的各种错误，例如 MySQL 尝试重新部署失败的流时出现主键约束错误
那我错过了什么？为什么使用 Spring Cloud Dataflow 比仅手动部署应用程序更有益？
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 和绑定特定属性手动连接每个流应用程序时，您将不得不处理更多的簿记工作。这一切都成为 Spring 云数据流 (SCDF) 编排层中的幕后琐事。
特别是，当您的流媒体管道中涉及 "scaling" 或 "partitions" 时，您必须注意 instanceCount、instanceIndex 和相关的特性。这些在 SCDF 中也通过 DSL 语义实现了自动化。
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)
根据我们的实验，当您处于 "development" 并在一天内多次重复创建 > 部署 > 销毁流时，通常会观察到这种情况。一般来说，服务器应该只需要1G。
普遍认为 PCF 中的 JVM 报告它并没有真正使用内存；这与 java 的 rt.jar 有关。 PCF 中围绕 'memory usage reporting' 功能进行了一些新的内核更改，因此在 JVM 启动后（ 使用了大量资源 ）它不会继续报告错误数据。我们正在密切跟踪此事。
也就是说，我们还在分析服务器以确保没有任何内存泄漏。按原样，服务器没有任何内存状态 - 服务器所需的最小元数据状态（例如：流定义）持久保存在 RDBMS 中。请密切关注 #107 的动态。
No flexibility on application naming, memory, instances, etc. (All the things that you would typically set in the manifest.yml)
不清楚您所说的 "application naming" 是什么意思。如果这必须处理服务器名称，您可以通过 manifest.yml 或其他方式轻松更改它。如果它与 stream-app 名称有关，它们会自动以 "stream name" 作为前缀进行部署，因此当您从 CF CLI 或 Apps-Mgr 查看应用程序时很容易识别。
至于内存和磁盘使用，您可以通过 SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_STREAM_MEMORY 和 SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_STREAM_DISK 令牌在每个应用程序级别进行控制。更多详细信息 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 构建在 stream/task 应用程序之上，因为它们是您开发工作流程的一部分。 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 来适应不断变化的 stream/task 应用程序状态。顺便说一句，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 covers the general capabilities. If you're to have numerous stream or task applications (like any other microservice setup), you'd need a central orchestration tooling to manage them in the cloud setting. SCDF provides DSL, REST-API, Dashboard, Flo and of course the security layer that comes out-of-the-box. Interoperability between streams and tasks is another important requirement for use-cases involving closed-loop analytics - there's DSL tooling around this. When Spinnaker integration becomes the first-class citizen, we foresee having an end-to-end continuous delivery over data pipelines. Lastly, the SCDF-tile for Cloud Foundry would interoperate with Spring Cloud Services 进一步自动化供应方面以及全面的安全覆盖。
希望对您有所帮助。