目录
编辑 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 事件全局订阅、传递、管理