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

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

重要提示：您使用 @StreamListener/@EnableBinding 所能做的一切，都可以在沒有它們的情況下完成。換句話說，函式式支援現在與基於註解的支援功能相容。

雖然下面描述的所有特性都是 Spring Cloud Function (SCF)（SCSt 的一個依賴項）的特性，但要理解函式在 SCSt 上下文中的額外含義，必須注意某些細微差別。

Supplier、Function 和 Consumer

任何型別為 Supplier、Function 或 Consumer 的 bean，或任何可以對映到 Supplier、Function 或 Consumer 的 bean（例如 POJO 函式、Kotlin lambdas 等），都被 SCSt 視為訊息處理器（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());
    }
}

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

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

注意：儘管前面的示例使用 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<?>...>>），其中事件融合的評估和計算通常需要檢視事件流而不是單個事件。

有關最新詳細資訊，請閱讀使用者指南的具有多個輸入和輸出引數的函式部分。