調研Spring Cloud Data Flow
從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的自動配置能力。
