专栏首页智能计算时代【无服务器架构】Knative Eventing 介绍

【无服务器架构】Knative Eventing 介绍

Knative Eventing是一个旨在满足云原生开发的常见需求的系统,并提供可组合的原语以启用后期绑定事件源和事件使用者。

设计概述

Knative Eventing是围绕以下目标设计的:

  1. 原始事件服务是松散耦合的。这些服务可以在各种平台上(例如Kubernetes,VM,SaaS或FaaS)独立开发和部署。
  2. 事件生产者和事件消费者是独立的。任何生产者(或源)都可以在有活动的事件使用者监听之前生成事件。在有生产者创建事件之前,任何事件消费者都可以对事件或事件类别表示兴趣。
  3. 可以将其他服务连接到Eventing系统。这些服务可以执行以下功能:创建新的应用程序而无需修改事件生产者或事件使用者。从生产者那里选择事件的特定子集并将其作为目标。
  4. 确保跨服务的互操作性。Knative Eventing与由CNCF Serverless WG开发的CloudEvents规范一致。

事件消费者

为了能够交付到多种类型的服务,Knative Eventing定义了两个通用接口,可以由多个Kubernetes资源实现:

  1. 可寻址对象能够接收和确认通过HTTP发送到其status.address.url字段中定义的地址的事件。作为一种特殊情况,核心的Kubernetes Service对象还实现了Addressable接口。
  2. 可调用对象能够接收通过HTTP传递的事件并转换该事件,从而在HTTP响应中返回0或1个新事件。可以以与处理来自外部事件源的事件相同的方式来进一步处理这些返回的事件。

事件经纪人和触发器

从v0.5开始,Knative Eventing定义了Broker和Trigger对象,使过滤事件更加容易。

代理提供了一系列事件,可以通过属性选择事件。它接收事件并将其转发给由一个或多个匹配触发器定义的订户。

触发器描述了事件属性的过滤器,应将其传递给可寻址对象。您可以根据需要创建任意数量的触发器。

事件注册表

从v0.6开始,Knative Eventing定义了一个EventType对象,以使消费者更容易发现可以从不同的Broker消费的事件类型。

注册表包含事件类型的集合。注册表中存储的事件类型包含(全部)必需的信息,供消费者创建触发器而不使用某些其他带外机制。

若要了解如何使用注册表,请参阅事件注册表文档。

事件频道和订阅

Knative Eventing还定义了事件转发和持久层,称为Channel。每个通道都是一个单独的Kubernetes自定义资源。使用订阅将事件传递到服务或转发到其他渠道(可能是其他类型)。这使群集中的消息传递可以根据需求而变化,因此某些事件可能由内存中的实现处理,而其他事件则可以使用Apache Kafka或NATS Streaming持久化。

请参阅渠道实施清单。

更高级别的事件构造

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

  1. 序列提供了一种定义功能的有序列表的方法。
  2. 并行提供了一种定义事件分支列表的方法。

未来的设计目标

下一个Eventing版本的重点是使事件源的易于实现。源使用Kubernetes Custom Resources管理来自外部系统的事件的注册和传递。在Eventing工作组中了解有关Eventing开发的更多信息。

安装

目前,Knative Eventing要求安装的Istio版本> = 1.0或Gloo版本> = 0.18.16的Knative Serving。按照说明在您选择的平台上进行安装。

架构

事件基础结构目前支持两种形式的事件传递:

  1. 从源直接传递到单个服务(可寻址端点,包括Knative服务或核心Kubernetes服务)。在这种情况下,如果目标服务不可用,则源负责重试或排队事件。
  2. 使用渠道和订阅从源或服务响应向多个端点进行扇出交付。在这种情况下,通道实现可确保将消息传递到请求的目标,并且如果目标服务不可用,则应缓冲事件。

实际的消息转发是由多个数据平面组件实现的,这些组件提供可观察性,持久性以及不同消息传递协议之间的转换。

来源

每个源都是一个单独的Kubernetes自定义资源。这允许每种类型的Source定义实例化Source所需的参数和参数。Knative Eventing在sources.eventing.knative.dev API组中定义了以下Sources。以下类型以golang格式声明,但在YAML中可以表示为简单列表等。所有源都应属于源类别,因此您可以使用kubectl get源列出所有现有源。当前实现的源描述如下。

除了核心资源(如下所述)外,您还可以安装其他资源。

如果您需要可用的Source实现中未涵盖的Source,则提供有关编写自己的Source的教程。

如果您的代码需要将事件作为其业务逻辑的一部分发送,并且不适合源模型,请考虑将事件直接馈送给Broker。

KubernetesEventSource

每当创建或更新Kubernetes事件时,KubernetesEventSource都会触发一个新事件。

规格字段:

  • namespace:string要监视事件的名称空间。
  • serviceAccountname:string用于连接到Kubernetes apiserver的ServiceAccount的名称。
  • sink:ObjectReference对应该接收事件的对象的引用。

请参阅Kubernetes事件源示例。

GitHub源

GitHubSource为选定的GitHub事件类型触发一个新事件。

规格字段:

  • ownerAndRepository:string从中接收事件的GitHub所有者/组织和存储库。该存储库可以保留下来以接收来自整个组织的事件。
  • eventTypes:[]字符串“ Webhook事件名称”格式的事件类型列表(lower_case)。
  • accessToken.secretKeyRef:包含用于配置GitHub Webhook的GitHub访问令牌的SecretKeySelector。必须设置此之一或secretToken。
  • secretToken.secretKeyRef:SecretKeySelector,其中包含用于配置GitHub Webhook的GitHub秘密令牌。必须设置其中之一或accessToken。
  • serviceAccountName:string用来运行容器的ServiceAccount的名称。
  • sink:ObjectReference对应该接收事件的对象的引用。
  • githubAPIURL:字符串可选字段,用于指定API请求的基本URL。如果未指定,则默认为公共GitHub API,但可以将其设置为要与GitHub Enterprise一起使用的域端点,例如https://github.mycompany.com/api/v3/。应始终在该基本URL后面加上斜杠。

参见GitHub Source示例。

GcpPubSubSource

每次在Google Cloud Platform PubSub主题上发布消息时,GcpPubSubSource都会触发一个新事件。

规格字段:

  • googleCloudProject:字符串拥有该主题的GCP项目ID。
  • topic:字符串PubSub主题的名称。
  • serviceAccountName:字符串用于访问gcpCredsSecret的ServiceAccount的名称。
  • gcpCredsSecret:ObjectReference对Secret的引用,其中包含用于与PubSub对话的GCP刷新令牌。
  • sink:ObjectReference对应该接收事件的对象的引用。

请参阅GCP PubSub来源示例。

AwsSqsSource

每次在AWS SQS主题上发布事件时,AwsSqsSource都会触发一个新事件。

规格字段:

  • queueURL:从中提取事件的SQS队列的URL。
  • awsCredsSecret:用于轮询AWS SQS队列的凭证。
  • sink:ObjectReference对应该接收事件的对象的引用。
  • serviceAccountName:字符串用于访问awsCredsSecret的ServiceAccount的名称。

ContainerSource

ContainerSource将实例化一个容器映像,该映像可以生成事件,直到ContainerSource被删除。例如,可以使用它来轮询FTP服务器上的新文件,或在设定的时间间隔内生成事件。

规格字段:

  • image(必填):字符串要运行的容器的docker镜像。
  • args:[] string命令行参数。如果未提供--sink标志,则将添加一个并用接收器对象的DNS地址填充。
  • env:map [string] string要在容器中设置的环境变量。
  • serviceAccountName:string用来运行容器的ServiceAccount的名称。
  • sink:ObjectReference对应该接收事件的对象的引用。

CronJobSource

CronJobSource根据给定的Cron时间表触发事件。

规格字段:

  • schedule(必填):字符串Cron格式的字符串,例如0 * * * *或@hourly。
  • data:字符串发送到下游接收器的可选数据。
  • serviceAccountName:string用来运行容器的ServiceAccount的名称。
  • sink:ObjectReference对应该接收事件的对象的引用。

请参阅Cronjob源示例。

Kafka资

KafkaSource从Apache Kafka集群读取事件,并将事件传递给Knative Serving应用程序,以便可以使用它们。

规格字段:

  • ConsumerGroup:字符串Kafka消费者组的名称。
  • bootstrapServers:字符串用逗号分隔的Kafka Broker主机名:端口对列表。
  • topic:字符串,用于吸收消息的Kafka主题的名称。
  • net:可选的网络配置。
  • sasl:可选的SASL身份验证配置。
  • enable:布尔值如果为true,则使用SASL进行身份验证。
  • user.secretKeyRef:包含要使用的SASL用户名的SecretKeySelector。
  • password.secretKeyRef:包含要使用的SASL密码的SecretKeySelector。
  • tls:可选的TLS配置。
  • enable:布尔值如果为true,则在连接时使用TLS。
  • cert.secretKeyRef:包含要使用的客户端证书的SecretKeySelector。
  • key.secretKeyRef:包含要使用的客户端密钥的SecretKeySelector。
  • caCert.secretKeyRef:包含要验证服务器证书时使用的服务器CA证书的SecretKeySelector。

参见Kafka Source示例。

CamelSource

CamelSource是事件源,可以代表提供用户端并允许将事件发布到可寻址端点的任何现有Apache Camel组件。每个Camel端点都具有URI的形式,其中方案是要使用的组件的ID。

CamelSource要求将Camel-K安装到当前名称空间中。

规格字段:

  • 来源:有关应创建的骆驼来源类型的信息。
  • component:默认类型的源,可通过配置单个Camel组件来创建EventSource。
  • uri:字符串包含应用于将事件推送到目标接收器的骆驼URI。
  • 属性:键/值映射包含Camel全局选项或特定于组件的配置。每个现有的Apache Camel组件的文档中都提供了选项。
  • serviceAccountName:字符串,可用于运行源容器的可选服务帐户。
  • image:字符串(可选)用于源pod的可选基本图像,主要用于开发目的。

参见CamelSource示例

原文:https://knative.dev/docs/eventing/

本文:http://jiagoushi.pro/knative-eventing-introdcution

本文分享自微信公众号 - 智能时刻(intelligentx),作者:南极真君

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-12-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 「微服务架构」微服务架构中的数据一致性

    在微服务中,一个逻辑上原子操作可以经常跨越多个微服务。即使是单片系统也可能使用多个数据库或消息传递解决方案。使用多个独立的数据存储解决方案,如果其中一个分布式流...

    首席架构师智库
  • 「首席看事件流架构」Kafka深挖第4部分:事件流管道的连续交付

    对于事件流应用程序开发人员,根据管道中各个应用程序的更改需要不断更新流管道非常重要。理解流开发人员用于构建事件流管道的一些常见流拓扑也很重要。

    首席架构师智库
  • 「领域驱动设计DDD」事件风暴简介:实现域驱动设计的简便方法

    事件风暴是一种快速,轻量级且未得到充分认可的群体建模技术,它对于加速开发团队而言非常强大,有趣且有用。作为Alberto Brandolini的心血结晶,它是G...

    首席架构师智库
  • C#系列学习笔记之事件

    需要使用winform来实现传入图片的base64值,调用接口,返回结果这样的一个功能。大致的设置如下图:

    算法发
  • [Vue 牛刀小试]:第三章 - 事件修饰符的使用

      熟悉了 Vue 的指令系统后,在实际开发中,不可避免的会使用到对于事件的操作,如何处理 DOM 事件流,成为我们必须要掌握的技能。不同于传统的前端开发,在 ...

    程序员宇说
  • javascript事件流的原理

    事件是用户或浏览器自身执行的某种动作,如click,load和mouseover都是事件的名字。

    前端老鸟
  • 微服务架构下的数据一致性保证(二)

    大家好,今天是第二次在这里给大家分享数据一致性的话题,在第一篇分享中我们介绍了微服务架构下应该满足数据最终一致性原则,并介绍实现最终一致性3种模式。 本文是...

    yuanyi928
  • 如何开发一个简单好用的RxBus

    在Android开发中,事件总线的库往往是开发必备的利器之一,我经历的几个开发项目,都无一例外的引用了事件总线的库,因为它能帮助我们非常简单的实现组件之间的通信...

    用户1269200
  • js高程之事件通识篇(一)

    在早期的浏览器厂商都认为页面中的元素事件都不仅仅是当前元素上,而是相关的其他元素甚至整个页面都应该相关的机制。但有意思的是,早期的两个开发团队分别是ie和Net...

    RobinsonZhang
  • 关于事件的前端面试题总结

    用户1687375

扫码关注云+社区

领取腾讯云代金券