為了準備即將釋出的 Spring Cloud Stream (SCSt) 3.0.0 - Horsham 和 Spring Cloud Function (SCF) 3.0.0，我們釋出了一系列文章，討論並展示了新功能和增強功能。我們提供了從基於註解的程式設計模型轉向函式模型的動機和理由，然後我們詳細介紹了函式式方法以及反應式函式。在另一篇文章中，這與我們接下來要討論的內容相關，Artem 展示了將函式式方法與 Spring Integration 專案結合起來的好處。我們還在上一篇文章中討論了事件路由。

在這篇文章中，我們將討論函式組合和企業整合模式 (EIP)，它們的共性、差異以及在 SCSt 環境下它們如何相互補充。

“沒有複雜的問題，因為每個複雜的問題都不過是一系列簡單問題的集合。”

函式組合

函式組合是 SCF 的一項功能，它允許您以宣告方式將多個函式組合在一起。以下示例展示瞭如何實現：

--spring.cloud.function.definition=uppercase|reverse

在這裡，我們實際上提供了一個單一函式的定義，該函式本身是由一個名為 uppercase 的函式和一個名為 reverse 的函式組合而成的。您也可以說我們已經編排了一個簡單的管道，該管道包括執行 uppercase 函式，然後將其輸出傳送到 reverse 函式。這裡的術語編排很重要，我們稍後將在文章中更詳細地介紹它。

企業整合模式 (EIP)

企業整合模式是一組模式，它們允許您將業務案例描述為一組清晰定義且易於理解的模式。一些示例包括過濾器、轉換器、路由器等。有關 EIP 的更多詳細資訊，請參閱此連結。Spring 透過 Spring Integration 框架提供了 EIP 的參考實現。例如，透過使用與之前相同的兩個函式示例，我們可以構建一個使用 SI 的 Java DSL 的管道，如下所示：

IntegrationFlow.fromChannel(inputChannel)
        .transform(uppercase)
        .transform(reverse);

有關 SI 的 Java DSL 的更多資訊，請參閱 Java DSL 文件以及此快速教程。

這裡的核心觀點是，我們剛剛展示了兩種透過編排管道來解決相同問題的方法。兩者都可以看作是複雜功能的編排器。

• 透過組合進行編排：您得到一個單一函式。
• 透過委託進行編排：您得到某種流程。

為什麼這很重要？如前所述，沒有複雜的問題，因為每個複雜的問題都不過是一系列簡單問題的集合。所以複雜性就是一種組合。然而，即使是複雜性也可以被看作是直接的或複雜的。讓我們看幾個用例來設定上下文。

• a) 考慮一個你需要計算一些東西…並將其儲存到資料庫的場景。
• b) 考慮另一個場景，你需要計算一些東西，但是，如果某些屬性缺失或未就緒，你需要將其傳送回去以獲取更多資訊，然後再次計算（如果提供了足夠的資訊），然後將其儲存到資料庫。

本著將複雜性分解為簡單性的精神，第一種情況可以分解為按順序排列的兩個服務：計算 -> 儲存（類似於我們之前的大寫 -> 反轉示例）。第二種情況雖然相似，但包含一個決策點，該決策點可以觸發一個包含某種附加服務呼叫（等等）的迴圈。換句話說，它不像簡單的計算 -> 儲存那麼直接。

Spring Integration 或 Spring Cloud Function 組合？

首先，讓我們快速說明 EIP 及其實現 Spring Integration 可以輕鬆處理這兩種用例。它們提供：

• 將一個程序的結果按順序傳遞給另一個程序的模式
• 回溯的能力
• 根據某些條件進行路由或過濾
• 更多選項

另一方面，SCF 憑藉其函式組合功能，可以輕鬆處理第一個用例，這是理所當然的。畢竟，compute -> save 是一系列按順序排列的功能集合 - computeFunction.andThen(saveFunction).andThen(..) 或使用 SCF 符號 computeFunction | saveFunction。此外，鑑於 SCF 和 SI 內部實現上的差異，SCF 組合要簡單得多且效能更高。然而，第二個用例（其步驟並非完全按順序排列）如果不是不可能的話，也很難透過函式組合來實現。在這種情況下，使用 SI 這樣的框架將是首選。

好訊息是，當分解後，複雜性仍然可以被實現為 SCF 和 SI 認可的一等公民函式，正如 Artem Bilan 在這篇文章中所述。這意味著您可以推遲決定編排方法，稍後選擇 SI 或 SCF，或者兩者的組合。

總結

SCF 組合更適合編排按順序排列的功能，而 SI 是更適合其他所有符合 EIP 類別情況的選擇。