目录
编辑 3.2Channels & Subscriptions
序言
三言两语，不如细心探索。
今天整理了一下Eventing相关知识点，希望此文，能帮助读者对Knative Eventing 有一个初步的了解
文章标记颜色说明：
- 黄色：重要标题
- 红色：用来标记结论
- 绿色：用来标记一级论点
- 蓝色：用来标记二级论点
1.基础介绍
Kubernetes 用户在实现开发和部署阶段服务之间松耦合的同时，服务间常要通过不同的事件机制来进行事件传递，为了解决大部分的云原生消息通信需求，Knative 提供了 Eventing 组件。
特点：
- 服务开发部署松耦合
- 支持各种事件传递
- 事件的生产者和事件的消费者是相互独立的
确保跨服务的互操作性
支持第三方的服务对接 Eventing 系统
2.组成要素
Eventing 主要由
- 事件源（Event Source）
- 事件处理（Flow）
- 事件消费者（Event Consumer）
三部分构成。
2.1 事件源（Event Source）
Source 是事件的来源，它是定义事件在何处生成以及如何将事件传递给关注对象的方式
- 事件生成
- 事件传递
目前支持以下8种事件源：
ApiserverSource：每次创建或更新 Kubernetes 资源时，ApiserverSource 都会触发一个新事件
GitHubSource：GitHub 操作时，GitHubSource 会触发一个新事件
GcpPubSubSource： GCP 云平台 Pub/Sub 服务会触发一个新事件
AwsSqsSource：Aws 云平台 SQS 服务会触发一个新事件
ContainerSource: ContainerSource 将实例化一个容器，通过该容器产生事件
CronJobSource: 通过 CronJob 产生事件
KafkaSource: 接收 Kafka 事件并触发一个新事件
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.架构模式
架构模式有三种：
- Source to Service
- Channels & Subscriptions
- 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提供了两个附加资源：
后面会写一篇文章，专门来讲有序列表和分支列表
4.总结
Knative 使用 Build 提供云原生“从源代码到容器”的镜像构建能力，通过 Serving 部署容器并提供通用的服务模型，同时以 Eventing 提供事件全局订阅、传递和管理能力，实现事件驱动。这就是 Knative 呈现给我们的标准 Serverless 编排框架
- Build 镜像构建
- Serving 容器部署
- Eventing 事件全局订阅、传递、管理