2. 核心概念：Event、Source、Sink、Trigger、Channel、Broker 的定义与关系
在 Serverless Eventing 体系中，理解核心概念是进行版本差异校验的前提。本章将逐一拆解 Event（事件）、Source（事件源）、Sink（事件接收端）、Trigger（触发器）、Channel（通道） 与 Broker（代理） 的定义，并阐明它们之间的协作关系。
2.1 核心概念定义
| 概念 | 英文 | 定义 | 类比 |
|---|---|---|---|
| 事件 | Event | 描述“发生了什么”的数据记录，包含上下文（Context）与数据（Data）。遵循 CloudEvents 规范。 | 信封（上下文）+ 信件（数据） |
| 事件源 | Source | 产生事件的实体。可以是服务、应用、设备或定时器。 | 发件人 |
| 事件接收端 | Sink | 消费或处理事件的最终目标。通常是函数、服务或外部系统。 | 收件人 |
| 触发器 | Trigger | 定义事件过滤规则（如事件类型、来源）并将匹配的事件转发给特定 Sink 的规则对象。 | 邮递员 + 筛选规则 |
| 通道 | Channel | 一种轻量级的事件缓冲与路由中间件，支持事件持久化、重试与多订阅者。 | 临时邮箱 |
| 代理 | Broker | 一个完整的事件网格节点，提供事件接收、过滤、路由、重试与死信队列等高级能力。 | 邮政总局 |
版本差异校验提示： 不同 Serverless 平台（如 Knative、OpenFunction、AWS Lambda）对 Broker 和 Channel 的实现细节存在差异，尤其在事件持久化策略和重试语义上。这是后续章节校验的重点。
2.2 概念关系：事件流转模型
下图展示了从事件产生到被消费的完整流转路径，以及各核心概念在其中的位置与关系。
2.3 概念对比：Channel vs Broker
Channel 和 Broker 是 Eventing 中容易混淆的两个概念。下表从多个维度进行对比，帮助理解它们在版本差异校验中的不同角色。
| 对比维度 | Channel（通道） | Broker（代理） |
|---|---|---|
| 定位 | 轻量级事件中间件 | 完整的事件网格节点 |
| 事件持久化 | 可选，依赖实现（如 InMemoryChannel 无持久化） | 默认支持持久化，通常基于 Kafka、RabbitMQ 等后端 |
| 过滤能力 | 无内置过滤，需配合 Subscription 实现 | 内置 Trigger 过滤机制，支持按类型、来源等属性过滤 |
| 重试机制 | 依赖 Subscription 配置 | 内置重试策略，支持指数退避和死信队列 |
| 版本差异校验点 | 不同实现（InMemory、Kafka、NATS）的语义差异 | Broker 配置（如事件 TTL、重试次数）的版本兼容性 |
2.4 事件流转流程（步骤列表）
一个典型的事件从产生到被消费，经历以下步骤：
- 事件产生： Source 检测到状态变化或外部触发，构建符合 CloudEvents 规范的 Event 对象。
- 事件发送： Source 将 Event 发送到指定的 Broker 或 Channel。
- 事件缓冲： Broker 内部的 Channel 接收事件，进行持久化存储（如写入 Kafka 主题）。
- 事件过滤： Trigger 从 Broker 拉取事件，根据配置的过滤规则（如
type: "order.created"）进行匹配。 - 事件转发： 匹配成功的事件被 Trigger 转发给绑定的 Sink（如一个 Knative Service 或函数）。
- 事件消费： Sink 处理事件数据，执行业务逻辑，并可能产生新的事件回写到 Eventing 系统。
版本差异校验关键点： 在步骤 3（事件缓冲）和步骤 4（事件过滤）中，不同版本的 Broker 实现可能在事件持久化策略、过滤语法和重试行为上存在差异。例如，Knative Eventing v0.25 之前使用 Subscription 进行过滤，而 v0.26 之后推荐使用 Trigger。这些差异直接影响容量规划与系统兼容性。
2.5 概念关系总结
下图以更简洁的方式总结了六个核心概念之间的依赖与协作关系，适合作为快速参考。