【云原生系列】第四讲：Knative 之 Eventing
目錄
序言
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 用戶在實現開發和部署階段服務之間松耦合的同時，服務間常要通過不同的事件機制來進行事件傳遞，為了解決大部分的云原生消息通信需求，Knative 提供了 Eventing 組件。
特點：
確保跨服務的互操作性
支持第三方的服務對接?Eventing 系統
2.組成要素
Eventing 主要由
三部分構成。
2.1 事件源（Event Source）
Source 是事件的來源，它是定義事件在何處生成以及如何將事件傳遞給關注對象的方式?
- 事件生成
- 事件傳遞
目前支持以下8種事件源：?
ApiserverSource：每次創建或更新 Kubernetes 資源時，ApiserverSource 都會觸發一個新事件
GitHubSource：GitHub 操作時，GitHubSource 會觸發一個新事件
GcpPubSubSource： GCP 云平臺 Pub/Sub 服務會觸發一個新事件
AwsSqsSource：Aws 云平臺 SQS 服務會觸發一個新事件
ContainerSource: ContainerSource 將實例化一個容器，通過該容器產生事件
CronJobSource: 通過 CronJob 產生事件
KafkaSource: 接收 Kafka 事件并觸發一個新事件
CamelSource: 接收 Camel 相關組件事件并觸發一個新事件
2.2 事件處理（Flow）
前 Knative 支持如下事件接收處理：
-
接收：直接事件接收
通過事件源直接轉發到單一事件消費者。支持直接調用 Knative Service 或者 Kubernetes Service 進行消費處理。這樣的場景下，如果調用的服務不可用，事件源負責重試機制處理
-
轉發：通過事件通道(Channel)以及事件訂閱(Subscriptions)轉發事件處理
這樣的情況下，可以通過 Channel 保證事件不丟失并進行緩沖處理，通過 Subscriptions 訂閱事件以滿足多個消費端處理
-
過濾：通過 brokers 和 triggers 支持事件消費及過濾機制
2.3?事件消費者（Event Consumer）
為了滿足將事件發送到不同類型的服務進行消費， Knative Eventing 通過多個 k8s 資源定義了兩個通用的接口：
- Addressable 接口：提供可用于事件接收和發送的 HTTP 請求地址，并通過status.address.hostname字段定義。作為一種特殊情況，Kubernetes Service 對象也可以實現 Addressable 接口
- Callable 接口：接收通過 HTTP 傳遞的事件并轉換事件。可以按照處理來自外部事件源事件的相同方式，對這些返回的事件做進一步處理
目前 Knative 支持通過 Knative Service 或者 Kubernetes Service 進行消費事件。
另外針對事件消費者，如何事先知道哪些事件可以被消費？?
將事件源發送到通道，并準備好處理它們的服務，但目前沒有辦法獲取從通道發送到服務的事件。為此，Knative設計了訂閱功能。訂閱是通道和服務之間的紐帶，指示Knative如何在整個系統中管理事件，如下圖
總結：
Knative中的服務不關心事件和請求是如何獲取的。
- 可以獲取來自入口網關的HTTP請求
- 可以獲取從通道發送來的事件
無論通過何種方式獲取，服務僅接收HTTP請求。
這是Knative中一個重要的解耦方式。
它確保將代碼編寫到架構中，而不是在底層創建訂閱、通道向服務發送事件。?
3.架構模式
架構模式有三種：
3.1?Source to Service
從源直接傳遞到單個服務（可尋址端點，包括Knative服務或核心Kubernetes服務）。
在這種情況下，如果目標服務不可用，則源負責重試或排隊事件?
?3.2Channels &?Subscriptions
通過渠道和訂閱，Knative事件系統定義了一個渠道，該渠道可以連接到各種后端（例如內存中，Kafka和GCP PubSub）來sourcing事件。
每個通道可以具有一個或多個以Sink Services形式的訂閱用戶
如圖，該訂閱用戶可以接收事件消息并根據需要對其進行處理。通道中的每個消息都將格式化為CloudEvent，并在鏈中進一步發送給其他訂閱用戶以進行進一步處理。
通道和訂閱使用模式無法過濾消息。
3.3?Brokers &?Triggers
Broker提供了一系列事件，可以通過屬性選擇事件。
它接收事件并將其轉發給由一個或多個匹配Trigger定義的訂閱用戶。
Trigger描述了事件屬性的過濾器，應將其傳遞給可尋址對象。
可以根據需要創建任意數量的Trigger。
?
?3.4 其他
更高級別的事件構造：
在某些情況下，可能希望一起使用一組協作功能，對于這些用例，Knative Eventing提供了兩個附加資源：
- Sequence?提供一種定義功能的有序列表的方法。
- Parallel?提供了一種定義事件分支列表的方法。
后面會寫一篇文章，專門來講有序列表和分支列表
4.總結
Knative 使用 Build 提供云原生“從源代碼到容器”的鏡像構建能力，通過 Serving 部署容器并提供通用的服務模型，同時以 Eventing 提供事件全局訂閱、傳遞和管理能力，實現事件驅動。這就是 Knative 呈現給我們的標準 Serverless 編排框架
5.投票
總結
以上是生活随笔為你收集整理的【云原生系列】第四讲：Knative 之 Eventing的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 安徽省2019c语言二级答案,二级c语言
- 下一篇： 个人虚拟化集群搭建教程