目錄

序言

1.基礎介紹?

2.組成要素

2.1 事件源（Event Source）

2.2 事件處理（Flow）

2.3?事件消費者（Event Consumer）

3.架構模式

3.1?Source to Service

?編輯?3.2Channels &?Subscriptions

3.3?Brokers &?Triggers

?3.4 其他

4.總結

5.投票

---

序言

三言兩語，不如細心探索。

今天整理了一下Eventing相關知識點，希望此文，能幫助讀者對Knative Eventing?有一個初步的了解

文章標記顏色說明：

• 黃色：重要標題
• 紅色：用來標記結論
• 綠色：用來標記一級論點
• 藍色：用來標記二級論點

1.基礎介紹?

Kubernetes 用戶在實現(xiàn)開發(fā)和部署階段服務之間松耦合的同時，服務間常要通過不同的事件機制來進行事件傳遞，為了解決大部分的云原生消息通信需求，Knative 提供了 Eventing 組件。

特點：

服務開發(fā)部署松耦合

支持各種事件傳遞

事件的生產者和事件的消費者是相互獨立的

確?？绶盏幕ゲ僮餍?/span>

支持第三方的服務對接?Eventing 系統(tǒng)

2.組成要素

Eventing 主要由

事件源（Event Source）

事件處理（Flow）

事件消費者（Event Consumer）

三部分構成。

2.1 事件源（Event Source）

Source 是事件的來源，它是定義事件在何處生成以及如何將事件傳遞給關注對象的方式?

• 事件生成
• 事件傳遞

目前支持以下8種事件源：?

ApiserverSource：每次創(chuàng)建或更新 Kubernetes 資源時，ApiserverSource 都會觸發(fā)一個新事件

GitHubSource：GitHub 操作時，GitHubSource 會觸發(fā)一個新事件

GcpPubSubSource： GCP 云平臺 Pub/Sub 服務會觸發(fā)一個新事件

AwsSqsSource：Aws 云平臺 SQS 服務會觸發(fā)一個新事件

ContainerSource: ContainerSource 將實例化一個容器，通過該容器產生事件

CronJobSource: 通過 CronJob 產生事件

KafkaSource: 接收 Kafka 事件并觸發(fā)一個新事件

CamelSource: 接收 Camel 相關組件事件并觸發(fā)一個新事件

2.2 事件處理（Flow）

前 Knative 支持如下事件接收處理：

• 接收：直接事件接收

  通過事件源直接轉發(fā)到單一事件消費者。支持直接調用 Knative Service 或者 Kubernetes Service 進行消費處理。這樣的場景下，如果調用的服務不可用，事件源負責重試機制處理

• 轉發(fā)：通過事件通道(Channel)以及事件訂閱(Subscriptions)轉發(fā)事件處理

  這樣的情況下，可以通過 Channel 保證事件不丟失并進行緩沖處理，通過 Subscriptions 訂閱事件以滿足多個消費端處理

• 過濾：通過 brokers 和 triggers 支持事件消費及過濾機制

2.3?事件消費者（Event Consumer）

為了滿足將事件發(fā)送到不同類型的服務進行消費， Knative Eventing 通過多個 k8s 資源定義了兩個通用的接口：

• Addressable 接口：提供可用于事件接收和發(fā)送的 HTTP 請求地址，并通過status.address.hostname字段定義。作為一種特殊情況，Kubernetes Service 對象也可以實現(xiàn) Addressable 接口
• Callable 接口：接收通過 HTTP 傳遞的事件并轉換事件?？梢园凑仗幚韥碜酝獠渴录词录南嗤绞?#xff0c;對這些返回的事件做進一步處理

目前 Knative 支持通過 Knative Service 或者 Kubernetes Service 進行消費事件。

另外針對事件消費者，如何事先知道哪些事件可以被消費？?

將事件源發(fā)送到通道，并準備好處理它們的服務，但目前沒有辦法獲取從通道發(fā)送到服務的事件。為此，Knative設計了訂閱功能。訂閱是通道和服務之間的紐帶，指示Knative如何在整個系統(tǒng)中管理事件，如下圖

總結：

Knative中的服務不關心事件和請求是如何獲取的。

• 可以獲取來自入口網(wǎng)關的HTTP請求
• 可以獲取從通道發(fā)送來的事件

無論通過何種方式獲取，服務僅接收HTTP請求。

這是Knative中一個重要的解耦方式。

它確保將代碼編寫到架構中，而不是在底層創(chuàng)建訂閱、通道向服務發(fā)送事件。?

3.架構模式

架構模式有三種：

Source to Service

Channels &?Subscriptions

Brokers &?Triggers

3.1?Source to Service

從源直接傳遞到單個服務（可尋址端點，包括Knative服務或核心Kubernetes服務）。

在這種情況下，如果目標服務不可用，則源負責重試或排隊事件?

?3.2Channels &?Subscriptions

通過渠道和訂閱，Knative事件系統(tǒng)定義了一個渠道，該渠道可以連接到各種后端（例如內存中，Kafka和GCP PubSub）來sourcing事件。

每個通道可以具有一個或多個以Sink Services形式的訂閱用戶

如圖，該訂閱用戶可以接收事件消息并根據(jù)需要對其進行處理。通道中的每個消息都將格式化為CloudEvent，并在鏈中進一步發(fā)送給其他訂閱用戶以進行進一步處理。

通道和訂閱使用模式無法過濾消息。

3.3?Brokers &?Triggers

Broker提供了一系列事件，可以通過屬性選擇事件。

它接收事件并將其轉發(fā)給由一個或多個匹配Trigger定義的訂閱用戶。

Trigger描述了事件屬性的過濾器，應將其傳遞給可尋址對象。

可以根據(jù)需要創(chuàng)建任意數(shù)量的Trigger。

?

?3.4 其他

更高級別的事件構造：

在某些情況下，可能希望一起使用一組協(xié)作功能，對于這些用例，Knative Eventing提供了兩個附加資源：

• Sequence?提供一種定義功能的有序列表的方法。
• Parallel?提供了一種定義事件分支列表的方法。

后面會寫一篇文章，專門來講有序列表和分支列表

4.總結

Knative 使用 Build 提供云原生“從源代碼到容器”的鏡像構建能力，通過 Serving 部署容器并提供通用的服務模型，同時以 Eventing 提供事件全局訂閱、傳遞和管理能力，實現(xiàn)事件驅動。這就是 Knative 呈現(xiàn)給我們的標準 Serverless 編排框架

Build 鏡像構建

Serving 容器部署

Eventing 事件全局訂閱、傳遞、管理

5.投票

總結

以上是生活随笔為你收集整理的【云原生系列】第四讲：Knative 之 Eventing的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。