4. 事件驱动架构基础：事件源、事件通道、事件订阅、事件流处理模式

事件驱动架构（Event-Driven Architecture, EDA）是 Knative 与 KEDA 实现弹性伸缩与异步解耦的底层通信模型。理解 EDA 的四个核心构件——事件源、事件通道、事件订阅、事件流处理模式——是后续进行容量规划的前提。本节从概念、职责与协作关系三个维度展开。

4.1 核心构件总览

4.2 事件源（Event Source）

事件源是 EDA 的起点。在 Knative 生态中，事件源通过 ApiServerSource、PingSource、KafkaSource 等 CRD 声明式接入。KEDA 则通过 ScaledObject 的 triggers 字段直接绑定外部源。

• 外部源： Kafka、RabbitMQ、AWS SQS/SNS、Azure Event Hub、Prometheus 指标、自定义 HTTP 端点。
• 内部源： Kubernetes 事件（Pod 状态变化）、Knative Service 自身产生的 CloudEvent。
• 关键指标： 事件产生速率（events/sec）、事件大小分布（bytes/event）、突发系数（peak / average）。

# KEDA ScaledObject 绑定 Kafka 事件源示例
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-consumer-scaler
spec:
  scaleTargetRef:
    name: event-processor
  triggers:
  - type: kafka
    metadata:
      bootstrapServers: kafka-cluster:9092
      consumerGroup: consumer-group-1
      topic: orders
      lagThreshold: "100"       # 积压阈值，触发扩容
      activationLagThreshold: "10"  # 缩容回退阈值

4.3 事件通道（Event Channel）

事件通道承担事件的中转与缓冲职责。Knative 提供多种 Channel 实现，KEDA 则依赖消息中间件自身的队列/主题作为通道。

4.4 事件订阅（Event Subscription）

订阅将事件通道与 Knative Service 或 KEDA 目标工作负载绑定。Knative 使用 Subscription CRD 建立从 Channel 到 Service 的转发规则；KEDA 通过 ScaledObject 的 triggers 隐式定义订阅关系。

# Knative Subscription 示例
apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
  name: order-subscription
spec:
  channel:
    apiVersion: messaging.knative.dev/v1
    kind: KafkaChannel
    name: orders-channel
  subscriber:
    uri: http://order-processor.default.svc.cluster.local
  reply:
    uri: http://audit-log.default.svc.cluster.local

• 订阅粒度： 一个通道可被多个订阅消费（扇出）；一个订阅可绑定多个通道（合并）。
• 背压机制： Knative 通过 Subscription 的 delivery 字段配置重试、死信队列与背压策略。
• 容量关联： 订阅的并发数（concurrency）与 KEDA 的 maxReplicaCount 共同决定最大处理能力。

4.5 事件流处理模式

事件流处理模式定义了事件从源到消费者的拓扑结构。Knative 与 KEDA 原生支持以下三种模式：

1. 点对点（Point-to-Point）： 一个事件被一个消费者处理。适用于任务队列、订单处理。KEDA 的 Kafka Scaler 默认行为。
2. 发布-订阅（Pub/Sub）： 一个事件被多个消费者独立处理。适用于审计、通知、分析。Knative Broker/Trigger 实现。
3. 事件溯源（Event Sourcing）： 事件作为唯一事实源，状态由事件重放计算。适用于复杂状态重建、审计追踪。KEDA 结合 Kafka 的 offset 管理实现。

4.6 事件驱动架构协作流程（SVG）

下图展示了事件源、通道、订阅与处理模式在 Knative/KEDA 环境下的完整协作流程：

4.7 事件流处理模式对比（SVG）

三种事件流处理模式在拓扑结构、扩缩容行为与容量规划策略上存在显著差异：

4.8 实践要点与容量规划关联

• 事件源速率建模： 使用 Prometheus 监控事件产生速率，建立基线（P50/P95/P99），作为 KEDA ScaledObject 的 cooldownPeriod 与 pollingInterval 配置依据。
• 通道积压预警： 设置 KafkaChannel 的 maxBufferSize 与 KEDA 的 lagThreshold 联动，避免积压超过通道容量导致事件丢失。
• 订阅并发控制： Knative Service 的 containerConcurrency 与 KEDA 的 maxReplicaCount 乘积应大于等于事件源峰值速率除以单实例处理时间。
• 模式选择影响： 点对点模式适合线性扩缩容；发布-订阅模式需要为每个订阅者独立规划；事件溯源模式需要预留重放计算资源。