从Spring XD到Data Flow
最初我们设计Spring XD作为一个可以轻松构建针对于实时和批量任务的复杂的，分布式的数据管道。1.x的架构它是一个强有力的工具对于一些应用，包括传统企业级ETL，连接数据集合，以及实时任务分析。在于1.x的经验，Spring Boot, 和 Pivotal Cloud Foundry 展现了新的方法来开启Cloud Native途径。
新的需求：对于创建和维护一个数据工作流的集成管道是很复杂的。存在不间断的扩展功能，canary部署，动态资源分配，分布式追踪等市场需求。当前的体系架构不允许我们去简单的构建这些。
更广泛的范围：大数据问题依然是集成问题：数据必须被摄入，过滤，分析，传递，存储并且以无数种方式可以处理。然而我们已经支持一些大数据用例，并不是每一个集成和处理用例都需要Apache Hadoop 或者是 Apache Spark用来存储和处理数据。无论多大规模或什么应用，都是有集成的需求针对于每一个类型或大小的企业级应用。
焦点：操作和非功能性能力被提倡通过像Pivotal Cloud Foundry这样的平台。而不是投资在冗余特性,积累技术债务,我们想调整和聚焦在客户价值方面而不是无差别的担起一个运行平台的重任。
部署和操作：设置一个Spring XD 运行环境分布式集群需要额外的例如 Zookeeper, 一个消息传递工具，数据库。考虑到这些活动的组件，管控集群是尤其的困难，需求的变化取决于规模和期盼的吞吐量。我们想要依赖具有弹性扩展能力的平台来减缓运营的需求。
Spirng Cloud Data Flow 是 Spring XD 的重新设想来作为消息驱动的微服务：Spring Boot data microservices, 通过Spring Cloud Services 包括Eureka 并且部署在Pivotal Cloud Foundry的合作。Spring XD runtime 没有了，代替它的是service provider interface (SPI) 利用本地平台的能力，包括Pivotal Cloud Foundry, Lattice, or Yarn.这个重构过程是根本的简化架构并且统一传统 RESTful 微服务到新的消息驱动微服务。
Spring XD 与 Spring Cloud Data Flow
Spring XD 的基于Zookeeper的运行时环境已经不复存在了，代替它的是服务提供接口（SPI）。SPI代表了其它的系统例如 Pivotal Cloud Foundry, Lattice, and Yarn 用于启动，扩展，监控微服务应用。例如SPI Lattice 使用 receptor API启动模块。在 Cloud Foundry cloud controller API 被使用。也存在一个本地的实现来运行，类似旧 XD 当中的单节点（Single node）。
“基本的想法是我们保留一些更高层级的APIs”, Pollak 在会议说”但是在底层我们大量地重构了它来克服一些我们已经发现的局限性。”
这些局限性包括扩展能力，canary 部署，资源分配例如不同的模块被给予不同的内存分配，分布式的追踪，等等。当前的体系架构不支持。其它的的一些局限性涉及到使用传统的层级父子类加载器相反的对于一个平级的类加载器可能用在独立的微服务应用体系架构上。
为了解决类加载器的问题已经存在的集成和批量模块已经被重构为独立扁平类加载器的Spring Boot 应用。实际上重新设计允许实时任务（stream）和批量任务(batch applications)以数据微服务的形式运行并且可以独立发展。模块可以在没有任何相关Spring Cloud Data Flow的东西来运行，java -jar 将会做这个工作，但是Data Flow 带走了许多的繁琐的配置properties等的工作。在其它的事情中它应该比起模块运行在基于Zookeeper 的XD 容器中更加简单的针对单独模块去写单元测试，这可能将开启一个市场让更多的社区去贡献开发。
以下的Boot模块是两个新的项目，Spring Cloud Stream 和 Spring Cloud Task，已经被创建提供分别对 Spring Integration 和 Spring Batch的自动配置能力。
Spring XD 迁移到 Spring Cloud Data Flow
