領先一步
VMware 提供培訓和認證，以加速您的進展。
了解更多Cloud Events 與 Spring - 第一部分
序言
跨系統和平台的資料一致性 是 Cloud Event 規範的獨特且崇高的目標。 隨著其日益普及，希望開發人員和架構師不再需要擔心如何處理來自不同系統和平台的各種事件。 。 。但是這篇文章的重點不是重新討論或重新證明 Cloud Events 的合理性。 簡單的 Google 搜尋會為您提供許多閱讀要點，以幫助您解決「為何選擇 Cloud Events？」這個問題。 本文以及後續關於此主題的文章的目標是分享一些想法以及我們在 Spring 所做的工作，以預期和處理 Cloud Events 更廣泛的採用。
簡介
Message，是 Spring 對 EIP Message 的實作，是一個足以代表 Cloud Event 的結構！ 這就是我們在這裡建構的案例。 如果屬實，那麼目前依賴 Spring Messaging 的任何框架或應用程式將自動支援 Cloud Event 用例。 所以 。 。
一個 Message 就是一個 Cloud Event
根據官方 網站，Cloud Events 是「一種以通用方式描述事件資料的規範」。
如果您閱讀該規範（非常簡單），您會很快意識到 Cloud Event 有效地定義了一種規範的、與平台無關的資料結構，以便以統一的方式在系統和平台之間交換。 該結構相當簡單。 它將一些有效負載封裝為 data 欄位，並將其他中繼資料封裝為 attributes（鍵/值結構）。 attributes 本身分為明確定義的中繼資料欄位，稱為 attributes（必填和可選），以及寬鬆定義或未定義的欄位，稱為 extension attributes。
目前就這麼多。
現在，對於那些熟悉 Message - 核心 企業整合模式 之一 - 及其在 Spring Messaging 中的定義的人來說，您可能會說：這看起來非常熟悉！ 確實如此。
就像 Cloud Event 一樣，Message 定義了一種規範的、與平台無關的資料結構，以便以統一的方式在系統和平台之間交換。 這種結構非常簡單。 它將一些有效負載封裝為 payload 欄位，並將中繼資料封裝為 headers（鍵/值結構）。
為什麼這很重要？ 與任何其他技術一樣，在 Spring 中為 Cloud Events 提供整合實際上是一個問題，即在眾所周知且（對其用戶而言）熟悉的 Spring 慣用語和抽象概念中實現其概念所需的努力。 這就是為什麼會想到 Message。 鑒於其與 Cloud Event 規範定義的結構幾乎完美匹配，「Message 是否可以是 Spring 中代表 Cloud Event 的適當抽象？」 因為，如果答案是「是」，則數以萬計目前依賴 Spring Messaging 的框架和應用程式可以自動支援 Cloud Event 用例，這意味著這些框架的用戶以及框架本身將能夠識別傳入的 Cloud Event 實例並建立它們，所有這些都在規範定義的協議細節（例如屬性前綴、類型系統等）的範圍內。
功能性與非功能性（樣板程式碼）
我們還需要查看一些典型的 Cloud Event 使用模式。 我們這樣做是為了隔離我們所謂的功能性與非功能性（樣板程式碼）方面。 因此，讓我們描述其中一些
- 產生一些東西並將其封裝到 Cloud Event 中
- 消費一些可能源自 Cloud Event 的東西
- 消費實際的 Cloud Event（與上述不同，因為它暗示消費整個事件）
- 根據 Cloud Event 屬性進行路由和篩選
此清單是一些典型使用模式的小子集，但它有助於說明問題領域。 它還有助於我們開始理解和隔離功能性與非功能性方面。 有趣的是，大多數描述的模式都是非功能性方面的例子，經驗豐富的 Spring 用戶會期望由框架來處理。 例如，雖然預期用戶「產生一些東西」（功能性），但「將其封裝到 Cloud Event 中」的部分應由框架處理（非功能性）。 相同的原則適用於消費 Cloud Event 時。 雖然含糊地說明，但它通常意味著用戶可能只關心 Cloud Event 的資料部分，最有可能期望它是框架應提取、轉換和提供的特定於領域的物件的形式。 這些再次是非功能性方面的例子。 然後是 Cloud Event 屬性及其前綴（例如，ce_ 與 ce- 等）的問題，它們有效地描述了事件的來源或目的地，人們會期望框架也處理這些問題，特別是考慮到功能的實施者甚至可能不知道事件的來源或目的地。
Spring
十多年來，Spring 一直成功地透過基於 Message 的框架支援轉換、類型轉換、路由、篩選和許多其他訊息傳遞模式（其中大多數由 企業整合模式描述），並且有數以萬計的用戶應用程式在生產環境中運行。 我們怎麼能忘記基礎架構類型的問題，例如連線能力、會話和交易管理、傳送和接收、重試、錯誤處理、恢復等等？ 在 Spring 中，我們的一般座右銘是我們嘗試處理非功能性（樣板程式碼）問題，只留下功能性（業務邏輯）問題。 因此，對於我們來說，始終重要的是在給定的整合上下文中區分這兩者，並盡可能將其外包給框架。 我們還公開實用程式、函式庫和配置選項，讓您可以影響某些非功能性問題，因為由於各種原因，仍然可能需要這樣做。
那麼，鑒於此，支援 Cloud Events 的典型 Spring 應用程式會是什麼樣的，尤其是在 Spring Boot 時代？
這是一個應用程式的範例，該應用程式將 Cloud Event 作為 HTTP 請求接收，並將 Cloud Event 作為 HTTP 回應產生
@SpringBootApplication
public static class SampleApplication
public static void main(String[] args) throws Exception {
SpringApplication.run(SampleApplication.class, args);
}
@Bean
Function<Person, Employee> hire() {
return person -> {
Employee employee = ...
return employee;
};
}
}
這是一個應用程式的範例，該應用程式從 Apache Kafka 接收 Cloud Event 並將其傳送到 RabbitMQ 訊息佇列代理程式
@SpringBootApplication
public static class SampleApplication
public static void main(String[] args) throws Exception {
SpringApplication.run(SampleApplication.class, args);
}
@Bean
Function<Person, Employee> hire() {
return person -> {
Employee employee = ...
return employee;
};
}
}
我們省略了這些函數的實作細節，因為它們與主題無關。 框架實際上並不關心您做什麼。 它只關心您期望什麼 - 輸入 - 以及您產生什麼 - 輸出 - 並且該資訊可以從函數簽名中獲得。
不過，我相信您們一定不是在想這些，您們可能想知道，我提出的這兩個看似不同的應用程式，實際上為何完全相同？以及哪裡說明了一個應用程式是 REST 端點，而另一個是訊息處理器？嗯，要回答這些問題，我們需要了解執行的背景，這來自於 Spring Boot 的自動配置，這些自動配置在您的應用程式類別路徑中可用。因此，舉例來說，要使第一個應用程式的描述為真，您需要在類別路徑中加入 spring-cloud-function-web 相依性，這會引入所有必要的元件和額外的自動配置，以將您的函式公開為 REST 端點。至於第二個應用程式，我們可以簡單地回歸到我們已經為 Apache Kafka、AMQP、Solace、HTTP、AWS、Google 等提供的 廣泛的綁定器函式庫。這些綁定器和相關的自動配置會將範例程式碼轉換為訊息處理器。
訊息 (Message)
訊息是這個功能的中心，它是 Spring 中所有移動部件都能理解的標準結構。它是一種可以清楚地傳達意圖和期望的結構。它從哪裡來？它將去哪裡？誰發送的？內容是什麼？它是否代表一個雲端事件？如果是，它是二進制模式還是結構化模式？這個列表是無窮無盡的，但唯一不變的是，作為一個結構和一個概念，訊息能夠很好地回答這些問題。有了這個想法，雲端事件就變成了另一種訊息。Spring Framework 可以像處理任何其他訊息一樣處理它，讓您可以專注於您的業務邏輯，而不是管線的細節。
總結
因此，訊息 (Message)不僅僅是代表雲端事件的一個適當結構，它也是在 Spring 中處理雲端事件使用案例的正確抽象概念。我希望這很清楚，隨著即將到來的對訊息的雲端事件支援，我們正走在為任何依賴 Spring Messaging 的應用程式提供雲端事件支援的道路上。
在 後續文章 中，我們將介紹在幾個 Spring 框架內即將到來的雲端事件支援的技術細節，以及使用 Cloud Event Java SDK 將雲端事件與 Spring 整合。您也可以開始查看一些範例。