定量分析的成敗在很大程度上取決於採集，存儲和處理數據的能力。若能及時地向業務決策者提供深刻並可靠的數據解讀，大數據項目就會有更多機會取得成功。
如今，為數據處理設計合適的架構需要下很大工夫。數據處理主要包括 3 個方面：
批處理：批量處理大量的靜態數據。這一方式一般是分佈式並且可擴展的。
實時處理：實時處理主要處理連續且無盡的的數據流。這些數據流也是分佈式的，且速度很快。
混合計算模型：該模型是批處理和實時處理的結合，可以處理大量和高速數據。
大數據項目的工程非常耗時，並且要利用合適的技能來解決數據採集和處理的問題，因為這些問題的解決對大多數方案來說都是必不可少的。Pivotal 曾推出了 Spring XD 和 Spring Cloud Dataflow 來減少大數據工程的開銷。本文將簡要介紹 Spring XD，以及該技術的最新版本，即 Spring Cloud Data Flow 的各方面細節。
Spring XD
Spring XD 是第一輪技術創新的產物。它為一些常見的與數據處理有關的任務提供了一種易用的解決方案。Spring XD 建立在了歷經考驗的 Spring 技術之上，併為數據攝入、移動、處理、深度分析、流處理和批處理提供了支持。
Spring XD 為實時處理以及批處理提供了一個精巧、穩定，且可擴展的框架。用 Spring XD 來採集數據，並將數據從各種數據源移到目標會更加容易。
Spring XD 架構在傳統企業級 ETL（數據抽取、轉換與加載的流程），實時分析和數據科學項目工作臺的創建中得到了廣泛應用。
基於 Spring XD 的架構
下圖描述了基於 Spring XD 的架構。在下圖這些模塊的幫助下，我們可以創建、運行、部署並銷燬數據管道，並對管道中的數據進行各種各樣的處理。
Spring XD 的主要組件是 Admin 和 Container。
Admin UI 用於向服務器發送要執行某個任務的請求，然後服務器會調用關聯的模塊執行所請求的任務。在此，一個模塊是構建 Spring 應用程序上下文的組件之一。
所有模塊都需要一個 XD 容器才能運行並執行該模塊執行的相關任務。
以下是 Spring XD 體系結構中的一些關鍵模塊。
數據源（Source）：一個數據流的創建總會從創建數據源模塊開始。數據源可以使用輪詢機制或事件驅動機制獲得數據，然後只會提供數據的輸出。
數據處理器（Processor）：它會接收輸入消息，並在經過某些類型的處理後產生輸出消息。
-
數據接收器（Sink）：顧名思義，該模塊是一個數據流的終點。它會將輸出的數據發送到一個外部的資源，例如 HDFS。
作業（Job）：該模塊會執行一些批處理作業。
對 Spring Cloud Data Flow 的需求
應用方面的需求總是在變化。這逐漸揭示了 Spring XD 的缺陷和對新一輪的技術創新的需求。以下是一些對新型框架最重要的需求：
雲技術在運營需求和非功能性需求的平臺級實現方面發揮了巨大作用，但在應用級別上落實 非功能性要求仍是一個對工程量的挑戰。
在分佈式環境中對特定階段部署，動態資源分配，擴展能力和跟蹤能力的需求也在日益增長。
現在越來越多的平臺意識到了將平臺遷移到雲服務供應商上，以及一個平臺的可遷移性的必要性。基於微服務的雲架構會更加適合這一需求，但 Spring XD 沒有為基於微服務的架構提供直接的支持。
Spring XD 支持大數據的應用場景，但仍有很大一部分項目不需要 Hadoop 來存儲並處理數據。
Spring Cloud Data Flow
作為第二輪技術創新，Pivotal 推出了 Spring Cloud Data Flow 來替代原來的 Spring XD。Spring Cloud Data Flow 繼承了 Spring XD 的優勢，並通過利用雲原生（cloud native）方法提供了更具可擴展性的解決方案。Spring Cloud Data Flow 是一個混合的計算模型，可以將流處理和批處理統一起來。開發人員可以利用 Spring Cloud Data Flow 來創建並操作數據管道來進行處理數據攝入、實時分析和批處理等常見流程。Spring Cloud Data Flow 只會提供一個管理服務模型，旨在精簡數據項目的工程量，並讓開發人員將精力集中在具體問題及對問題的分析上。
Spring Cloud Data Flow 的架構
從 Spring XD 到 Spring Cloud Data Flow，對功能的結構以及利用雲原生架構擴展應用程序方法發生了從根本上的改變。
Spring Cloud Data Flow 從傳統的基於組件的架構轉向了採用更適合雲原生應用的，由消息驅動的微服務架構。現在 Spring XD 模塊已經被部署在雲端上的微服務取代了。
具體地說，Spring Cloud Data Flow 在以下方面有著一些重大變化：
為了利用雲原生平臺，Spring Cloud Data Flow 引入了服務提供者接口（SPI），該接口取代了 Spring XD 運行層（runtime layer）。
像 Admin REST API，shell 和 UI 層這樣的用戶界面和集成元素與 Spring XD 相同，但底層架構已被大幅修改。
服務提供者接口（SPI）取代了基於 Zookeeper 的運行模式。現在 SPI 會與其他系統（例如 Pivotal Cloud Foundry 或 Yarn）協調監測並啟動基於微服務的應用程序。
Spring Cloud Data Flow 的組件：
上圖描繪了使用 Spring Cloud Data Flow 模型創建的一個典型數據流。
作為 Spring Boot 微服務，數據源，作業，數據接收器和數據處理器都可以部署在 Cloud Foundry， Lattice 或 Yarn 集群上。通過使用部署在雲原生平臺上的這些微服務，我們可以創建數據管道並將其輸入到 Yarn，Lattice 或基於 Cloud Foundry 的目標中。平臺特定的 SPI（服務提供者接口）會被用於發現和綁定微服務，以及綁定基於開發平臺的渠道（channel）。
用例
使用 Spring Cloud Data Flow 的真正好處是能夠使用一個統一的框架來快速完成構建和配置工作，並建立數據攝入和處理流程，從而使開發人員能更好地關注具體問題。
我們不妨構建這樣一個用例來在高層面上見識一下 Spring Cloud Data Flow 的改變：在沒有自帶數據源模塊的情況下構造一個完整的數據流，比如對 Facebook 的數據造一個數據流來分析 Facebook 的帖子。 在這種情況下，我們不能用在 Spring Cloud Data Flow 模塊裡能隨便用的 Facebook 數據源模塊，因此我們需要為 Facebook 數據源創建自定義模塊。創建一個數據流需要三個主要的微服務：數據源，數據處理器和數據接收器。這三個微服務都有相應的接口類。
Facebook 數據管道的數據源和數據接收器的微服務示例代碼片段：
Facebook 數據源：
@EnableBindings(Source.class)註解會檢查相應的作為可綁定組件的接口類的實現是否存在（要在應用的 classpath 中設置，參考 Redis），然後這一組件會構建相應的渠道適配器（channel adapters）。所有微服務都會被轉變為 Spring Boot 應用程序來實現更簡單的依賴管理。
Facebook 數據接收器：
上述代碼會接收來自 Facebook 數據流的數據並將其寫入控制檯。Sink.class 在此會作為參數傳遞給 @EnableBinding 註解。另外 @ServiceActivator 會將數據輸入模塊連接到上例中的終端（endpoint）控制檯。
一些作為數據處理器的微服務將根據輸入的 SPEL 表達式過濾來自 FBSource 微服務的 Facebook 帖子，而數據處理器微服務的輸出就會是 FBSink 微服務的輸入。
結論
Spring Cloud Data Flow 使用了 Spring Cloud stream 模塊。我們可以用後者來創建和運行以 Spring Boot 應用為形式的消息傳遞微服務，以便它們可以部署在不同的平臺上，獨立運行並相互交互。在使用 Spring Cloud stream 模塊創建數據管道時，Spring Cloud Data Flow 可以充當類似膠水的角色。
目前有許多用於管理數據攝入，實時分析和數據加載的，獨立的開源項目。Spring Cloud Data Flow 則為數據攝入，實時分析，批處理還有數據輸出提供了一個統一的，可擴展的分佈式服務。
如果對java微服務、分佈式、高併發、高可用、大型互聯網架構技術、面試經驗交流。感興趣可以關注我的頭條號，我會在微頭條不定期的發放免費的資料鏈接，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。歡迎分享，歡迎評論，歡迎轉發
閱讀更多 Java高級架構師 的文章
