对话 Eric Bottard：Spring Cloud Data Flow 的 Cloud Foundry 特别版

Pivotal发布了Spring Cloud Data Flow 的Cloud Foundry 特别版，用于在Cloud Foundry 平台上为微服务提供编排服务。

Spring Cloud Data Flow 是对 Spring XD 进行重构的产物，而它的 Cloud Foundry 特别版为企业在 Cloud Foundry 上运行以微服务为中心的架构提供了一系列实用的模式和最佳实践，不过它并不是一个开箱即用的 ETL 或数据集成方案。Spring Cloud Data Flow 将开发人员从分布式架构的复杂性中解脱出来，提供了一站式的系统集成方案，为项目复用奠定了坚实的基础。

InfoQ 采访了在 Pivotal 负责该项目的高级工程师Eric Bottard。

InfoQ：你能简要地介绍一下 Spring Cloud Data Flow 的 Cloud Foundry 特别版吗？它在 Spring 的生态系统里依赖了哪些项目？这个项目有其他短一点的名字吗？

Eric Bottard ： Spring Cloud Data Flow 的 Cloud Foundry 特别版前身是运行在 Cloud Foundry 上的旧版 Spring Cloud Data Flow。它是整个生态系统的一部分（还有其他运行时，由“部署器”提供支持），可以被看成是 Spring Boot 应用之上的一个编排层。更准确地说，它支持“流”（由多个基于数据驱动的应用组成，应用间挨个发生交互，从头到尾形成一个数据流）和任务（基于固定数量数据运行的应用，且只运行一次）的协调部署和监控。

它为使用 Spring Cloud Stream 或 Spring Cloud Task 的 Spring 开发者提供了额外的选择。Spring Cloud Data Flow 本身也是一个 Spring Boot 应用，并依赖了其他 Spring Cloud软件包。

它的名字太长了，所以我们给它取了个别称叫 SCDF，Cloud Foundry 版本的叫作“SCDF for CF”。

InfoQ： Spring XD 对这个项目的设计是否产生了重大影响？Spring Cloud Data Flow 解决了哪些在 Spring XD 中存在的问题？该如何看待这个项目与 Apache Spark、Flink、Kafka 之间的不同？

Bottard：我们最初将 Spring XD 设计成一个独立的分布式数据管道产品，它为应用部署提供了一个弹性的运行时，我们为此投入了一定的精力。不过市场对不间断扩展、canary 部署和分布式追踪的需求更为强烈，而 Cloud Foundry 可以更好地处理这些问题。Spring Cloud Data Flow 把焦点放在如何为用户创造价值上，并降低数据驱动应用的开发准入门槛。

至于说到如何将它与其他产品进行比较，我们可以先来看看 Spring 的观点：当一部分技术占领了相同的市场份额（比如 Apache Flink），它们需要专有的运行时环境，这为构建以数据为中心的应用带来了不必要的负担。我们可以把一些产品作为我们的组件（Apache Kafka 是一个很好的粘合剂，Spring Cloud Steam 将消息中间件称为粘合剂），有时候可以考虑把它们集成起来，或者从已有的架构进行迁移，比如 Apache Spark。

InfoQ：Cloud Foundry 是一个微服务平台，而 Spring Cloud Data Flow 的 Cloud Foundry 特别版是为数据微服务而设计的。你能介绍一下一般性微服务和数据微服务在 Spring 平台上有什么区别吗？

Bottard：当说到微服务，开发人员会想到 RESTful 服务、简单的外部配置和动态服务发现，Spring Boot 和 Spring Cloud 就提供了这些功能。不过企业应用要求的远不止这些，他们还要为开发消息驱动和任务驱动的应用找到一些方法，避免与那些古板老旧的集成产品打交道。这也就是 Spring Cloud Stream 和 Spring Cloud Task 项目存在的意义。Spring Cloud Data Flow 用于编排由 Spring Cloud Stream 和 Spring Cloud Task 应用组成的数据管道。

InfoQ：Spring Cloud Data Flow 的 Cloud Foundry 特别版可以被用于批处理应用和基于流的应用，对吗？你可以介绍一下实现和优化方面的细节吗？

Bottard：实际上是这样的，你不需要编写任何所谓的“Spring Cloud Data Flow”应用。在用它来编排 Spring Cloud Steam 和 Spring Cloud Task 应用时，你不需要编写任何代码。这是 Spring Cloud Data Flow 的一个主要设计原则：帮助开发人员方便地集成微服务应用，同时将应用的运行时也抽离出去。Cloud Foundry 是唯一可用的运行时。

如果你需要用到流和边界内数据，那么事情就会变得很有趣。你可能需要使用面向任务的事件（比如在批处理结束后发出的通知）来驱动处理过程，Spring Cloud Data Flow 为此提供了支持。

至于实现细节，基于流的应用和基于任务的应用分别与 LRP 和 Cloud Foundry 的任务概念相呼应的。LRP 是长运行进程（Long Running Process）的缩写，平台负责管理这些进程，确保它们一直处于运行状态，在必要的时候需要对其进行扩展。另外需要注意的是，任务总是有开始和结束的。

InfoQ：从开发者的角度来看，Spring Cloud Data Flow 可以被用于多种用途，比如 DSL、仪表盘，等等。你可以对此发表你的看法吗？请告诉我们一般怎样上手？

Bottard：是的。Spring Cloud Data Flow 的模型结构可以满足你的特定需求（基于流和任务），你可以决定是否需要将这些结构部署在你的运行时（比如 Cloud Foundry）上，以及如何部署。这些模型结构是通过 RESTful API 暴露出来的，至于使用何种方式与之进行交互，比如使用仪表盘、shell 或直接调用 API，这个并不重要。

内建的 shell 是一个典型的开发工具，数据工程师可以配置自己的 profile。它使用了一种 unix 风格的 DSL，应用间的交互式通过管道来进行的，比如“http --server.port=1234 | hdfs”。

对于数据科学家和数据仓库工程师来说，他们更喜欢使用仪表盘，仪表盘提供了一个概览视图。当数据规模不断增长，流与流之间相互嵌套的时候，仪表盘会带来很多方便。

InfoQ：这个特别版是否只适用于 Pivotal 的 Cloud Foundry？它可以被用于其他基于 Cloud Foundry 的平台吗？你能详细说一下这个项目的路线图吗？

Bottard：Spring Cloud Data Flow 与 Cloud Foundry 之间的交互依赖一种部署器，这种部署器是为 Cloud Foundry 开源 API 而设计的，所以 SCDF 是完全可以与其他平台兼容的。在少数情况下，如果某些平台对一些特定的服务支持地不好（比如 RabbitMQ），SCDF 就会受到限制，你不得不选择其他消息中间件。

我们争取每三个月发布一个版本，发布的版本里包含了一些开箱即用的应用和一些核心的改进。例如，在 v1.2 里将带来已经组合好的任务、基于角色的安全机制，如果使用了 Docker，还会带来更好的用户体验。

这里有快速入门的例子和文档。

查看英文原文： Q&A with Eric Bottard Regarding Spring Cloud Data Flow for Cloud Foundry