領先一步
VMware 提供培訓和認證,助你加速進步。
瞭解更多在 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
的函式的組合。你也可以說我們已經*編排(orchestrated)*了一個簡單的管道,包括執行 uppercase
函式,然後將其輸出傳送到 reverse
函式。這裡的術語*編排*很重要,我們將在文章後面更詳細地討論它。
企業整合模式是一組模式,允許你將業務案例描述為清晰定義且易於理解的模式集合。一些例子包括*過濾器*、*轉換器*、*路由器*等。有關 EIP 的更多詳細資訊,請參閱此連結。Spring 透過 Spring Integration 框架提供了 EIP 的參考實現。例如,使用與之前相同的兩個函式示例,我們可以使用 SI 的 Java DSL 構建一個管道,如下所示
IntegrationFlow.fromChannel(inputChannel)
.transform(uppercase)
.transform(reverse);
有關 SI 的 Java DSL 的更多資訊,請參閱Java DSL 文件以及此快速教程。
這裡的核心要點是,我們剛剛展示了透過編排管道來解決同一問題的兩種方法。兩者都可以看作是複雜功能的編排者
為什麼這很重要?正如之前所述,*沒有複雜的難題,因為每個複雜的難題都不過是由一系列簡單的難題組成*。所以複雜性是一種組合。然而,即使是複雜性也可以被視為直截了當或複雜的事物。讓我們看幾個用例來設定上下文
本著將複雜性分解為簡單性的精神,第一種情況可以分解為兩個順序的服務:*計算 -> 儲存*(類似於我們之前的*轉大寫 -> 反轉*示例)。第二種情況,雖然類似,但包含一個決策點,該決策點可以觸發一個迴圈回,其中包含某種型別的附加服務呼叫(等等)。換句話說,它不像簡單的*計算 -> 儲存*那樣直截了當。
首先,讓我們快速說明 EIP 及其實現 Spring Integration 可以輕鬆處理這兩種用例。它們提供了
另一方面,SCF 及其函式組合特性可以輕鬆處理第一個用例,這是理所當然的。畢竟,計算 -> 儲存
是一系列按順序排列的功能 - computeFunction.andThen(saveFunction).andThen(..)
或使用 SCF 的表示法 computeFunction | saveFunction
。此外,由於 SCF 和 SI 內部實現上的差異,使用 SCF 組合要簡單得多,效能也更高。然而,第二個用例(它並非完全按照一系列步驟對齊)使用函式組合將很難甚至不可能實現。在這種情況下,使用 SI 這樣的框架將是首選。
好訊息是,分解後,複雜性仍然可以被視為 SCF 和 SI 識別為一等公民的函式,正如 Artem Bilan 在這篇文章中所述。這意味著你可以推遲決定你的編排方法,直到稍後選擇 SI、SCF 或兩者的組合。
SCF 組合更適合編排按順序排列的功能,而 SI 是適合 EIP 類別中其他所有內容的更好選擇。