目的是揭開Spring Cloud Stream和Spring Cloud Function專案的真正目標的神祕面紗，並進行演示他們的新功能。

Spring Cloud Stream是Spring Integration包裝器嗎？

 Spring Cloud Stream，是一個輕量級的Spring Integration輸入/輸出路由器……”。這是一個有趣的看法，但我不同意，儘管它可能是受企業整合模式（EIP）的啟發並且在Spring Integration（SI）的基礎上構建，最後一部分實際上只是一個實現細節，Spring Cloud Stream（SCSt）作為框架絕不是“成為輕量級的Spring Integration輸入/輸出路由器”。

實際上，該陳述表明了問題的一部分，在某種程度上，SI（支援SCSt的一些內部需求的選擇框架）被認為是SCSt的核心，因此許多人都認為SCSt是擴充套件的SI的包裝器。

Spring Cloud Stream一直以來都是關於純微服務，並將它們繫結到資料的源和目標（即訊息傳遞系統），就那麼簡單。它確實是一個繫結和啟用框架。它將一段程式碼（由使用者提供）繫結到公開的源/目標，並根據繫結器的具體實現（例如訊息到達等）啟用此類程式碼，就是這樣。

Function還是非Function？

從歷史上看，Spring Cloud Stream公開了基於註釋的配置模型，該模型要求使用者提供很多可以輕鬆推斷的資訊，從而簡化了配置。

讓我們看下面的兩個程式碼片段

基於註釋：

@SpringBootApplication
@EnableBinding(Processor.class)
public class SampleApplication  {
    @StreamListener(Processor.INPUT)
    @SendTo(Processor.OUTPUT)
    public String uppercase(String value) {
        return value.toUpperCase();
    }
}

基於函式(自v2.1.0起)

@SpringBootApplication
public class SampleApplication  {
    @Bean
    public Function<String, String> uppercase() {
        return value -> value.toUpperCase();
    }
}

兩者都是有效且功能齊全的SCSt應用程式。兩者都做同樣的事情，並且都產生相同的結果，這就提出了一個問題：為什麼？Spring一直以來都是“您關心功能需求，我們會處理非函式性（樣板）”。

因此，在SCSt作為框架及其“繫結和啟用/觸發”的核心目標的上下文中，我們很快意識到這些抽象是樣板，不應洩漏到使用者程式碼中，尤其是以註釋的形式洩漏，因為它們有助於無正當理由而導致此類程式碼對SCSt的二進位制依賴性。

因此，我要說的是，我們正開始緩慢的旅程，從基於註釋的程式設計模型轉變為更加敏捷，簡單且符合Spring Boot要求的，經過明確記錄的直觀模型，並且在有限的條件下實現了直觀的約定。使用者所需的即用型配置。（banq注：從基於註釋到函數語言程式設計是一個大方向）