事件網格¶

事件網格是一種動態基礎架構，旨在簡化將事件從傳送者分發到接收者的過程。與 Apache Kafka 或 RabbitMQ 等傳統的訊息通道架構類似，事件網格提供訊息的非同步（儲存和轉發）傳遞，從而允許在時間上分離傳送者和接收者。與傳統的訊息通道整合模式不同，事件網格還通過將傳送者和接收者與底層事件傳輸基礎架構（可能是 Kafka、RabbitMQ 或雲端供應商基礎架構等聯合解決方案）分離來簡化傳送者和接收者的路由問題。網格透過跨任何環境甚至雲端之間的互連事件代理網絡，以無縫且鬆散耦合的方式將事件從生產者傳輸到消費者。

在事件網格中，生產和消費應用程式都不需要實作事件路由或訂閱管理。事件生產者可以將所有事件發佈到網格，網格可以將事件路由到感興趣的訂閱者，而無需應用程式將事件細分為通道。事件消費者可以使用網格配置，透過細粒度的篩選表達式來接收感興趣的事件，而無需實作多個訂閱和應用程式級別的事件篩選來選擇感興趣的事件。事件序列化和反序列化可以由語言原生庫處理，而無需實作較為繁重的路由和篩選。

Knative 事件網格¶

上述提及的事件代理直接對應到 Knative 事件中的核心 API：Broker API 提供事件輸入的可探索端點，而 Trigger API 則通過其事件篩選和傳遞功能完善了產品。通過這些 API，Knative 事件提供了如上定義的事件網格

Raw Trace

如上圖所示，事件網格是使用 Broker 和 Trigger API 來定義事件的輸入和輸出。Knative 事件允許多個資源透過稱為「鴨子類型」的部分模式參與事件網格。鴨子類型允許多種類型的資源宣告通用功能，例如「可以在 URL 接收事件」或「可以將事件傳遞到目的地」。Knative 事件使用這些功能來提供可互操作的來源池，用於將事件發送到 Broker 和作為 Trigger 路由事件的目的地。Knative 事件 API 包含三個類別的 API

事件輸入：支援連接事件傳送者：來源鴨子類型和 SinkBinding，以支援輕鬆配置應用程式將事件傳遞到 Broker。應用程式可以提交事件並使用事件，即使沒有安裝任何來源。
事件路由：Broker 和 Trigger 物件支援定義網格和事件路由。請注意，Broker 符合可尋址事件目的地的定義，因此可以將一個叢集中的 Broker 的事件轉發到另一個叢集中的 Broker。同樣，Trigger 使用與許多來源相同的可交付鴨子類型，因此很容易用事件網格替代直接傳遞事件。
事件輸出：可交付合約支援指定裸 URL 或參考實作可尋址介面（具有 status.address.url）的 Kubernetes 物件作為目的地。所有事件目的地（「接收器」）都必須實作 CloudEvents 傳遞規範，但不一定需要實作任何 Kubernetes 行為 - 以 URL 參考的裸 VM 是一個可接受的事件輸出。

重要的是要注意，事件來源和接收器是事件生態系統的支援元件，但不是事件網格的直接組成部分。雖然不是事件網格的一部分，但這些生態系統元件補充了網格，並受益於鴨子類型 API (Callable/Addressable)，以便與「事件網格」順利整合或連接。