CN116136860A - 一种事件转发方法、装置、电子设备和存储介质 - Google Patents

Abstract

本申请提供一种事件转发方法、装置、电子设备和计算机存储介质，该方法应用于Knative Eventing系统，所述Knative Eventing系统包括Kafka消息队列，还包括接收组件和过滤组件中的至少一种；该方法包括：利用所述接收组件接收进入所述Knative Eventing系统中的事件，将所述事件中的至少部分事件存储至所述Kafka消息队列的主题Topic中；按照过滤规则对所述至少部分事件进行过滤处理；或，按照设定方式将进入所述Knative Eventing系统中的事件，存储至所述Kafka消息队列的Topic中；通过所述过滤组件消费所述事件，并按照过滤规则对所述事件进行过滤处理；将过滤处理后的事件转发到指定的函数服务中。

Description

一种事件转发方法、装置、电子设备和存储介质

技术领域

本申请涉及云计算技术领域，尤其涉及一种事件转发方法、装置、电子设备和计算机存储介质。

背景技术

Knative Eventing系统提供了Broker/Trigger的消息传递模型，引入事件代理(Broker)和触发器(Trigger)的目的，是为了搭建一个黑盒子，使用Broker和Trigger分离事件生产者和消费者，将具体的实现隐藏起来从而使事件生产者和事件消费者可以后期绑定。

图1为相关技术中的一种Broker/Trigger事件处理模型的结构示意图，如图1所示，当Knative Eventing系统中获取CloudEventss事件，该事件首先要通过超文本传输协议(hyper text transfer protocol，http)请求发送给Ingress组件，Ingress组件接收到CloudEventss事件通知后，将事件转发到Kafka管道(Channel)中，Kafka管道通过Dispatcher组件将事件写入Kafka消息队列中，然后再消费事件并把事件发送到Filter组件，Filter组件根据Trigger中的过滤规则对事件进行过滤处理，最后将满足过滤规则的事件分发到函数服务(Kservice)，进而触发用户函数执行；可见，中间过程各个组件最少要转发4次才能将事件转发到函数，这种方式极大的消耗了底层资源的网络流量及应用资源。

发明内容

本申请提供一种事件转发方法、装置、电子设备和计算机存储介质；可以解决相关技术中在基于Knative Eventing系统进行事件转发时，底层资源的网络流量及应用资源消耗较大的问题。

本申请的技术方案是这样实现的：

本申请提供了一种事件转发方法，应用于Knative Eventing系统，所述KnativeEventing系统包括Kafka消息队列，还包括接收组件和过滤组件中的至少一种；所述方法包括：

利用所述接收组件接收进入所述Knative Eventing系统中的事件，将所述事件中的至少部分事件存储至所述Kafka消息队列的主题Topic中；按照过滤规则对所述至少部分事件进行过滤处理；或，

按照设定方式将进入所述Knative Eventing系统中的事件，存储至所述Kafka消息队列的Topic中；通过所述过滤组件消费所述事件，并按照过滤规则对所述事件进行过滤处理；

将过滤处理后的事件转发到指定的函数服务中。

在一些实施例中，所述按照过滤规则对所述至少部分事件进行过滤处理，包括：

通过所述过滤组件消费所述至少部分事件，并按照过滤规则对所述至少部分事件进行过滤处理。

在一些实施例中，在通过所述过滤组件消费所述至少部分事件，并按照过滤规则对所述至少部分事件进行过滤处理的情况下，所述将过滤处理后的事件转发到指定的函数服务中，包括：

利用所述过滤组件将过滤处理后的事件转发到指定的函数服务中。

在一些实施例中，所述Knative Eventing系统还包括控制器组件，所述方法还包括：

利用所述控制器组件对所述接收组件对应的Broker和所述过滤组件对应的Trigger进行管理操作；所述Broker用于将进入所述Knative Eventing系统中的事件发送给所述接收组件；所述Trigger中配置有所述过滤规则。

在一些实施例中，所述方法还包括：

在进行过滤处理前，根据需要进行过滤处理的事件的Topic，获取对应的Broker的第一属性信息；

获取Trigger中配置的Broker的第二属性信息；

在确定所述第一属性信息和所述第二属性信息匹配时，利用所述控制器组件获取Trigger中配置的过滤规则。

在一些实施例中，所述方法还包括：

在利用所述接收组件接收进入Knative Eventing系统中的事件后，对所述事件进行初始过滤处理，得到所述至少部分事件。

在一些实施例中，所述方法还包括：

在利用所述接收组件接收进入Knative Eventing系统中的事件后，将所述事件转发到指定中间件；所述指定中间件表示除所述Kafka消息队列之外的其它具有存储功能的中间件。

在一些实施例中，所述将过滤处理后的事件转发到指定的函数服务中，包括：

针对所述过滤处理后的事件，解析Trigger中配置的订阅属性；

基于所述订阅属性，将所述过滤处理后的事件转发到指定的函数服务中。

本申请提供一种事件转发装置，应用于Knative Eventing系统，所述KnativeEventing系统包括Kafka消息队列，还包括接收组件和过滤组件中的至少一种；所述装置包括存储过滤模块和转发模块，其中，

存储过滤模块，用于利用所述接收组件接收进入所述Knative Eventing系统中的事件，将所述事件中的至少部分事件存储至所述Kafka消息队列的主题Topic中；按照过滤规则对所述至少部分事件进行过滤处理；或，按照设定方式将进入所述Knative Eventing系统中的事件，存储至所述Kafka消息队列的Topic中；通过所述过滤组件消费所述事件，并按照过滤规则对所述事件进行过滤处理；

转发模块，用于将过滤处理后的事件转发到指定的函数服务中。

本申请提供一种电子设备，所述设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现前述一个或多个技术方案提供的事件转发方法。

本申请提供一种计算机存储介质，所述计算机存储介质存储有计算机程序；所述计算机程序被执行后能够实现前述一个或多个技术方案提供的事件转发方法。

本申请提供一种事件转发方法、装置、电子设备和计算机存储介质，该方法应用于Knative Eventing系统，所述Knative Eventing系统包括Kafka消息队列，还包括接收组件和过滤组件中的至少一种；该方法包括：利用所述接收组件接收进入所述KnativeEventing系统中的事件，将所述事件中的至少部分事件存储至所述Kafka消息队列的Topic中；按照过滤规则对所述至少部分事件进行过滤处理；或，按照设定方式将进入所述Knative Eventing系统中的事件，存储至所述Kafka消息队列的Topic中；通过所述过滤组件消费所述事件，并按照过滤规则对所述事件进行过滤处理；将过滤处理后的事件转发到指定的函数服务中。

可以看出，本申请实施例可以利用接收组件将进入Knative Eventing系统中的事件直接存储到Kafka消息队列中，与相关技术中需要利用Ingress组件接收事件，并将事件转发到Kafka管道中，再通过Dispatcher组件将事件写入Kafka消息队列中相比，本申请实施例仅通过接收组件便可实现事件的接收和存储功能，可以减少事件转发跳数，减少资源的消耗；另外，本申请实施例可以通过过滤组件消费事件，并按照过滤规则对事件进行过滤处理，与相关技术中需要利用Dispatcher组件消费事件并把事件转发到Filter组件，再利用Filter组件对事件进行过滤处理相比，本申请实施例仅通过过滤组件便可实现Dispatcher组件和Filter组件的功能，同样可以减少事件转发跳数，减少资源的消耗；如此，本申请实施例可以解决相关技术中在基于Knative Eventing系统进行事件转发时，底层资源的网络流量及应用资源消耗较大的问题。

附图说明

图1为相关技术中的一种Broker/Trigger事件处理模型的结构示意图；

图2A为本申请实施例的一种事件转发方法的流程图；

图2B为本申请实施例一种改进后的Kafka-Broker/Trigger事件处理模型的结构示意图；

图3为本申请实施例的事件转发装置的组成结构示意图；

图4为本申请实施例提供的电子设备的结构示意图。

具体实施方式

下面将结合本申请中的附图，对本申请中的技术方案进行清楚、完整地描述。

以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所提供的实施例仅仅用以解释本申请，并不用于限定本申请。另外，以下所提供的实施例是用于实施本申请的部分实施例，而非提供实施本申请的全部实施例，在不冲突的情况下，本申请记载的技术方案可以任意组合的方式实施。

需要说明的是，在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的方法或者装置不仅包括所明确记载的要素，而且还包括没有明确列出的其他要素，或者是还包括为实施方法或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括该要素的方法或者装置中还存在另外的相关要素(例如方法中的步骤或者装置中的单元，例如的单元可以是部分处理器、部分程序或软件等等)。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括A、B、C中的至少一种，可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。

例如，本申请提供的事件转发方法包含了一系列的步骤，但是本申请提供的事件转发方法不限于所记载的步骤，同样地，本申请提供的事件转发装置包括了一系列模块，但是本申请提供的事件转发装置不限于包括所明确记载的模块，还可以包括为获取相关信息、或基于信息进行处理时所需要设置的模块。

本申请可以基于电子设备实现，这里，电子设备可以是瘦客户机、厚客户机、手持或膝上设备、基于微处理器的系统、机顶盒、可编程消费电子产品、网络个人电脑、小型计算机系统，等等。

电子设备可以通过程序模块的执行实现相应的功能。通常，程序模块可以包括例程、程序、目标程序、组件、逻辑、数据结构等等。它们执行特定的任务或者实现特定的抽象数据类型。计算机系统可以在分布式云计算环境中实施，在分布式云计算环境中，任务是由通过通信网络链接的远程处理设备执行的。在分布式云计算环境中，程序模块可以位于包括存储设备的本地或远程计算系统存储介质上。

随着云计算的快速发展，传统的软件架构和运维方式也有了跨越式的发展，不断涌现出的新技术在多方面提升云计算的服务能力。Serverless无服务器架构是云计算架构的一种延伸，主要包括了两个领域的技术，后端服务(Backend as a Service，BaaS)和函数计算服务(Function as a Service，FaaS)。Serverless无服务器架构的出现，意味着用户或开发者只需要关注产品代码的业务逻辑，完全从基础环境的配置运维、构建部署等繁杂的工作中解脱出来。

在Serverless产品层面，从最早的AWS Lambda，到Azure Functions、GoogleFunctions、Google CloudRun，再到如今的Serverless Kubernetes、Serverless应用引擎、函数计算等。Knative是谷歌开源的Serverless架构方案，旨在提供一套简单易用的Serverless方案，把Serverless标准化，目前还处于快速发展的阶段。Knative一个很重要的目标就是制定云原生、跨平台的Serverless编排标准。Knative是通过整合容器构建(或者函数)、工作负载管理(和动态扩缩)以及事件模型这三者来实现的Serverless标准。

Knative Eventing是一个开源的Kubernetes上的标准化事件平台，提供了一套管理云计算事件发布和订阅的机制，为Serverless平台提供基于事件的服务触发。KnativeEventing提供可组合的原语，以实现事件生产者和事件消费者之间的绑定。

参照图1所示的相关技术中的Broker/Trigger事件处理模型，基于该模型进行事件转发时，中间组件最少要转发4次才能将事件转发到函数，这种方式极大的消耗了底层资源的网络流量及应用资源。

针对上述问题，提出以下各实施例。

在本申请的一些实施例中，事件转发方法可以利用事件转发装置中的处理器实现，上述处理器可以为特定用途集成电路(Application Specific Integrated Circuit，ASIC)、数字信号处理器(Digital Signal Processor，DSP)、数字信号处理装置(DigitalSignal Processing Device，DSPD)、可编程逻辑装置(Programmable Logic Device，PLD)、现场可编程逻辑门阵列(Field Programmable Gate Array，FPGA)、中央处理器(CentralProcessing Unit，CPU)、控制器、微控制器、微处理器中的至少一种。

图2A为本申请实施例的一种事件转发方法的流程图，该方法应用于KnativeEventing系统，其中，Knative Eventing系统包括Kafka消息队列，还包括接收组件和过滤组件中的至少一种如图2A所示，该流程可以包括：

步骤100：利用接收组件接收进入Knative Eventing系统中的事件，将事件中的至少部分事件存储至Kafka消息队列的Topic中；按照过滤规则对至少部分事件进行过滤处理。

这里，Knative Eventing系统能够绑定事件生产者和事件消费者，并通过事件转发方法使事件的生产者和消费者充分解耦。

示例性地，Knative Eventing系统可以包括接收组件，该组件用于接收进入Knative Eventing系统中的事件；其中，进入Knative Eventing系统中的事件可以是Knative Eventing系统外部其他应用发送的事件，也可以是由不同的事件源发送的事件，这里，对于事件源的类型不作限定，例如可以是GitHub、ContainerSource等事件源。

在一些实施例中，接收组件还用于在接收到进入Knative Eventing系统中的事件后，将事件的格式转化为CloudEventss格式。

这里，在接收组件接收到进入Knative Eventing系统中的事件后，首先对事件进行解析，得到事件的格式；在确定事件的格式为CloudEventss格式时，继续对事件进行后续处理；反之，在确定事件的格式不为CloudEventss格式时，则需要先将事件的格式转化为CloudEventss格式，再进行后续处理。

这里，通过对进入Knative Eventing系统中的事件进行格式转化，可以确保该系统中的相关组件对其进行使用。

在一些实施例中，上述方法还可以包括：在利用接收组件接收进入KnativeEventing系统中的事件后，对事件进行初始过滤处理，得到至少部分事件。

本申请实施例中，接收组件具有事件过滤功能；这里，在接收组件接收到进入Knative Eventing系统中的每个事件，且确定这些事件的格式均为CloudEventss格式后，可以对这些事件进行初始过滤处理，得到至少部分事件；即，至少部分事件表示满足过滤条件的事件；对不满足过滤条件的事件则不作处理。

可见，基于接收组件的过滤功能，不需要进入Knative Eventing系统中的所有事件均在最后转发给函数服务前通过同一组件进行过滤处理，可以减少一定的过滤压力。

在一些实施例中，Knative Eventing系统还可以包括控制器组件，上述方法还可以包括：利用控制器组件对接收组件对应的Broker进行管理操作；其中，Broker用于将进入Knative Eventing系统中的事件发送给接收组件。

这里，在用户创建与接收组件对应的Broker后，控制器组件会创建一个Broker的统一资源定位系统(uniform resource locator，url)链接，链接接收组件的实际服务url地址；该url链接路径包括了Broker的命名空间和名称；这样，当进入Knative Eventing系统中的事件发送到该url链接时，后端实际发送到了接收组件，这样，接收组件便可接收到进入Knative Eventing系统中的所有事件。

示例性地，控制器组件可以通过监听Kubernetes API接口，确定Broker的资源变化情况；这里，控制器组件对Broker进行管理操作表示当用户创建、删除、修改Broker对应的资源时，控制器组件能够监听到资源的变化并实现资源的操作同步。

示例性地，Knative Eventing系统还可以包括Kafka消息队列；在利用接收组件接收进入Knative Eventing系统中的事件，并进行初始过滤处理后，会将过滤处理后的至少部分事件存储至Kafka消息队列的Topic中。

这里，在用户创建与接收组件对应的Broker后，控制器组件会同时为Kafka消息队列创建相应的Topic；类似地，在用户修改或删除与接收组件对应的Broker后，控制器组件会同时为Kafka消息队列修改或删除相应的Topic；即，控制器组件还可以实现对Kafka消息队列的Topic进行管理操作。

示例性地，在接收组件根据上述url链接明确Broker的命名空间和名称的情况下，可以将过滤处理后的至少部分事件存储至与Broker对应的Kafka消息队列的Topic中。

进一步地，在确定Kafka消息队列的Topic中存在至少部分事件时，可以按照过滤规则对至少部分事件进行过滤处理。

示例性地，过滤规则可以表示与事件的事件源和事件类型相关的信息；这样，在获取过滤规则后，通过确定至少部分事件中每个事件对应的事件源和事件类型是否满足过滤规则，如果确定满足，则说明对应事件符合转发条件；反之，如果确定不满足，则说明对应事件不符合转发条件，并对该事件进行过滤处理。

在一种实施方式中，按照过滤规则对至少部分事件进行过滤处理的实现方式可以参照图1，具体为：可以通过Dispatcher组件消费Kafka消息队列的Topic中的至少部分事件，并将至少部分事件发送到Filter组件，Filter组件根据Trigger中的过滤规则对事件进行过滤处理。

可以看出，本申请实施例利用接收组件接收进入Knative Eventing系统中的事件后，并将过滤处理后的至少部分事件存储至Kafka消息队列中，与相关技术中需要利用Ingress组件接收事件，并将事件转发到Kafka管道中，再通过Dispatcher组件将事件写入Kafka消息队列中相比，本申请实施例仅通过接收组件便可实现事件的接收和存储功能，可以减少事件转发跳数，减少资源的消耗；另外，由于接收组件还具有事件过滤功能，因而，可以减少Filter组件的过滤压力。

步骤101：按照设定方式将进入Knative Eventing系统中的事件，存储至Kafka消息队列的Topic中；通过过滤组件消费事件，并按照过滤规则对事件进行过滤处理。

示例性地，与步骤100中利用接收组件同时实现事件的接收和存储不同的是，还可以按照设定方式将进入Knative Eventing系统中的事件，存储至Kafka消息队列的Topic中，对应的实现方式可以参照图1，具体为：将进入Knative Eventing系统中的事件先发送给Ingress组件，Ingress组件接收到事件通知后，会将事件转发到Kafka管道中，Kafka管道通过Dispatcher组件将事件写入Kafka消息队列的Topic中。

示例性地，在确定Kafka消息队列的Topic中存在事件时，可以通过该过滤组件消费事件，并按照过滤规则对事件进行过滤处理；这里，消费事件表示获取事件。

示例性地，可以利用控制器组件对过滤组件对应的Trigger进行管理操作；其中，Trigger中配置有过滤规则。这里，对Trigger进行管理操作表示利用控制器组件可以实现对Trigger对应资源的增删改查，同时实现Trigger的业务逻辑；在用户创建Trigger后，控制器组件可以获取到Trigger中配置的过滤规则。

这里，本申请实施例可以利用控制器组件对接收组件对应的Broker和过滤组件对应的Trigger均进行管理操作；与相关技术中，需要使用不同的控制组件分别对Broker和Trigger进行管理操作相比，可以降低管理复杂度。

在一些实施例中，上述方法还可以包括：在对事件进行过滤处理前，根据需要进行过滤处理的事件的Topic，获取对应的Broker的第一属性信息；获取Trigger中配置的Broker的第二属性信息；在确定第一属性信息和第二属性信息匹配时，利用控制器组件获取Trigger中配置的过滤规则。

这里，第一属性信息和第二属性信息可以包括名称和命名空间。示例性地，在通过过滤组件消费事件时，可以获取到该事件的Topic；这样，在需要对该事件进行过滤处理时，根据该事件的Topic，获取对应的Broker的名称和命名空间；同时，在通过过滤组件消费事件时，可以获取Trigger中配置的Broker的名称和命名空间；然后，将根据Topic获取的Broker的名称和命名空间与Trigger中配置的Broker的名称和命名空间进行对比，在确定两者匹配时，可以利用控制器组件获取Trigger中配置的过滤规则；反之，在确定两者不匹配时，不需要获取Trigger中配置的过滤规则。

示例性地，在利用控制器组件获取过滤规则后，通过确定需要进行过滤处理的事件是否满足过滤规则，如果确定满足，则说明该事件符合转发条件；反之，如果确定不满足，则说明该事件不符合转发条件，并对该事件进行过滤处理。

可以看出，本申请实施例通过过滤组件消费事件，并按照过滤规则对事件进行过滤处理，与相关技术中需要利用Dispatcher组件消费事件并把事件转发到Filter组件，再利用Filter组件对事件进行过滤处理相比，本申请实施例仅通过过滤组件便可实现Dispatcher组件和Filter组件这两个组件的功能，进而，可以减少事件转发跳数，减少资源的消耗。

需要说明的是，步骤100和步骤101是两个可选的过程；在执行步骤101之前，可以执行步骤100和步骤101中的任意一项。

步骤102：将过滤处理后的事件转发到指定的函数服务中。

本申请实施例中，过滤处理后的事件表示根据步骤101得到的所有满足过滤规则的事件；示例性地，在得到过滤处理后的事件后，将过滤处理后的事件转发到指定的函数服务中，可以包括：针对过滤处理后的事件，解析Trigger中配置的订阅属性；基于订阅属性，将过滤处理后的事件转发到指定的函数服务中。

示例性地，解析Trigger中配置的订阅属性表示解析Trigger中配置的subscriber字段；这里，subscriber字段中指定了过滤处理后的事件所要转发的函数服务；因而，基于该订阅属性，可以将过滤处理后的事件转发到指定的函数服务中。

本申请提供一种事件转发方法、装置、电子设备和计算机存储介质，该方法应用于Knative Eventing系统，该方法包括：利用接收组件接收进入Knative Eventing系统中的事件，将事件中的至少部分事件存储至Kafka消息队列的Topic中；按照过滤规则对至少部分事件进行过滤处理；或，按照设定方式将进入Knative Eventing系统中的事件，存储至Kafka消息队列的Topic中；通过过滤组件消费事件，并按照过滤规则对事件进行过滤处理；将过滤处理后的事件转发到指定的函数服务中。

可以看出，本申请实施例可以利用接收组件将进入Knative Eventing系统中的事件直接存储到Kafka消息队列中，与相关技术中需要利用Ingress组件接收事件，并将事件转发到Kafka管道中，再通过Dispatcher组件将事件写入Kafka消息队列中相比，本申请实施例仅通过接收组件便可实现事件的接收和存储功能，可以减少事件转发跳数，减少资源的消耗；另外，本申请实施例可以通过过滤组件消费事件，并按照过滤规则对事件进行过滤处理，与相关技术中需要利用Dispatcher组件消费事件并把事件转发到Filter组件，再利用Filter组件对事件进行过滤处理相比，本申请实施例仅通过过滤组件便可实现Dispatcher组件和Filter组件的功能，同样可以减少事件转发跳数，减少资源的消耗；如此，本申请实施例可以解决相关技术中在基于Knative Eventing系统进行事件转发时，底层资源的网络流量及应用资源消耗较大的问题。

在一些实施例中，上述方法还可以包括：在利用接收组件接收进入KnativeEventing系统中的事件后，将事件转发到指定中间件；指定中间件表示除Kafka消息队列之外的其它具有存储功能的中间件。

示例性地，接收组件还具有将接收到的事件转发到其他指定中间件的功能；本申请实施例，对于指定中间件的类型不作限定，例如，可以是第三方数据库等。这里，通过将事件转发到其他中间件，可以灵活与其他中间件集成，实现不同业务场景的使用。

在一种实施方式中，按照过滤规则对至少部分事件进行过滤处理，可以包括：通过过滤组件消费至少部分事件，并按照过滤规则对至少部分事件进行过滤处理。

这里，通过过滤组件对至少部分事件进行过滤处理的实现方式与步骤101中上述通过过滤组件消费对事件进行过滤处理的过程类似，此处不再赘述。

可见，本申请实施例利用接收组件接收进入Knative Eventing系统中的事件后，并将过滤处理后的至少部分事件存储至Kafka消息队列中，并通过过滤组件实现Dispatcher组件和Filter组件这两个组件的功能；如此，可以简化事件在KnativeEventing系统中的传递跳数，节省系统资源。

在一些实施例中，在通过过滤组件消费至少部分事件，并按照过滤规则对至少部分事件进行过滤处理的情况下，将过滤处理后的事件转发到指定的函数服务中，可以包括：利用过滤组件将过滤处理后的事件转发到指定的函数服务中。

示例性地，在通过过滤组件得到过滤处理后的事件后，会利用过滤组件将过滤处理后的事件转发到指定的函数服务中，以触发该函数服务执行相应操作。

为了能够更加体现本申请的目的，在本申请上述实施例的基础上，进行进一步的说明。

在相关技术中Broker/Trigger模型的基础上，图2B为本申请实施例一种改进后的Kafka-Broker/Trigger事件处理模型的结构示意图，如图2B所示，该模型主要包括三个组件：Kafka-Receive组件、Kafka-Broker-Controller组件和Kafka-Dispatch组件；其中，Kafka-Receive组件对应上述接收组件，用于负责接收外部进入Knative Eventing系统中的事件，例如图中所示的CloudEventsss事件；Kafka-Broker-Controller组件对应上述控制器组件，用于负责创建Kafka消息队列的资源(对应图中的KafkaSink)，以及管理Kafka-Broker(对应上述Broker)和Trigger的创建，删除，更新等操作；Kafka-Dispatch组件对应上述过滤组件，用于负责消费Kafka消息队列中的事件并过滤事件，最后转发给指定的函数服务。

示例性地，该模型通过Kafka-Broker-Controller组件管理Kafka Broker和Trigger对应的资源；该组件的功能实现主要基于kubernetes中的自定义资源(CustomResource Definition，CRD)实现，其具有图1所示的Broker/Trigger模型中的Broker控制器和Trigger控制器的功能，以及Kafka消息队列对应的资源的管理功能，例如Borker和Trigger资源的增删改查。该组件在功能上是没有影响的，可以对Kafka管道资源进行管理，通过对Kafka消息队列的Topic进行管理(Kafka管道在原有系统是一种自定义资源，是通过Broker控制器创建管理的)；可见，与相关技术相比，该组件增加了对Trigger对应资源的管理，性能不会发生变化。

这里，Kafka-Receive组件相对与相关技术中的Ingress组件和Kafka管道的结合是保证了这两个组件本身的功能的；在本申请实施例中，Kafka-Receiver组件接收到外部事件后，通过Kafka Broker的资源信息获取到Kafka消息队列的Topic，并将事件存放到Kafka消息队列的Topic中。Kafka-Receive组件不是简单的Ingress组件和Kafka管道这两个模块的组合，是新的组件实现了两个模块的功能，相比于相关技术中的两个模块实现相同的功能，可减少不必要的转发步骤；此外，Kafka-Receive组件还具有过滤功能，从而减少相关技术中的Dispatcher组件的过滤压力，增加转发到其他中间件的功能，灵活与其他中间件集成，实现不同业务场景的使用。

进一步地，由于Kafka-Dispatcher组件具有转发过滤功能，相对于相关技术中的Dispatcher组件增加了获取Trigger过滤规则进行事件过滤的功能，不需要所有事件均转发到Filter组件进行过滤处理，减少转发请求的时间和流量消耗；另外，由于该组件的数据来源是Kafka消息队列，在其他应用场景中也具有监听http请求的事件，实现不同业务场景的事件过滤转发功能。

参照图2B，Kafka-Broker-Controller组件实现了Kafka Broker和Trigger的业务逻辑，当用户创建Kafka Broker时，Kafka-Broker-Controller组件会为用户创建相应的Kafka Topic供用户持久存放事件；图中所示的CloudEventsss事件是指从KnativeEventing系统外部接收的事件或事件源发送给Knative Eventing系统的事件。在KafkaBroker/Trigger的消息机制中，通过Kafka-Receiver组件接收事件，接收到事件后将事件存放在Kafka消息队列的Topic中；当Kafka消息队列的Topic中存在事件时，通过KafkaDispatcher组件消费事件，并获取Trigger的相关配置信息(配置规则)进行事件过滤，最后将符合配置规则的事件发送给指定的函数服务并触发函数服务执行。

可见，本申请实施例提出了一种基于Knative Eventing系统的Kafka-Broker/Trigger消息传递模式；通过Kafka-Broker/Trigger模式中的三个组件实现了事件的接收并存储、过滤处理到最后触发函数执行的过程；可以解决了相关技术中Knative Eventing系统中的Broker/Trigger模式事件转发次数太多,占用网络流量及应用资源大的问题，并且因为Kafka-Broker/Trigger模式中需要部署的组件较少，对用户来说更容易理解学习，在生产中对问题的排查追踪更方便，易维护。

参照图2B，本申请实施例定义了三种CRD资源，分别为Kafka Broker、Trigger和KafkaSink；这里，通过Kafka-Broker-Controller组件实现这三种资源的管理控制，该组件通过监听这三种资源的变化情况并进行相关业务处理。

下面，对Kafka-Broker-Controller组件的实现方式进行说明，具体可以包括以下步骤：

步骤A1：创建CRD，作为kubernetes的自定义资源。

步骤A2：编写代码，将CRD的情况写入对应的代码中，然后通过自动代码生成工具k8s.io/code-generator(kubernetes提供的代码生成工具)实现Kubernetes资源的自定义扩展，将Kafka-Broker-Controller组件之外的Informer，客户端(client)代码等内容较为固定的代码通过工具生成；这里，Informer是用于kubernets开发的核心工具包。

步骤A3：编写Kafka-Broker-Controller组件，进行实际业务处理；这里，可以主要采用go语言实现CRD资源控制器Kafka-Broker-Controller组件的编写，Kafka-Broker-Controller组件不断的监听Kubernetes API接口中Broker、Trigger和KafkaSink资源的变化。当用户创建、删除、修改资源Broker、Trigger及KafkaSink资源时，Kafka-Broker-Controller组件能够监听到资源的变化并实现资源的操作同步。同时，该组件还可以实现Kafka服务的Topic的管理，当用户创建了Broker后，Kafka-Broker-Controller组件负责为Kafka消息队列创建修改或删除相应的Topic。

步骤A4：创建Broker的方法，实现Broker的增删改查，同时实现Broker的业务逻辑；当用户创建Broker时，Kafka-Broker-Controller组件会创建一个Broker的url连接，链接后端代理Kafka-Receiver的实际服务url地址；该链接路径包括了Broker的命名空间和名称信息，用户将事件发送到该链接时，后端实际发送到了Kafka-Receiver组件。示例性地，创建Broker关键代码如下：

其中，上面示例代码表示在defaultnamespaces的命名空间中创建了名为default的Kafka-Broker。并声明该Broker类型为Kafka。当用户通过上述文件创建broker后，Kafka-Broker-Controller组件会生成Broker的url：http://Kafka-broker.knative-eventing.svc.cluster.local/defaultnamespace/default；该url就代理了Kafka-Receiver的服务地址。事件源将事件发送到该地址之后，Broker代理转发到Kafka-receiver实际的服务地址。

步骤A5：创建Trigger的方法，实现资源Trigger的增删改查，同时实现Trigger的业务逻辑；当用户创建Trigger后，Kafka-Broker-Controller组件获取到事件的过滤规则，并指定事件转发的目的地地址。示例性地，创建Trigger关键代码如下：

其中，上面示例代码表示用户创建了名称为my-service-trigger的Trigger资源，设置了名称为default的Broker，代表接收default Broker中的事件，并设置了过滤类型为dev.knative.foo.bar，同时过滤扩展名为my-extension-value的事件；subscriber是指将过滤的事件发送到指定的函数服务中，上例中通过以上过滤规则进行事件过滤，最后将符合过滤规则的事件发送到my-service的函数服务中。

步骤A6：创建KafkaSink方法，实现资源KafkaSink资源的增删改并实现Kafka资源的topic的管理。当用户创建Broker后，Kafka-Broker-Controller组件同时创建一个指定名称的Topic；示例性地，Topic名称可以指定为knative-sink-为前缀并与Broker的命名空间和Broker名称以中横线连接，在Kafka-Receive组件明确Broker的名称和命名空间的情况下，就可以将事件写入到指定的Topic中。

这部分主要对Kafka-Receiver组件的实现方式进行说明；Kafka-Receiver组件主要实现接收事件源发送的事件，并将事件写入到Kafka消息队列指定的Topic中。该组件主要通过go语言技术实现，具体步骤如下：

步骤B1：Kafka-Receiver组件的实现功能主要是通过监听接收事件，因此，该组件是启动了一个http server服务端，监听post请求。事件源发送事件时url中带有Broker的命名空间和名称的信息，当Kafka-Receiver组件接收到信息后，解析url获取到Broker的名称和命名空间。

步骤B2：Kafka-Receiver组件获取到Broker的名称和命名空间后，将Body体中的CloudEventsss事件写入到指定的Topic中，该Topic的名称为knative-sink-为前缀与Broker的命名空间和Broker名称以中横线连接。该组件采用go实现的sarama作为Kafka的软件开发工具包(Software Development Kit，SDK)客户端，调用该SDK的接口将事件写入到Kafka消息队列的Topic中。

步骤B3：Kafka-Receiver组件增加保存其他数据库的功能，通过启动参数配置第三方数据库的接口，当接收到事件后通过解析CloudEventss格式并保存在指定的数据库中，以供其他应用使用。

这部分主要对Kafka-Dispathcher组件的实现方式进行说明；Kafka-Dispathcher组件主要实现事件的消费及事件的过滤和转发功能；具体实现步骤：

步骤C1：Kafka-Dispathcher组件消费Kafka消息队列的Topic中的事件，当Kafka的Topic中有事件时，Dispatcher消费该事件，并根据消费的Topic获取Broker的名称和命名空间。

步骤C2：Dispatcher组件获取到事件后，获取Trigger中配置的Broker的名称和命名空间，并将Trigger中配置的Broker的名称和命名空间与根据消费的Topic获取Broker的名称和命名空间进行匹配，如果匹配，获取到该Trigger的过滤规则。

步骤C3：获取到Trigger的过滤规则后，通过将CloudEventsss事件的事件源和事件类型与过滤规则进行匹配，否满足Trigger中配置的过滤规则，解析Trigger配置中的subscriber属性，将事件转发到Trigger指定的函数服务中。

这部分说明了配置Knative Eventing系统默认使用Kafka-Broker的方式，通过修改名称空间中的config-br-defaults ConfigMap来进行全局设置，将Kafk-Broker设置为Knative Eventing系统中全局配置，所有事件都使用Kafka-Broker/Trigger机制进行消息传递。以下YAML代码是config-br-defaults使用Kafka Broker作为默认配置的ConfigMap。

以上示例代码表示创建了Kubernetes资源ConfigMap自有资源，ConfigMap资源在Kubernetes集群中作为组件的配置文件挂载在组件中。该配置文件挂载在KnativeEventing系统的Kafka-Broker-Controller组件中，控制整个系统的事件流。上述配置文是在knative-eventing的命名空间中创建了名为config-br-defaults的configmap配置文件，主要配置全局Knative Eventing系统中Broker类型和连接Kafka消息队列的相关配置。该配置中的data参数表示配置内容，default-br-config表示默认的Kafka-Broker-Controller组件配置，brokerClass表示Broker的类型，在本申请中是指Kakfa类型。配置了在knative-eventing命名空间中的Kafka-broker-config配置。

如上所述，本申请实施例基于Knative Eventing系统的事件转发方法只需要将接收的事件写入Kafka消息队列中，然后通过消费Kafka消息队列中的消息，过滤转发到函数中；即，只需要接收保存转发省去中间件之间的请求转发过程，减少事件转发的跳数，减少系统中因为转发所消耗的网络流量和应用资源。

图3为本申请实施例的事件转发装置的组成结构示意图，应用于KnativeEventing系统，所述Knative Eventing系统包括Kafka消息队列，还包括接收组件和过滤组件中的至少一种；如图3所示，该装置包括：存储过滤模块300和转发模块301，其中：

存储过滤模块300，用于利用所述接收组件接收进入所述Knative Eventing系统中的事件，将所述事件中的至少部分事件存储至所述Kafka消息队列的主题Topic中；按照过滤规则对所述至少部分事件进行过滤处理；或，按照设定方式将进入所述KnativeEventing系统中的事件，存储至所述Kafka消息队列的Topic中；通过所述过滤组件消费所述事件，并按照过滤规则对所述事件进行过滤处理；

转发模块301，用于将过滤处理后的事件转发到指定的函数服务中。在一些实施例中，

在一些实施例中，所述存储过滤模块300，用于按照过滤规则对所述至少部分事件进行过滤处理，包括：

通过所述过滤组件消费所述至少部分事件，并按照过滤规则对所述至少部分事件进行过滤处理。

在一些实施例中，在通过所述过滤组件消费所述至少部分事件，并按照过滤规则对所述至少部分事件进行过滤处理的情况下，所述转发模块301，用于将过滤处理后的事件转发到指定的函数服务中，包括：

利用所述过滤组件将过滤处理后的事件转发到指定的函数服务中。

在一些实施例中，所述Knative Eventing系统还包括控制器组件，所述存储过滤模块300，还用于：

利用所述控制器组件对所述接收组件对应的Broker和所述过滤组件对应的Trigger进行管理操作；所述Broker用于将进入所述Knative Eventing系统中的事件发送给所述接收组件；所述Trigger中配置有所述过滤规则。

在一些实施例中，所述存储过滤模块300，还用于：

在进行过滤处理前，根据需要进行过滤处理的事件的Topic，获取对应的Broker的第一属性信息；

获取Trigger中配置的Broker的第二属性信息；

在确定所述第一属性信息和所述第二属性信息匹配时，利用所述控制器组件获取Trigger中配置的过滤规则。

在一些实施例中，所述存储过滤模块300，还用于：

在利用所述接收组件接收进入Knative Eventing系统中的事件后，对所述事件进行初始过滤处理，得到所述至少部分事件。

在一些实施例中，所述存储过滤模块300，还用于：在利用所述接收组件接收进入Knative Eventing系统中的事件后，将所述事件转发到指定中间件；所述指定中间件表示除所述Kafka消息队列之外的其它具有存储功能的中间件。

在一些实施例中，所述转发模块301，用于将过滤处理后的事件转发到指定的函数服务中，包括：

针对所述过滤处理后的事件，解析Trigger中配置的订阅属性；

基于所述订阅属性，将所述过滤处理后的事件转发到指定的函数服务中。

在实际应用中，上述存储过滤模块300和转发模块301均可以由位于电子设备中的处理器实现，该处理器可以为ASIC、DSP、DSPD、PLD、FPGA、CPU、控制器、微控制器、微处理器中的至少一种。

另外，在本实施例中的各功能模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对相关技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)或processor(处理器)执行本实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等多种可以存储程序代码的介质。

具体来讲，本实施例中的一种事件转发方法对应的计算机程序指令可以被存储在光盘、硬盘、U盘等存储介质上，当存储介质中的与一种事件转发方法对应的计算机程序指令被一电子设备读取或被执行时，实现前述实施例的任意一种事件转发方法。

基于前述实施例相同的技术构思，参见图4，其示出了本申请实施例提供的电子设备400，可以包括：存储器401和处理器402；其中，

存储器401，用于存储计算机程序和数据；

处理器402，用于执行存储器中存储的计算机程序，以实现前述实施例的任意一种事件转发方法。

在实际应用中，上述存储器401可以是易失性存储器(volatile memory)，例如RAM；或者非易失性存储器(non-volatile memory)，例如ROM、快闪存储器(flash memory)、硬盘(Hard Disk Drive，HDD)或固态硬盘(Solid-State Drive，SSD)；或者上述种类的存储器的组合，并向处理器402提供指令和数据。

上述处理器402可以为ASIC、DSP、DSPD、PLD、FPGA、CPU、控制器、微控制器、微处理器中的至少一种。可以理解地，对于不同的模型训练设备，用于实现上述处理器功能的电子器件还可以为其它，本申请实施例不作具体限定。

在一些实施例中，本申请实施例提供的装置具有的功能或包含的模块可以用于执行上文方法实施例描述的方法，其具体实现可以参照上文方法实施例的描述，为了简洁，这里不再赘述。

上文对各个实施例的描述倾向于强调各个实施例之间的不同之处，其相同或相似之处可以互相参考，为了简洁，本文不再赘述。

本申请所提供的各方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的各产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的各方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其它可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其它可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可装载到计算机或其它可编程数据处理设备上，使得在计算机或其它可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其它可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。

Claims (11)

1.一种事件转发方法，其特征在于，应用于Knative Eventing系统，所述KnativeEventing系统包括Kafka消息队列，还包括接收组件和过滤组件中的至少一种；所述方法包括：

利用所述接收组件接收进入所述Knative Eventing系统中的事件，将所述事件中的至少部分事件存储至所述Kafka消息队列的主题Topic中；按照过滤规则对所述至少部分事件进行过滤处理；或，

按照设定方式将进入所述Knative Eventing系统中的事件，存储至所述Kafka消息队列的Topic中；通过所述过滤组件消费所述事件，并按照过滤规则对所述事件进行过滤处理；

将过滤处理后的事件转发到指定的函数服务中。

2.根据权利要求1所述的方法，其特征在于，所述按照过滤规则对所述至少部分事件进行过滤处理，包括：

通过所述过滤组件消费所述至少部分事件，并按照过滤规则对所述至少部分事件进行过滤处理。

3.根据权利要求1或2所述的方法，其特征在于，在通过所述过滤组件消费所述至少部分事件，并按照过滤规则对所述至少部分事件进行过滤处理的情况下，所述将过滤处理后的事件转发到指定的函数服务中，包括：

利用所述过滤组件将过滤处理后的事件转发到指定的函数服务中。

4.根据权利要求1或2所述的方法，其特征在于，所述Knative Eventing系统还包括控制器组件，所述方法还包括：

利用所述控制器组件对所述接收组件对应的Broker和所述过滤组件对应的Trigger进行管理操作；所述Broker用于将进入所述Knative Eventing系统中的事件发送给所述接收组件；所述Trigger中配置有所述过滤规则。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

在进行过滤处理前，根据需要进行过滤处理的事件的Topic，获取对应的Broker的第一属性信息；

获取Trigger中配置的Broker的第二属性信息；

在确定所述第一属性信息和所述第二属性信息匹配时，利用所述控制器组件获取Trigger中配置的过滤规则。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在利用所述接收组件接收进入Knative Eventing系统中的事件后，对所述事件进行初始过滤处理，得到所述至少部分事件。

7.根据权利要求1或6所述的方法，其特征在于，所述方法还包括：

在利用所述接收组件接收进入Knative Eventing系统中的事件后，将所述事件转发到指定中间件；所述指定中间件表示除所述Kafka消息队列之外的其它具有存储功能的中间件。

8.根据权利要求1所述的方法，其特征在于，所述将过滤处理后的事件转发到指定的函数服务中，包括：

针对所述过滤处理后的事件，解析Trigger中配置的订阅属性；

基于所述订阅属性，将所述过滤处理后的事件转发到指定的函数服务中。

9.一种事件转发装置，其特征在于，应用于Knative Eventing系统，所述KnativeEventing系统包括Kafka消息队列，还包括接收组件和过滤组件中的至少一种；所述装置包括：

存储过滤模块，用于利用所述接收组件接收进入所述Knative Eventing系统中的事件，将所述事件中的至少部分事件存储至所述Kafka消息队列的主题Topic中；按照过滤规则对所述至少部分事件进行过滤处理；或，按照设定方式将进入所述Knative Eventing系统中的事件，存储至所述Kafka消息队列的Topic中；通过所述过滤组件消费所述事件，并按照过滤规则对所述事件进行过滤处理；

转发模块，用于将过滤处理后的事件转发到指定的函数服务中。

10.一种电子设备，其特征在于，所述设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现权利要求1至8任一项所述的方法。

11.一种计算机存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至8任一项所述的方法。

Images