【云原生系列】第四讲：Knative 之 Eventing

目录

序言

1.基础介绍 

2.组成要素

2.1 事件源（Event Source）

2.2 事件处理（Flow）

2.3 事件消费者（Event Consumer）

3.架构模式

3.1 Source to Service

​编辑 3.2Channels & Subscriptions

3.3 Brokers & Triggers

 3.4 其他

4.总结

5.投票

---

 

序言

三言两语，不如细心探索。

今天整理了一下Eventing相关知识点，希望此文，能帮助读者对Knative Eventing 有一个初步的了解

文章标记颜色说明：

• 黄色：重要标题
• 红色：用来标记结论
• 绿色：用来标记一级论点
• 蓝色：用来标记二级论点

1.基础介绍 

Kubernetes 用户在实现开发和部署阶段服务之间松耦合的同时，服务间常要通过不同的事件机制来进行事件传递，为了解决大部分的云原生消息通信需求，Knative 提供了 Eventing 组件。

特点：

1. 服务开发部署松耦合
2. 支持各种事件传递
3. 事件的生产者和事件的消费者是相互独立的

4. 确保跨服务的互操作性

5. 支持第三方的服务对接 Eventing 系统

2.组成要素

Eventing 主要由

1. 事件源（Event Source）
2. 事件处理（Flow）
3. 事件消费者（Event Consumer）

三部分构成。

2.1 事件源（Event Source）

Source 是事件的来源，它是定义事件在何处生成以及如何将事件传递给关注对象的方式 

• 事件生成
• 事件传递

目前支持以下8种事件源： 

1. ApiserverSource：每次创建或更新 Kubernetes 资源时，ApiserverSource 都会触发一个新事件

2. GitHubSource：GitHub 操作时，GitHubSource 会触发一个新事件

3. GcpPubSubSource： GCP 云平台 Pub/Sub 服务会触发一个新事件

4. AwsSqsSource：Aws 云平台 SQS 服务会触发一个新事件

5. ContainerSource: ContainerSource 将实例化一个容器，通过该容器产生事件

6. CronJobSource: 通过 CronJob 产生事件

7. KafkaSource: 接收 Kafka 事件并触发一个新事件

8. CamelSource: 接收 Camel 相关组件事件并触发一个新事件

2.2 事件处理（Flow）

前 Knative 支持如下事件接收处理：

• 接收：直接事件接收

  通过事件源直接转发到单一事件消费者。支持直接调用 Knative Service 或者 Kubernetes Service 进行消费处理。这样的场景下，如果调用的服务不可用，事件源负责重试机制处理

• 转发：通过事件通道(Channel)以及事件订阅(Subscriptions)转发事件处理

  这样的情况下，可以通过 Channel 保证事件不丢失并进行缓冲处理，通过 Subscriptions 订阅事件以满足多个消费端处理

• 过滤：通过 brokers 和 triggers 支持事件消费及过滤机制

2.3 事件消费者（Event Consumer）

为了满足将事件发送到不同类型的服务进行消费， Knative Eventing 通过多个 k8s 资源定义了两个通用的接口：

• Addressable 接口：提供可用于事件接收和发送的 HTTP 请求地址，并通过status.address.hostname字段定义。作为一种特殊情况，Kubernetes Service 对象也可以实现 Addressable 接口
• Callable 接口：接收通过 HTTP 传递的事件并转换事件。可以按照处理来自外部事件源事件的相同方式，对这些返回的事件做进一步处理

目前 Knative 支持通过 Knative Service 或者 Kubernetes Service 进行消费事件。

另外针对事件消费者，如何事先知道哪些事件可以被消费？ 

将事件源发送到通道，并准备好处理它们的服务，但目前没有办法获取从通道发送到服务的事件。为此，Knative设计了订阅功能。订阅是通道和服务之间的纽带，指示Knative如何在整个系统中管理事件，如下图

总结：

Knative中的服务不关心事件和请求是如何获取的。

• 可以获取来自入口网关的HTTP请求
• 可以获取从通道发送来的事件

无论通过何种方式获取，服务仅接收HTTP请求。

这是Knative中一个重要的解耦方式。

它确保将代码编写到架构中，而不是在底层创建订阅、通道向服务发送事件。 

3.架构模式

架构模式有三种：

1. Source to Service
2. Channels & Subscriptions
3. Brokers & Triggers

3.1 Source to Service

从源直接传递到单个服务（可寻址端点，包括Knative服务或核心Kubernetes服务）。

在这种情况下，如果目标服务不可用，则源负责重试或排队事件 

 3.2Channels & Subscriptions

通过渠道和订阅，Knative事件系统定义了一个渠道，该渠道可以连接到各种后端（例如内存中，Kafka和GCP PubSub）来sourcing事件。

每个通道可以具有一个或多个以Sink Services形式的订阅用户

如图，该订阅用户可以接收事件消息并根据需要对其进行处理。通道中的每个消息都将格式化为CloudEvent，并在链中进一步发送给其他订阅用户以进行进一步处理。

通道和订阅使用模式无法过滤消息。

3.3 Brokers & Triggers

Broker提供了一系列事件，可以通过属性选择事件。

它接收事件并将其转发给由一个或多个匹配Trigger定义的订阅用户。

Trigger描述了事件属性的过滤器，应将其传递给可寻址对象。

可以根据需要创建任意数量的Trigger。

 

 3.4 其他

更高级别的事件构造：

在某些情况下，可能希望一起使用一组协作功能，对于这些用例，Knative Eventing提供了两个附加资源：

• Sequence 提供一种定义功能的有序列表的方法。
• Parallel 提供了一种定义事件分支列表的方法。

后面会写一篇文章，专门来讲有序列表和分支列表

4.总结

Knative 使用 Build 提供云原生“从源代码到容器”的镜像构建能力，通过 Serving 部署容器并提供通用的服务模型，同时以 Eventing 提供事件全局订阅、传递和管理能力，实现事件驱动。这就是 Knative 呈现给我们的标准 Serverless 编排框架

1. Build 镜像构建
2. Serving 容器部署
3. Eventing 事件全局订阅、传递、管理

5.投票