3. Knative Eventing架构深度解析

Knative Eventing 的核心价值在于把“事件从哪里来、经过谁、最终送到哪里”这件事标准化。它并不要求生产者知道消费者的存在，而是通过一组可组合的抽象对象完成解耦。理解这些对象的关键，不是记住它们的名字，而是看清它们在事件路径上分别承担什么职责、彼此如何引用，以及在什么生产场景下应该选谁。

四类核心对象的分工

Broker 是事件的入口与分发中枢。生产者只需把事件 POST 到 Broker 的地址，Broker 内部会为每个事件建立可被过滤的通道，并根据 Trigger 的订阅关系决定投递目标。它适合“多生产者、多消费者、按属性路由”的场景，例如一个订单系统同时产生创建、支付、发货事件，不同团队各自只关心其中一部分。

Trigger 是 Broker 上的过滤与订阅规则。它由 filter（基于 CloudEvents 属性匹配）和 subscriber（投递目标）组成。一个 Broker 可以挂多个 Trigger，每个 Trigger 只把满足条件的事件投给对应消费者。Trigger 是“声明式路由”，不需要生产者做任何判断。

Channel 是事件的持久化缓冲与传递层。它不负责复杂过滤，而是保证事件在生产者与消费者之间可靠传递，支持内存、Kafka、NATS 等不同实现。Channel 适合“点对点或一对多、需要缓冲与重试”的场景，例如把日志事件先写入 Kafka Channel，再由多个消费者按各自节奏读取。

Subscription 是 Channel 与消费者之间的绑定关系。它把 Channel 中的事件投递给一个 subscriber，并可配置回复、死信等策略。Subscription 与 Trigger 的区别在于：Trigger 面向 Broker 的过滤路由，Subscription 面向 Channel 的订阅投递。

Broker 与 Trigger 的协作机制

当生产者向 Broker 发送一个 CloudEvent 时，Broker 会读取事件头中的 type、source、subject 等属性，并与所有 Trigger 的 filter 逐一比对。只有 filter 完全匹配的 Trigger 才会收到该事件。例如，一个订单创建事件 type=order.created 只会命中 filter 为 type=order.created 的 Trigger，而不会命中 type=payment.done 的 Trigger。这种基于属性的过滤是声明式的，生产者不需要在代码里写任何 if-else 路由逻辑。

Trigger 的 subscriber 可以指向 Knative Service、Kubernetes Service，也可以指向另一个 Channel。当 subscriber 返回 2xx 时，Broker 认为投递成功；返回非 2xx 或超时，则按配置进行重试。生产环境中，建议为每个 Trigger 配置独立的死信队列（Dead Letter Sink），避免失败事件无限重试拖垮消费者。

Channel 与 Subscription 的可靠传递

Channel 的核心职责是“先接住，再传递”。它把生产者与消费者在时间上解耦：生产者发送完即可返回，消费者可以按自己的节奏消费。Channel 的实现决定了可靠性等级：InMemoryChannel 仅适合开发测试，Pod 重启会丢事件；KafkaChannel 提供持久化、分区和副本，适合生产环境；NATSChannel 则在轻量级和吞吐之间取得平衡。

Subscription 把 Channel 与消费者绑定，并支持 reply 字段实现请求-响应模式。例如，一个校验服务消费事件后，可以把结果通过 reply 发回另一个 Channel，形成事件链。生产环境中，Subscription 同样需要配置重试策略和死信目标，并且要关注消费者的处理幂等性，因为重试可能导致同一事件被多次投递。

生产适用场景与选型建议

Broker/Trigger 更适合“事件路由”场景：多个团队各自订阅自己关心的事件类型，生产者只发一次，Broker 负责分发。典型例子是电商平台，订单服务发出 order.created，库存服务、积分服务、通知服务各自通过 Trigger 订阅，互不干扰。

Channel/Subscription 更适合“可靠管道”场景：事件需要持久化、缓冲、重试，或者需要一对多广播。典型例子是日志采集，应用把日志事件写入 KafkaChannel，日志分析服务和告警服务各自通过 Subscription 消费，分析服务可以批量慢速处理，告警服务则实时快速响应。

一个可参考的配置示例

下面是一个 Broker 与 Trigger 的 YAML 片段，用于把 order.created 事件路由到订单处理服务，并配置死信队列：

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: order-broker
  namespace: production
---
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: order-created-trigger
  namespace: production
spec:
  broker: order-broker
  filter:
    attributes:
      type: order.created
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: order-processor
  delivery:
    retry: 5
    backoffPolicy: exponential
    backoffDelay: PT1S
    deadLetterSink:
      ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: order-dlq

这段配置的含义是：事件进入 order-broker 后，只有 type=order.created 的事件会被投递给 order-processor；如果投递失败，最多重试 5 次，采用指数退避，首次延迟 1 秒；仍然失败则写入 order-dlq 死信服务。生产环境中，死信服务应该记录失败事件的完整内容、失败原因和时间戳，便于后续人工排查或补偿。

可靠性治理的关键观察点

无论选择哪条主线，生产环境都需要关注几个共同指标：事件投递成功率、重试次数分布、死信队列积压量、消费者处理延迟。Knative Eventing 会为这些指标暴露 Prometheus 格式的 metrics，例如 event_delivery_attempts、event_delivery_failures。当死信队列持续增长时，通常意味着消费者逻辑存在 bug、下游依赖不可用，或者 filter 配置过宽导致大量无关事件涌入。

另一个容易被忽视的点是事件顺序。Broker/Trigger 默认不保证全局有序，Channel 的分区可以保证同一分区内有序。如果业务对顺序敏感，例如支付状态变更，应该把同一订单的事件路由到同一分区，并在消费者侧做幂等和顺序校验。生产实践中，建议把“事件类型 + 业务主键”作为分区键，而不是简单轮询。

最后，Trigger 和 Subscription 的数量不宜过多。每个 Trigger 都会增加 Broker 的匹配开销，每个 Subscription 都会增加 Channel 的投递扇出。建议按业务域划分 Broker，按事件类型划分 Trigger，按消费者职责划分 Subscription，避免一个 Broker 承载上百个 Trigger 导致路由性能下降。