Spring中雲事件簡介

跨系統和平臺的資料一致性是Cloud Event規範的一個獨特而崇高的目的。隨著越來越多的採用，希望是開發人員和架構師將不再需要擔心如何處理來自不同系統和平臺的各種事件。

Message是EIP Message的Spring實現，它是表示Cloud Event的適當結構！

訊息是雲事件

根據官方網站的說法，Cloud Events是“以通用方式描述事件資料的規範”。

如果您閱讀了該規範（這很簡單），您很快就會意識到Cloud Event有效地定義了規範和獨立於平臺的資料結構，從而可以在系統和平臺之間以統一的方式進行交換。結構很簡單。它將一些有效載荷封裝為一個data欄位，並將其他後設資料封裝為attributes（鍵/值結構）。的attributes本身是分割成稱為明確定義的後設資料欄位attributes（必需和可選）稱為和鬆散定義或未定義欄位extension attributes。

現在，對於那些熟悉訊息（核心企業整合模式之一）及其在Spring Messaging中定義的人來說，您可能會說：這看起來非常熟悉！當然是這樣。

就像Cloud Event一樣，Message定義了規範的和獨立於平臺的資料結構，以統一的方式在系統和平臺之間交換。這種結構也非常簡單。它將一些有效載荷封裝為一個payload欄位，將後設資料封裝為headers（鍵/值結構）。

當前依賴Spring Messaging的數萬個框架和應用程式可以自動支援Cloud Event用例，這意味著此類框架的使用者以及框架本身將能夠識別傳入的Cloud Event例項並建立它們，所有這些都在規範定義的協議詳細資訊範圍內，例如屬性字首，型別系統等。

使用模式

我們還需要檢視一些典型的Cloud Event使用模式。我們這樣做是為了隔離我們所謂的功能與非功能（樣板）方面。因此，讓我們描述其中的一些：

• 產生一些東西並將其封裝到Cloud Event中
• 消費可能源自雲事件的內容
• 消耗實際的Cloud Event（與上面的有所不同，因為它意味著消耗了整個事件）
• 根據Cloud Event屬性進行路由和過濾

Spring

十多年來，Spring已通過基於訊息的框架成功支援轉換，型別轉換，路由，過濾和許多其他訊息傳遞模式（其中大多數由Enterprise Integration Patterns描述），生產中有成千上萬個使用者應用程式在執行。我們如何忘記基礎結構型別的問題，例如連線性，會話和事務管理，傳送和接收，重試，錯誤處理，恢復等等

Spring嘗試處理非功能性（模板）問題，只給您提供功能性（業務邏輯）問題。在Spring Boot時代，支援Cloud Events的典型Spring應用程式會是什麼樣？

這是一個應用程式示例，該應用程式接收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端點所需的所有必要元件和其他自動配置。

至於第二個，我們可以簡單地依靠extensive library of binders，我們已經提供了Apache Kafka，AMQP，Solace，HTTP，AWS，Google等產品。這些繫結程式和相關的自動配置會將示例程式碼轉換為訊息處理程式

訊息

訊息是核心，這是Spring中所有元件都瞭解一個規範的結構。這是一種可以清楚傳達意圖和期望的結構。它是從哪裡來的？它會去哪裡？誰寄的？內容是什麼？它代表雲事件嗎？如果是這樣，它是二進位制模式還是結構化模式？這樣的列表是無止境的，但是不變的是，訊息作為一種結構和概念很容易回答這些問題。考慮到這一點，Cloud Event成為另一種訊息。Spring框架可以像處理其他任何Message一樣處理它，使您可以自由考慮業務邏輯，而不必考慮管道的細節。

因此，訊息不僅是一個代表雲事件的適當的結構，也是處理雲事件的正確抽象。隨著即將對訊息提供的Cloud Event支援，Spring正在為依賴Spring Messaging的任何應用程式提供Cloud Events支援。