2. 触发器概念：Trigger 在 Knative Eventing 中的角色

2.1 事件驱动模型与 Trigger 的定位

在 Knative Eventing 控制面架构中，Trigger 是连接事件源与事件消费者的核心路由规则。它定义了“哪些事件应该被发送到哪个服务”，是事件驱动模型中订阅/分发语义的具体实现。

事件驱动模型的基本流程如下：

1. 事件生产者（如 Kafka 主题、S3 存储桶）将事件发送到 Broker。
2. Broker 作为事件网关，接收并暂存所有事件。
3. Trigger 根据过滤规则（事件类型、来源、扩展属性）从 Broker 中筛选匹配的事件。
4. 匹配的事件被转发到 Subscriber（通常是 Knative Service 或 Channel）。

2.2 Trigger 与 Broker 的关系

Trigger 必须绑定到一个 Broker 才能生效。一个 Broker 可以关联多个 Trigger，每个 Trigger 定义不同的过滤条件和目标订阅者。下表总结了二者的职责分工：

2.3 Trigger 的过滤机制

Trigger 支持基于 CloudEvents 属性的精确过滤和前缀匹配。过滤规则定义在 spec.filters 字段中，支持以下属性：

• type：事件类型，如 com.example.order.created
• source：事件来源，如 /apis/v1/namespaces/default
• subject：事件主体，如 order-12345
• extensionattributes：自定义扩展属性，如 env: production

过滤规则使用 AND 逻辑：所有指定的过滤条件必须同时满足，事件才会被路由到 Subscriber。如果未指定任何过滤器，Trigger 将接收该 Broker 中的所有事件。

2.4 Trigger 控制面架构图

下图展示了 Trigger 在 Knative Eventing 控制面中的完整数据流与组件关系：

2.5 Trigger 的声明式配置

以下是一个完整的 Trigger YAML 示例，展示了如何将特定事件路由到 Knative Service：

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: order-created-trigger
  namespace: default
spec:
  broker: default
  filter:
    attributes:
      type: com.example.order.created
      source: /apis/v1/namespaces/default
      extensionattributes:
        env: staging
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: order-processor
    uri: /v1/events

2.6 Trigger 状态与生命周期

Trigger 的状态反映了其与 Broker、Subscriber 的绑定情况。通过 kubectl get trigger 可以查看当前状态：

2.7 工程案例：多环境事件路由

在实际控制面架构中，Trigger 常用于实现环境隔离和灰度发布。以下是一个典型的多环境路由策略：

• 生产环境 Broker：接收所有生产事件，通过 Trigger 路由到生产服务。
• 预发环境 Broker：接收部分生产事件（通过 env: staging 过滤），路由到预发服务进行验证。
• 测试环境 Broker：接收模拟事件，路由到测试服务。