事件网格¶

事件网格是旨在简化事件从发送方到接收方的分发的动态基础设施。与 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 匹配可寻址事件目标的定义，因此可以将事件从一个集群中的代理中继到另一个集群中的代理。类似地，Trigger 使用与许多源相同的 Deliverable 鸭子类型，因此可以轻松地用事件网格代替事件的直接传递。
事件出口：Deliverable 合约支持指定一个裸 URL 或引用一个实现可寻址接口的 Kubernetes 对象（具有 status.address.url）作为目的地。所有事件目的地（“接收器”）必须实现 CloudEvents 传递规范，但并不一定需要实现任何 Kubernetes 行为 - 由 URL 引用的裸 VM 是一个可接受的事件出口。

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