事件网格¶

事件网格是一种动态的、互联的基础设施，旨在简化事件从发送方到接收方的分发。类似于传统的基于消息通道的架构，如 Apache Kafka 或 RabbitMQ，事件网格提供异步（存储转发）的消息传递，从而允许发送方和接收方在时间上解耦。与传统的基于消息通道的集成模式不同，事件网格还通过将发送方和接收方与底层事件传输基础设施（可以是像 Kafka、RabbitMQ 或云提供商基础设施等解决方案的联合集）解耦，从而简化了发送方和接收方的路由问题。该网格通过一个由互连的事件代理组成的网络，跨任何环境，甚至在云之间，以无缝和松散耦合的方式将事件从生产者传输到消费者。

在事件网格中，生产和消费应用程序都不需要实现事件路由或订阅管理。事件生产者可以将所有事件发布到网格中，网格可以将事件路由到感兴趣的订阅者，而无需应用程序将事件细分到通道中。事件消费者可以使用网格配置，通过细粒度过滤表达式接收感兴趣的事件，而无需实现多个订阅和应用程序级事件过滤来选择感兴趣的事件。事件序列化和反序列化可以由语言原生库处理，而无需实现更繁重的路由和过滤。

Knative 事件网格¶

上述的事件代理直接映射到 Knative Eventing 中的一个核心 API：Broker API 提供了一个可发现的事件入口端点，而 Trigger API 则通过其事件过滤和传递能力完善了这一功能。通过这些 API，Knative Eventing 提供了如上所述的事件网格

Raw Trace

如上图所示，事件网格由 Broker 和 Trigger API 定义，用于事件的入口和出口。Knative Eventing 允许多个资源通过一种称为“鸭子类型”的部分模式参与事件网格。鸭子类型允许多种资源类型宣传共同的能力，例如“可以在 URL 接收事件”或“可以将事件传递到目的地”。Knative Eventing 使用这些能力提供一个可互操作的源池用于向 Broker 发送事件，并作为Trigger 路由事件的目的地。Knative Eventing API 包含三类 API

事件入口：支持连接事件发送方：Source 鸭子类型和 SinkBinding，以支持轻松配置应用程序将事件传递到 Broker。应用程序可以提交事件并使用 Eventing，即使没有安装任何源。
事件路由：Broker 和 Trigger 对象支持定义网格和事件路由。请注意，Broker 符合可寻址事件目标的定义，因此可以将一个集群中的 Broker 的事件中继到另一个集群中的 Broker。类似地，Trigger 使用与许多源相同的 Deliverable 鸭子类型，因此很容易用事件网格替换事件的直接传递。
事件出口：Deliverable 契约支持指定裸 URL 或引用实现 Addressable 接口（具有 status.address.url）的 Kubernetes 对象作为目的地。所有事件目的地（“接收器”）都必须实现 CloudEvents 交付规范，但不一定需要实现任何 Kubernetes 行为——通过 URL 引用的裸虚拟机是可接受的事件出口。

重要的是要注意，事件源和接收器是事件生态系统的支持组件，但不是事件网格的直接组成部分。虽然不是事件网格的一部分，但这些生态系统组件补充了网格，并受益于鸭子类型 API (Callable/Addressable)，以便与“事件网格”进行平滑集成或连接。