序言

跨系統和平臺的資料統一性是Cloud Event 規範獨特而崇高的目標。隨著其日益廣泛的採用，人們希望開發者和架構師不再需要擔心如何處理來自不同系統和平臺的各種事件。. . 但這篇文章的重點不是重新討論或重新論證 Cloud Events。簡單的谷歌搜尋會為您提供很多可讀的內容來幫助回答“為什麼選擇 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 本身分為定義明確的元資料欄位（必需和可選）以及鬆散定義或未定義的欄位，後者稱為 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 時代？

以下是一個應用程式示例，它接收一個作為 HTTP 請求的 Cloud Event，並生成一個作為 HTTP 響應的 Cloud Event

@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 端點而另一個是訊息處理程式？嗯，要回答這些問題，我們需要了解執行上下文，這來自於您的應用程式 classpath 中可用的 Spring Boot 自動配置。例如，為了使第一個應用程式的描述為真，您需要在 classpath 中新增 spring-cloud-function-web 依賴，它帶來了所有必要的元件和額外的自動配置，將您的函式暴露為 REST 端點。至於第二個應用程式，我們可以簡單地利用我們已經為 Apache Kafka、AMQP、Solace、HTTP、AWS、Google 等提供的豐富的繫結器庫。這些繫結器和相關的自動配置將把示例程式碼轉化為訊息處理程式。

Message

Message 是實現這一功能的核心，它是 Spring 中所有活動部件都理解的規範結構。這是一種能夠清楚地傳達意圖和期望的結構。它從哪裡來？它將去哪裡？誰傳送的？內容是什麼？它代表一個 Cloud Event 嗎？如果是，它是二進位制模式還是結構化模式？ 問題無窮無盡，但一個不變的事實是，Message 作為一種結構和概念，能夠很好地回答這些問題。考慮到這一點，Cloud Event 成為另一種 Message。Spring Framework 可以像處理任何其他 Message 一樣處理它，讓您專注於業務邏輯，而不是底層細節。

總結

所以，Message 不僅是表示 Cloud Event 的合適結構，它也是在 Spring 中處理 Cloud Event 用例的正確抽象。希望這一點已經清楚了，隨著即將到來的對 Message 的 Cloud Event 支援，我們正在為依賴 Spring Messaging 的任何應用程式提供 Cloud Events 支援的道路上。

在後續文章中，我們將介紹即將到來的 Cloud Event 在多個 Spring 框架中的技術細節，以及使用Cloud Event Java SDK 與 Spring 的整合。您現在也可以開始檢視一些示例

• Spring Cloud Function/Spring Cloud Stream
• KNative
• 透過 Java SDK 實現 Spring 響應式