0


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

序言

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

今天整理了一下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.投票


本文转载自: https://blog.csdn.net/weixin_36755535/article/details/128068493
版权归原作者 颜淡慕潇 所有, 如有侵权,请联系我们删除。

“【云原生系列】第四讲:Knative 之 Eventing”的评论:

还没有评论