在上一篇文章中，我試圖說明我們在Spring Cloud Stream (SCSt) 中轉向函數語言程式設計模型的理由。它帶來了更少的程式碼，更少的配置。然而，最重要的是，您的程式碼與 SCSt 的內部實現完全解耦且獨立。

在這篇文章中，我將更深入地探討並總結我們的函式式支援的核心特性，特別是其響應式特性。

重要提示：使用 @StreamListener/@EnableBinding 可以完成的任何事情，在不使用它們的情況下也可以完成。換句話說，函式式支援現在與基於註解的支援功能相容。

雖然下面描述的所有特性都是 Spring Cloud Function (SCF)（SCSt 的依賴項）的特性，但在理解函式在 SCSt 上下文中的附加含義時，需要注意一些細微之處。

Supplier, Function 和 Consumer

SCSt 將任何型別為 Supplier、Function 或 Consumer 的 bean，或任何可以對映到 Supplier、Function 或 Consumer 的 bean（例如 POJO 函式、Kotlin Lambda 等）視為訊息處理程式（Function 或 Consumer）或訊息源（Supplier）。根據使用的函式式策略型別，輸入和輸出繫結會透過以下命名約定自動生成：<函式名>-<in/out>-<索引>。

考慮以下示例

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

前面的函式被視為一個訊息處理程式，它從 uppercase-in-0 繫結消費併發送到 uppercase-out-0 繫結。其餘現有的流屬性可以照常使用。例如 --spring.cloud.stream.bindings.uppercase-in-0.content-type=text/plain。

點選這裡瞭解更多詳情和配置選項。

###命令式還是響應式 函式可以是命令式的或響應式的。命令式函式在每個單獨的事件上觸發，而響應式函式觸發一次，並傳遞對由Project Reactor提供的整個事件流抽象（例如 Flux 和 Mono）的引用。

考慮以下兩組示例

命令式

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

響應式

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

除了提供一種不同的（monadic）程式設計風格來處理事件（這很容易被視為個人偏好問題）之外，響應式程式設計對於某些用例增加了額外價值，否則實現這些用例會相當複雜。雖然本文不會詳細討論這些用例或響應式模式，但狀態管理用例（例如視窗化、聚合和分組）以及流的拆分或多個流的合併用例仍然值得提及，我將在下一節中討論這些內容。

關於響應式函式的繫結和命名規則，它們與前一節中解釋的相同。

注意：雖然前面的示例使用了 Function，但相同的規則也適用於 Supplier 和 Consumer。使用者指南的Spring Cloud Function 支援部分以及Reactor 文件提供了更多詳情。

###函式元數 有時需要對資料流進行分類和組織。例如，考慮一個經典的大資料用例，處理包含“訂單”和“發票”等未組織資料，您希望將它們分別儲存到不同的資料儲存中。這時，函式元數（具有多個輸入和輸出的函式）的支援就派上用場了。

讓我們看一個這類函式的示例（完整的實現細節可在此處找到），

@Bean
public Function<Flux<Integer>, Tuple2<Flux<String>, Flux<String>>> organise() {
	return flux -> ...;
}

鑑於 Project Reactor 是 SCF 的核心依賴，我們使用了它的 Tuple 庫。Tuple 透過向我們傳達基數和型別資訊，提供了獨特的優勢。這兩點在 SCSt 的上下文中都極其重要。基數讓我們知道需要建立多少輸入和輸出繫結，並將它們繫結到函式的相應輸入和輸出。瞭解型別資訊確保了正確的型別轉換。

此外，繫結名稱命名約定的“索引”部分也在這裡發揮作用，因為在這個函式中，兩個輸出繫結的名稱是 organise-out-0 和 organise-out-1。

重要提示：目前，函式元數僅支援以複雜事件處理為中心的響應式函式（Function<TupleN<Flux<?>...>, TupleN<Flux<?>...>>），在此場景下，對事件匯合進行評估和計算通常需要檢視事件流，而不是單個事件。

有關最新詳情，請閱讀使用者指南中具有多個輸入和輸出引數的函式一節。