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