【图解 Knative】剖析 Eventing Broker-Trigger 实现原理
1. 背景介紹
我們都知道，Knative 有兩個主要的子項目：Serving 和 Eventing。其中 關于 Serviing 可以查看之前的一篇公眾號文章 【超詳細】深入探究 Knative 擴縮容的奧秘。Eventing 將系統中的服務以事件驅動的方式松耦合的綁定在一起：即事件發送者不關注誰來消費事件，事件消費者也不關注事件是由誰產生的。Eventing 中有多種事件組合的方式，比如：
-
最簡單的 Source -> Service 直接綁定
-
通過 channel 與 subscriptions 訂閱的方式
-
并行事件流處理 的方式 Parallel，以及串行事件流處理的方式 Sequence
-
以及支持事件過濾的 Broker & Trigger 也是本文將要重點介紹的模式
?注：對于其他幾種事件組合的方式，感興趣的可以在官網查閱 https://knative.dev/docs/eventing/
2. 工作原理介紹
上圖展示的是 Broker & Trigger 模型的中 Event 傳遞的基本方式，其中事件傳遞的格式是標準的 CLoudEvent 的格式。簡要介紹下圖中的流程：
事件由事件源 Source 產生, Knative 支持多種事件源,如 GitHub、Heartbeats、k8s、ContainerSource等，更多 Source 可在官網查閱 https://knative.dev/docs/eventing/sources/，也可以自定義 Source ,參考之前發的一篇公眾號為 Serverless 平臺插上騰飛的翅膀--自定義 Faas 事件驅動事件源。
圖中 事件源產生 type 為 foo 的事件，發送到 Broker，其中 有三個 Trigger 綁定了 Broker，兩個 Trigger 的 filter 是 type:foo ,也就是會關注 type=foo 的事件，然后發送給對應的消費者。
Service1和 Service3 只是單純的消費，并不回復事件
Service2 收到事件后回復 type=bar 的事件,事件重新傳遞到 Broker上，此時只有一個 Trigger 過濾了 type:bar 事件被傳送到 Service3 消費。
其中消費者是否回復事件是可選的。
關于圖中的實例 yaml，可參考附錄章節
3. 底層實現原理
上面介紹了 Broker & Trigger 的工作原理，現在從底層實現的角度進一步講解。
Knative Eventing 事件傳遞過程中依賴消息通道 Channel，為了便于持久化，生產環境使用可持久化的消息通過( 本文以 NatsStreaming 為例) 來做事件的消息通道，如果是開發調試，則直接用 InMemoryChannel 即可(只會保存在內存中，不會持久化)
先上圖
-
圖中包含控制平面與數據平面，圖中箭頭：控制平面為實線，數據平面為虛線
-
實線的方框為 Knative 組件，虛線的方框為 k8s CR 資源
下面分別從數據平面和控制平面分別講解
3.1 數據平面
EventSource------> Broker------>Trigger------->SubScriber
1. EventSource------> Broker
Broker 可以手動生成，或者通過給 namespace 打 label eventing.knative.dev/injection:true ，讓sugar-controller 會自動生成對應的 Broker 實例
EventSource 一般通過 SinkURI 環境變量將 Broker 的 地址傳入 。比如，Broker 的地址為 http://broker-ingress.knative-eventing.svc.cluster.local/default/default，該地址為broker-ingress 的地址，而 broker-ingress通過 請求 URL的 path 可以得到 Broker 的信息，比如/default/default表示 default namespace 下名為 default 的 Broker
#?kubectl?get?broker NAME??????URL????????????????????????????????????????????????????????????????????????AGE???READY???REASON default???http://broker-ingress.knative-eventing.svc.cluster.local/default/default???46h???True2.Broker------>Trigger
broker-ingress ****得到 Broker 的信息(name namespace)之后,可以得到 Broker 的 status 信息,如下得到 channelAddress 的地址(http://default-kne-trigger-kn-channel.default.svc.cluster.local)
apiVersion:?eventing.knative.dev/v1 kind:?Broker metadata:name:?defaultnamespace:?default status:address:url:?http://broker-ingress.knative-eventing.svc.cluster.local/default/defaultannotations:knative.dev/channelAPIVersion:?messaging.knative.dev/v1beta1knative.dev/channelAddress:?http://default-kne-trigger-kn-channel.default.svc.cluster.localknative.dev/channelKind:?NatssChannelknative.dev/channelName:?default-kne-triggerchannelAddress 的地址是個svc 的地址,通過 externalName 指向 natss-ch-dispatcher
#?kubectl?get?svc?default-kne-trigger-kn-channel NAME?????????????????????????????TYPE???????????CLUSTER-IP???EXTERNAL-IP??????????????????????????????????????????????PORT(S)???AGE default-kne-trigger-kn-channel???ExternalName???<none>???????natss-ch-dispatcher.knative-eventing.svc.cluster.local???<none>????46hnatss-ch-dispatcher 負責將 消息（主題為channel.Name + "." + channel.Namespace） 發布到 Natss-Streaming 組件
3. Trigger------->SubScriber
natss-ch-dispatcher ****不僅負責發布，還負責訂閱消息，natss-ch-dispatcher ****watch natssChannel (見下面的 NatssChannel), 獲取 natssChannel的 subscriber的地址 subscriberUri，通過 subscriberUri發送消息給 broker-filter ,跟 broker-ingress 一樣，subscriberUri 的地址是broker-filter 的 地址，通過請求 path 區分哪個 trigger ,請求 path :/triggers/<trigger namespace>/<trigger name>/<trigger UID>
apiVersion:?messaging.knative.dev/v1beta1 kind:?NatssChannel metadata:name:?default-kne-triggernamespace:?default spec:subscribers:-?generation:?1replyUri:?http://broker-ingress.knative-eventing.svc.cluster.local/default/defaultsubscriberUri:?http://broker-filter.knative-eventing.svc.cluster.local/triggers/default/trigger2/c0f3f1bb-9a25-4fb2-b803-fc5cd74e57dauid:?9b4c991a-8912-4333-aa5a-caf053e5ee9c-?generation:?1replyUri:?http://broker-ingress.knative-eventing.svc.cluster.local/default/defaultsubscriberUri:?http://broker-filter.knative-eventing.svc.cluster.local/triggers/default/trigger3/28e7ba73-d514-4aea-a0de-7946fc21e7ccuid:?56d00260-e69f-4d7a-bd05-c81479774a95-?generation:?1replyUri:?http://broker-ingress.knative-eventing.svc.cluster.local/default/defaultsubscriberUri:?http://broker-filter.knative-eventing.svc.cluster.local/triggers/default/trigger1/3f6e7a8e-f7d1-4c8f-a25a-1970b6ab73e3uid:?963fd671-097f-489a-a857-c1803ad3fb19 status:address:url:?http://default-kne-trigger-kn-channel.default.svc.cluster.localbroker-filter 獲取到 Trigger 的信息后,通過 根據 Trigger 的filter 將消息過濾，再決定是否將消息發給 對應的 subscriber, subscriber可以從 Trigger status 的 subcriberUri 獲取到，見下圖,對于subscriber Reply 的消息，broker-filter 發送到 replyUri 地址上，http://broker-ingress.knative-eventing.svc.cluster.local/default/default ,也就是發送給 Broker (實際是 broker-ingress)。
apiVersion:?eventing.knative.dev/v1 kind:?Trigger metadata:name:?trigger1namespace:?default spec:broker:?defaultfilter:attributes:type:?dev.knative.sources.pingsubscriber:ref:apiVersion:?serving.knative.dev/v1kind:?Servicename:?service1namespace:?default status:subscriberUri:?http://service1.default.svc.cluster.local至此數據面的通信流就完成了，接下來看控制面的數據流。
3.2 控制平面
控制平面主要看上圖中的實線部分，此處再貼一下圖
接下來按流程講解
-
1.1 mt-broker-controller watch Broker 的創建
-
1.2 mt-broker-controller 根據 Broker 的配置，創建對應的 Channel，此處為 NatssChannel
-
1.3 Natss-ch-controller watch NatssChannel 的創建，更新 Natss-Streaming 的服務端狀態到NatssChannel 的 status
-
1.4 Natss-ch-controller創建 svc，externalname指向 natss-ch-dispatcher
-
1.5 mt-broker-controllerwatch NatssChannel 的status
-
1.6 mt-broker-controller 更新 Broker 的status，其中包含: Broker 的address（broker-ingress 的地址）,channel 的 address,供 broker-ingress 使用
-
2.1 mt-broker-controllerwatch Trigger
-
2.2 mt-broker-controller根據 Trigger（含 subscriber 的信息）創建subscription,其中包含 subsciber(broker-filter) 的地址和 Broker 的信息
-
2.3 eventing-controller watch subscription ,解析 subcriber和 replyUri的地址(broker-ingress 的地址)
-
2.4 eventing-controller根據subcription 更新 Natss-Channel :subsriberUrl 和 replyUrl
2.5 mt-broker-controller 根據 subscription 和 broker 的狀態 更新 Trigger 的狀態
控制面的邏輯就完了，和數據面的邏輯結合的地方在于：
broker-ingress 和 broker-filter ：
broker-ingress watch Broker ,從 Broker 的 status 中獲取 channel 的地址(natss-ch-dispatch 的 svc 的地址)
broker-filter watch Trigger ，根據 trigger 中subscriber 地址，將event filter 后決定是否發送到 對應的 target
至此，整個流程都講完了，可以按照附錄中的資源，創建一下，看看其中的資源。
附錄
broker.yaml
trigger1.yaml
trigger2.yaml
trigger3.yaml
service1.yaml
5.service3.yaml (service1和service3 一樣都是打印接收到的 event)
apiVersion:?serving.knative.dev/v1 kind:?Service metadata:name:?service1 spec:template:spec:containers:-?image:?docker.io/zhaojizhuang66/event-display:v1service2.yaml
關注公眾號： Knative，了解更多 Serverless 、Knative，云原生相關資訊
關注公眾號，回復 "進群"，即可進群與眾多云原生 Serverless 技術大佬探討技術，探討人生。
總結
以上是生活随笔為你收集整理的【图解 Knative】剖析 Eventing Broker-Trigger 实现原理的全部內容，希望文章能夠幫你解決所遇到的問題。
