CN115033344A - 事件处理系统和事件处理方法、设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种事件处理系统和事件处理方法、设备及存储介质。本申请实施例提供一种通用的资源事件引擎，主要增设了动态管理组件和资源对象的监测对象。其中，动态管理组件可获取计算集群的资源事件；并根据资源事件确定订阅该资源事件的目标监测对象；目标监测对象可将资源事件提供给对应的执行器，执行器根据资源事件对相关资源对象进行处理。该资源事件处理对资源事件的类型无要求，有助于提高资源事件引擎的通用性。

Description

事件处理系统和事件处理方法、设备及存储介质

技术领域

本申请涉及云服务技术领域，尤其涉及一种事件处理系统和事件处理方法、设备及存储介质。

背景技术

PaaS平台是一个基于容器集群管理系统构建的云平台。控制器-运行时(controller-runtime)框架被用来创建容器集群管理系统的资源控制器。通过controller-runtime可以监听资源的变化，捕获资源事件(Resource Event)，触发相应的处理流程。但是，controller-runtime框架灵活度较差，支持的资源事件有限。

发明内容

本申请的多个方面提供一种事件处理系统和事件处理方法、设备及存储介质，用以提供一种新的事件处理系统，提高事件引擎的通用性。

本申请实施例提供一种事件处理系统，包括：控制器；所述控制器包括：动态管理组件、执行器和计算集群的资源对象对应的监测对象；

所述动态管理组件，用于获取计算集群的第一资源对象的事件；并根据所述第一资源对象的事件，确定订阅所述第一资源对象的事件的目标监测对象；将所述第一资源对象的事件提供给所述目标监测对象；所述目标监测对象将所述第一资源对象的事件提供给所述目标监测对象对应的执行器；

所述目标监测对象对应的执行器用于根据所述第一资源对象的事件，对所述第一资源对象和/或所述目标监测对象对应的第二资源对象进行处理。

本申请实施例还提供一种事件处理方法，包括：

调用动态管理组件获取计算集群的第一资源对象的事件；

根据所述第一资源对象的事件，确定订阅所述第一资源对象的事件的目标监测对象；

将所述第一资源对象的事件提供给所述目标监测对象，以供所述目标监测对象将所述第一资源对象的事件提供给所述目标监测对象对应的执行器；

调用所述目标监测对象对应的执行器根据所述第一资源对象的事件，对所述第一资源对象和/或所述目标监测对象对应的第二资源对象进行处理。

本申请实施例还提供一种计算设备，包括：存储器和处理器；其中，所述存储器，用于存储计算机程序；

所述处理器耦合至所述存储器，用于执行所述计算机程序以用于执行上述事件处理方法中的步骤。

本申请实施例还提供一种存储有计算机指令的计算机可读存储介质，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行上述事件处理方法中的步骤。

本申请实施例提供一种通用的资源事件引擎，主要增设了动态管理组件和资源对象的监测对象。其中，动态管理组件可获取计算集群的资源事件；并根据资源事件确定订阅该资源事件的目标监测对象；目标监测对象可将资源事件提供给对应的执行器，执行器根据资源事件对相关资源对象进行处理。该资源事件处理对资源事件的类型无要求，有助于提高资源事件引擎的通用性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1和图2为本申请实施例提供的事件处理系统的结构示意图；

图3为controller-runtime框架进行应用状态管理的示意图；

图4为本申请实施例提供的事件处理系统进行应用状态管理的示意图；

图5为controller-runtime框架进行应用状态管理和本申请实施例提供的事件处理系统进行应用状态管理的CPU使用量的测试结果；

图6为本申请实施例提供的事件处理方法的流程示意图；

图7为本申请实施例提供的计算设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在容器集群管理平台中，controller-runtime框架被用来创建容器集群管理系统的资源控制器。通过controller-runtime可以监听资源的变化，捕获资源事件(ResourceEvent)，触发相应的处理流程。但是，发明人对controller-runtime架构研究发现，controller-runtime框架灵活度较差，支持的资源事件有限。例如，controller-runtime框架仅支持有ownerReference的资源对象订阅的资源事件，无法支持松耦合的cluster级别和namespace级别间的关联事件，也无法支持非结构类型对象的资源事件及非ownerReference的资源对象事件级联订阅等。

针对上述技术问题，本申请实施例提供一种通用的资源事件引擎，主要增设了动态管理组件和资源对象的监测对象。其中，动态管理组件可获取计算集群的资源事件；并根据资源事件确定订阅该资源事件的目标监测对象；目标监测对象可将资源事件提供给对应的执行器，执行器根据资源事件对相关资源对象进行处理。该资源事件处理对资源事件的类型无要求，有助于提高资源事件引擎的通用性。

以下结合附图，详细说明本申请各实施例提供的技术方案。

应注意到：相同的标号在下面的附图以及实施例中表示同一物体，因此，一旦某一物体在一个附图或实施例中被定义，则在随后的附图和实施例中不需要对其进行进一步讨论。

图1和图2为本申请实施例提供的事件处理系统的结构示意图。该事件处理系统可实现为容器集群管理系统中控制器的事件引擎，用于对容器集群管理平台的资源对象的事件进行处理。在本申请实施例中，资源对象的事件，也可称为资源事件，主要是指资源本身发生变化时触发的事件。资源对象的事件可包括：创建事件(Create Event)、更新事件(Update Event)和删除事件(Delete Event)等。当然，资源对象的事件也可包括计算集群的外部事件，即非集群内资源事件。

如图1和图2所示，事件处理系统可包括：控制器(Controller)10。在容器集群管理系统中，控制器10通过监测计算集群的公共状态，并致力于将当前状态转变为期望的状态。一个控制器10至少追踪一种类型的资源。这些资源对象有一个代表期望状态的spec字段。该资源对象的控制器负责确保其当前状态达到期望状态。

在本申请实施例中，控制器10可实现事件订阅、事件通知和事件执行等资源事件处理。下面对控制器10进行资源事件处理的方式进行示例性说明。

如图1和图2所示，针对计算集群的资源对象，控制器10可动态创建和移除资源对象对应的监测对象11(Watcher)(对应图1和图2中的步骤1)。监测对象11为资源对象在控制器10中的逻辑体现。在本申请实施例中，资源对象可为容器集群管理系统对应集群中任意资源，包括但不局限于结构类型对象(Structure Type Objects)和非结构类型对象(Unstructure Type Objects)等。结构类型对象是指在控制器1代码中定义有明确的数据结构的资源对象，可包括：容器集群管理系统原生支持的资源对象和自定义资源对象(Custom Resource，CR)；非结构类型对象是指在控制器代码中没有定义有数据结构的资源对象，可包括自定义资源对象等。

具体地，控制器10可响应于监测对象创建事件，创建监测对象(Watcher)11(对应图1和图2中步骤1中的“创建”)。在本申请实施例中，不限定监测对象创建事件的具体实现形态。在一些实施例中，监测对象创建事件可实现为控制器10启动事件。相应地，控制器10在启动过程中，可自动创建计算集群的资源对象对应的监测对象11。

对于资源对象来说，控制器10可将监测对象11订阅的资源对象的标识，写入该监测对象11的管控资源队列(Managed Resources)。具体地，控制器10可在启动过程中，获取监测对象创建实例；并从监测对象创建实例中获取监测对象11订阅的资源对象的标识；进一步，可将监测对象11订阅的资源对象的标识，写入该监测对象11的管控资源队列中。其中，资源对象的标识是指唯一标识一种资源对象的信息，可用资源对象的组别、版本号和资源类型(Group、Version and Kind，GVK)进行表示。其中，管控资源队列用于维护执行器(Reconciler)12订阅的事件对象。

执行器12为控制器10中用于响应资源事件，执行相应处理逻辑的组件。在本实施例中，控制器10可将监测对象11和执行器12进行绑定。其中，一个监测对象11可唯一绑定一个执行器12。执行器12可对监测对象11订阅的资源对象的事件进行响应，并执行相应处理逻辑。

在本申请实施例中，控制器10还可包括：动态管理组件13。动态管理组件13和监测对象11之间可通过监测对象11维护的事件通道(Generic Event)连接。其中，动态管理组件13是指控制器10中用于接收资源对象的事件的逻辑组件。

在本申请实施例中，控制器10可将监测对象11注册到动态管理组件13，并建立监测对象11与动态管理组件13之间的事件通道。控制器10还可将监测对象的标识与监测对象订阅的资源对象的标识(如GVK)之间的对应关系，写入动态管理组件13的订阅队列(Subscribers)(对应图1和图2中步骤2中“订阅”)。订阅队列可实现为以GVK为索引的监测对象列表，本质是监测对象及其订阅的资源对象倒排索引。在一个资源对象的事件发生时，动态管理组件13可通过订阅对象存储的监测对象的标识与监测对象订阅的资源对象的标识(如GVK)之间的对应关系，确定订阅该资源对象事件的目标监测对象；并将资源对象的事件提供给目标监测对象。具体地，动态管理组件13可通过监测对象11维护的事件通道，将资源对象事件提供给目标监测对象。

在本申请实施例中，动态管理组件13还可包括：事件总线。事件总线用于接收资源对象的事件(对应图1中步骤3和图2中步骤7)。在本申请实施例中，动态管理组件13接收的资源对象的事件可为外部事件，也可为计算集群内部资源事件。下面对本申请实施例提供的事件处理系统进行资源事件处理的过程进行示例性说明。

如图1所示，动态管控组件13可获取计算集群的资源对象的事件(简称为资源事件)(对应图1中步骤3和图2中步骤7)。具体地，动态管理组件13中的事件总线可接收计算集群的资源对象的事件。其中，事件总线可以订阅或发布形式实现。资源对象的事件可为外部事件，也可为计算集群的内部资源事件。其中，资源对象的事件可包括：资源对象的标识，用于表示发生事件的资源对象。

对于计算集群的外部事件，动态管控组件13可增设外部事件接口，用户可通过调用外部事件接口发送计算集群的外部事件。相应地，动态管理组件13可接收计算集群的外部事件，并从外部事件中获取外部事件对应的资源对；并确定外部事件为资源对象的事件(对应图1中步骤3和图2中步骤7的“外部事件”传递)。

对于计算集群的内部资源事件，如图2所示，可由动态通知组件14对API服务(APIServer)组件20进行监测。API服务组件20是容器集群管理系统中用于资源对象的增、删、查、改、盯(监听)的服务端，API服务组件20还可存储资源对象发生的事件，如资源对象删除、更新或增加等资源事件。数据存储在etcd数据库中，API服务组件20可通过etcd数据库中存储的数据的认证鉴权、缓存、API版本适配转换等一系列的功能。其中，etcd数据库是一个分布式的、高可用的、一致的Key-Value(键值对)存储数据库，主要用于共享配置和服务发现。

具体地，动态通知(Dynamic Informer)组件14可维护监测对象11的通知实例(Informer)。Informer是client-go中的核心工具包。Informer，其实就是一个带有本地缓存(Cache)和索引(Index)机制的、可以注册事件处理方法(EventHandler)的客户端(client)。使用Informer可减轻API服务组件20数据交互的压力，客户端对API服务组件20的数据的读取和监听操作都可通过本地Informer进行。

在本申请实施例中，监测对象的通知实例(Informer)是动态创建或删除的。对于上述图1步骤1中新创建的监测对象11，还可先判断是否存在监测对象对应的通知实例。在本申请实施例中，动态管理组件13可记录监测对象的标识与通知实例之间的对应关系。其中，监测对象的标识可以监测对象11对应的资源对象的标识进行表示。相应地，对于新创建的监测对象11可利用监测对象的标识在动态管理组件13记录的监测对象的标识与通知实例之间的对应关系中进行查询；若查询到监测对象的标识对应的通知实例，则控制器10可复用该通知实例。相应地，若未查询到监测对象的标识对应的通知实例，确定控制器10中不存在监测对象的通知实例；并可创建监测对象的通知实例(对应图2中步骤3中的新建Informer)。之后，可建立监测对象的通知实例与API服务组件20之间的长连接。具体地，建立通知实例的反射器与API服务组件20之间的长连接，并建立反射器对API服务组件20中监测对象对应的资源对象的监测。

当然，控制器10还可响应于监测对象删除事件，确定监测对象删除事件关联的待删除监测对象；在不存在订阅待删除监测对象对应的资源对象的事件的监测对象的情况下，删除待删除监测对象的通知实例(对应图2中步骤3中的“销毁Informer”)，实现通知实例的动态删除。

当然，在监测对象删除时，控制器10还可删除待删除监测对象的管控资源队列中订阅待删除监测对象对应的资源对象的事件的资源对象的标识；并从动态管理组件13的订阅队列中，删除待删除监测对象的标识与该监测对象订阅的资源对象的标识之间的对应关系，实现动态订阅(对应图1和图2步骤2中“取消订阅”)。

上述动态通知组件14基于容器集群管理平台的controller-runtime框架实现了通知实例(Informer)的动态创建和删除。这样，在云产品中新增CRD类型时，无需侵入控制器底层代码，只需针对新增CRD类型对应的资源对象动态创建监测对象和动态实例，即可实现对新增CRD类型对应的资源对象的资源事件的监听、响应和处理。

基于上述通知实例，监测对象的通知实例可监测API服务组件20中的资源对象事件；并在监测到有资源对象事件发生的情况下，获取发生的资源对象事件为资源对象的事件；进一步，可将资源对象的事件提供给动态管理组件13。

如图2所示，通知实例可包括：反射器(Reflector)、增量事件队列(Delta FIFO)和资源对象的索引缓存(Cache)。反射器可监测API服务组件20中的资源对象事件；并在监测到有资源对象件发生的情况下，获取发生的资源对象事件为资源对象的事件；将资源对象的事件存储至增量事件队列(对应图2中步骤5)；动态通知组件14用于根据资源对象的事件，对资源对象对应的索引缓存进行操作(对应图2中步骤6)。

具体地，Informer中的反射器可与API服务组件20建立连接，反射器使用List AndWatch的方法，调用Kubernetes List和Watch两种类型的API。反射器会先调用KubernetesList API获得某种资源的资源对象，然后调用Watch API监测资源对象；若资源对象的实例有创建、删除或更新等事件发生，反射器都会收到事件通知，即监测到发生资源对象的事件(对应图2中步骤4“list和watch”)。该资源事件可被存放在增量事件队列中。Informer会不断地从增量事件队列中读取资源事件，每读取一个资源事件，Informer就会判断这个资源事件的类型，然后创建或更新该资源类型对应的本地的索引缓存(Cache)。

如果事件类型是添加资源对象(Added)，Informer会通过Indexer的库把这个资源事件里的API对象保存到本地的缓存中，并为它创建索引；若为删除操作，则在本地缓存中删除该对象。对于增量缓存队列，还可将资源对象的事件提供给动态管理组件13(对应图2中步骤7“内部资源事件”传递)。

进一步，动态管理组件13可根据资源对象的事件，确定订阅该资源对象的事件的目标监测对象。可选地，动态管理组件13可从资源对象的事件中，获取资源对象的标识；并利用资源对象的标识查询订阅队列，以确定资源对象的标识对应的目标监测对象。具体地，动态管理组件13中的事件总线针对接收到的资源对象的事件；可从资源对象的事件中，获取资源对象的标识；并利用资源对象的标识查询订阅队列，以确定资源对象的标识对应的目标监测对象。

进一步，动态管理组件13可将资源对象的事件提供给目标监测对象(对应图1中步骤4和图2中步骤8)。具体地，动态管理组件13可通过监测对象11维护的事件通道，将资源对象的事件提供给目标监测对象。

在一些实施例中，资源对象的事件对应的用户自定义逻辑代码是按照controller-runtime支持的组织格式实现的，资源对象的事件在本申请实施例提供的控制器10传输过程中，中间过程不需要感知具体事件类型。因此，为了提高控制器10的通用性，动态管理组件13在将资源对象的事件提供给目标监测对象之前，可对资源对象的事件进行标准化处理，以得到具有标准化格式的资源对象的事件；进一步，可将具有标准化格式的资源对象的事件提供给目标监测对象(对应图1中步骤4和图2中步骤8)。具体地，上述将资源对象的事件进行标准化处理的过程可由动态管理组件13的事件总线进行执行。在得到具有标准化格式的资源对象的事件，动态管理组件13可将事件总线中具有标准化格式的资源对象的事件，通过目标监测对象维护的事件通道传输给目标监测对象。

对于目标监测对象，可将资源对象的事件提供给目标监测对象对应的执行器12(对应图1中步骤5)。在本申请一些实施例中，由于执行器12为用户侧基于controller-runtime架构支持的组织格式定义的处理逻辑，执行器12作为资源事件的处理单元需要感知资源事件的类型，而上述标准化格式的资源事件对资源事件进行了封装，因此，如图2所示，还可在监测对象11和执行器12之间设置事件解析组件15。其中，事件解析组件15用于将具有标准化格式的资源事件解析为执行器12可原始类型的资源事件。基于事件解析组件15，目标监测对象可将具有标准化格式的资源对象的事件发送到事件解析组件15。事件解析组件15可将具有标准化格式的资源对象的事件解析为原始类型的资源对象的事件；并将原始类型的资源对象的事件提供给目标监测对象对应的执行器12。

由于执行器12的资源对象处理能力是有限的，因此，在本申请实施例中，控制器10中还可设置工作队列16。在本申请实施例中，工作队列16可设置于监测对象11和执行器12之间。在一些实施例中，工作队列16可设置于监测对象11和事件解析组件15之间，事件解析组件15与执行器12相连接。在另一些实施例中，事件解析组件15可与监测对象11相连接；工作队列16连接于事件解析组件15与执行器12之间等等。

其中，工作队列16用于存储目标监测对象输出的资源对象的事件。控制器10可根据执行器12的数据处理能力，对工作队列16进行流量控制，以使工作队列16输出资源事件的速度与执行器12的处理速度相适配。例如，控制器10可对工作队列16输出资源事件进行延迟或限速处理等等。

在另一些实施例中，对于资源对象的用户来说，并非所有资源事件都需要执行器12进行处理。相应地，用户可根据自己的应用逻辑和需求，设计事件过滤器17。事件过滤器17用于维护资源事件过滤条件，并过滤满足资源事件过滤条件的资源事件。资源事件过滤条件可由资源对象的用户根据自己的应用需求进行灵活设置。

其中，事件过滤器17可设置于监测对象11和执行器12之间。对于目标监测对象输出的资源对象的事件，事件过滤器17可根据设定的事件过滤条件，对资源对象的事件进行过滤。若资源对象的事件不满足事件过滤条件，则将资源对象的事件提供给目标监测对象对应的执行器12。相应地，若资源对象的事件满足事件过滤条件，则舍弃该资源对象的事件。

对于上述目标监测对象输出的为标准化格式的资源事件的实施例来说，由于事件过滤器17是用户侧设计的，且考虑到事件解析组件15、事件过滤器17及执行器12的数据处理能力，对于具有工作队列16、事件解析组件15、事件过滤器17及执行器12的控制器10来说，目标监测对象输出的资源对象的事件可存储于工作队列16(对应图2中步骤9)，控制器10可对工作队列16进行流量控制。工作队列16输出的具有标准化格式的资源对象的事件，可由事件解析组件15解析为用户侧格式(对应图2中步骤10)；并将具有用户侧格式的资源对象的事件输出到事件过滤器17(对应图2中步骤11)。事件过滤器17可根据设定的事件过滤条件，对资源对象的事件进行过滤(对应图2中步骤12)。若资源对象的事件不满足事件过滤条件，则将资源对象的事件提供给目标监测对象对应的执行器12。

相应地，目标监测对象对应的执行器12可根据资源对象的事件，对该资源对象和/或目标监测对象对应的资源对象进行处理(对应图2中步骤13)。在本申请实施例中，为了便于描述和区分，将发生资源事件的资源对象定义为第一资源对象；并将订阅第一资源对象的目标监测对象对应的资源对象，定义为第二资源对象。

在本申请实施例中，不限定目标监测对象对应的执行器12根据第一资源对象的事件，对第一资源对象和/或第二资源对象进行处理的具体实施方式。具体地，执行器12可根据第一资源对象的事件，调用回调函数对第一资源对象和/或第二对象进行处理。其中，执行器12执行的处理逻辑可由回调函数决定。

在一些实施例中，执行器12可根据第一资源对象的事件，对第一资源对象和/或第二资源对象进行状态管理，以使第一资源对象和/或第二资源对象达到相应的期望状态。具体地，订阅第一资源对象的事件的目标监测对象对应的执行器12可获取第一资源对象和/或第二资源对象的当前状态和相应的期望状态；并控制API服务组件20将第一资源对象和/或第二资源对象的状态调整到相应的期望状态。

例如，在一些实施例中，第一资源对象的事件实现为第一资源对象的删除事件。订阅第一资源对象的事件的目标监测对象对应的执行器12，可根据第一资源对象的删除事件，对第二资源对象进行状态管理等。例如，第二资源对象的期望状态为对应5个第一资源对象；第一资源对象发生删除，导致订阅第一资源对象的第二资源对象的当前状态为对应4个第一资源对象，则执行器12可动态为第二资源对象创建新的第一资源对象等等。

在另一些实施例中，第一资源对象的事件实现为第一资源对象的故障事件，则订阅第一资源对象的事件的目标监测对象对应的执行器12可根据第一资源对象的故障事件，调整第一资源对象的状态，使得第一资源对象的状态达到正常状态等。例如，订阅第一资源对象的事件的目标监测对象对应的执行器12可重新创建第一资源对象等。当然，订阅第一资源对象的事件的目标监测对象对应的执行器12可根据第一资源对象的故障事件，将第二资源对象的状态调整为未就绪状态(unready)等等。或者，订阅第一资源对象的事件的目标监测对象对应的执行器12可根据第一资源对象的故障事件，重新创建第一资源对象；并在第一资源对象创建完成并达到就绪状态时，将第二资源对象的状态调整为就绪状态(ready)等。上述对资源对象进行处理的实施方式仅为示例性说明，并不构成限定。关于执行器12如何对资源对象进行处理的执行逻辑，具体由设定的回调函数决定。

本申请实施例提供的事件处理系统，提供了通用的资源事件引擎。主要增设了动态管理组件和资源对象的监测对象。其中，动态管理组件可获取计算集群的资源事件；并根据资源事件确定订阅该资源事件的目标监测对象；目标监测对象可将资源事件提供给对应的执行器，执行器根据资源事件对相关资源对象进行处理。该资源事件处理对资源事件的类型无要求，有助于提高资源事件引擎的通用性。本申请实施例提供的事件处理系统还可支持资源事件灵活订阅和发布，可支持非结构类型对象的资源事件及无ownerReference的资源对象的资源事件等。

本申请实施例提供的事件处理系统可应用于各种资源事件处理。例如，可应用于对应用状态进行管理等。其中，应用状态管理是PaaS平台核心功能之一，状态管理效率和资源消耗也直接影响到PaaS平台的稳定性和产品竞争力。在一些方案中，应用状态管理是基于开源的controller-runtime引擎实现。这种应用状态管理方式主要是基于“并发+轮询(Polling)”方式实现，可定制能力和扩展性较弱，同时由于定时并发执行机制，导致运行时资源消耗波动非常多，给系统带了稳定性问题。

对于PaaS平台部署的应用服务来说，可分解为多层资源。每层资源对应一种资源类型，每种资源类型具有多个资源对象，下一层级的资源对象为上一层级的子资源；上一层级的资源对象为上一层级的父资源。父资源可订阅子资源的事件。例如，图3和图4所示，应用服务可包括：产品层资源(Product Deploy)、集群层实例资源(Cluster Instance)、应用集合(APP Set)、应用实例(APP Instance)及工作负载(Workload)等5层嵌套的资源对象，则工作负载为应用实例的子资源，应用实例为应用集合的子资源。相应地，应用实例可订阅工作负载的资源事件，应用集合可订阅应用实例的资源事件等。其中，工作负载的子资源对象为容器组(如Pod等)。

在上述基于开源的controller-runtime引擎的“并发+轮询”方式的应用状态管理方案中，“轮询”是指每层资源对应的控制器按照设定的查询周期，周期性地查询API服务组件来监听是否有该层资源的资源事件发生；若查询到该层资源对象的资源事件，则触发控制器对该资源事件进行处理。“并发”是指为每层资源的多个资源对象启动多个进程并发查询API服务组件。如图3所示，对于这种“并发+轮询”方式，每层资源的多个资源对象的查询时间到达时，该层资源的控制器会从API服务组件拉取该层资源对象下所有的子资源，并遍历所有子资源的状态后，将子资源的状态结果汇总到父资源。因此，基于开源的controller-runtime引擎的“并发+轮询”方式本质是一个自顶向下检查机制，如果最底层的资源对象发生变化，顶层的资源对象感知到底层资源对象发生变化的时间较长，而且并发查询耗费CPU资源较高。

本申请实施例提供的事件处理系统，对应用状态检查模块进行了执行逻辑重构。如图4所示，针对多层嵌套的资源对象，底层资源对象发生变化时，底层资源的资源事件会通过上述图1和图2提供的事件处理系统，传递到上层父资源对应的监测对象，由父资源对应的监测对象的执行器对资源事件进行处理，可提高父资源对子资源的资源事件的感知速度，进而有助于提高对资源事件的响应速度，且资源消耗较低。

本申请发明人对基于开源的controller-runtime引擎的“并发+轮询”方式的应用状态管理方案，以及，利用本申请实施例提供的事件处理系统进行应用状态管理的方案进行性能测试。测试结果如图5和下表1所示。

表1性能测试对比

其中，图5为对基于开源的controller-runtime引擎的“并发+轮询”方式的应用状态管理方案，以及，利用本申请实施例提供的事件处理系统进行应用状态管理测试，得到的CPU使用量的情况。根据图5所示的CPU使用量情况，可知基于开源的controller-runtime引擎的“并发+轮询”方式的应用状态管理方案的CPU使用量在轮询周期达到时，CPU使用量较大，其它情况下CPU使用量较低，导致PaaS平台的CPU使用量波动较大，影响PaaS平台的稳定性。本申请实施例提供的事件处理系统进行应用状态管理时，CPU使用量比较平稳，且整体CPU消耗量较小。

上述表1是对对基于开源的controller-runtime引擎的“并发+轮询”方式的应用状态管理方案，以及，利用本申请实施例提供的事件处理系统进行应用状态管理测试时，在平均CPU使用量、内存使用量、对API服务组件的请求量、平均状态变化响应时间、以及新增CRD对研发成本投入整体对比，可知本申请实施例提供的事件处理系统的CPU消耗量较低，对API服务组件的请求量也较低，状态变化的平均响应时间较短。由于本申请实施例提供的事件处理系统的控制器中的Informer中会缓存资源对象信息，因此，本申请实施例提供的事件处理系统的内存开销会有所变大。

除了上述实施例提供的事件处理系统之外，本申请实施例还提供事件处理方法。下面对本申请实施例提供的事件处理方法进行示例性说明。

图6为本申请实施例提供的事件处理方法的流程示意图。如图6所示，事件处理方法主要包括以下步骤：

601、调用动态管理组件获取计算集群的第一资源对象的事件。

602、根据第一资源对象的事件，确定订阅第一资源对象的事件的目标监测对象。

603、将第一资源对象的事件提供给目标监测对象，以供目标监测对象将第一资源对象的事件提供给目标监测对象对应的执行器。

604、调用目标监测对象对应的执行器根据第一资源对象的事件，对第一资源对象和/或目标监测对象对应的第二资源对象进行处理。

本申请实施例提供的事件处理方法可由资源对象的控制器进行执行。其中，关于资源对象、资源对象的事件、资源对象的控制器、动态管理组件及资源对象对应的监测对象的描述，均可参见上述系统实施例的相关内容，在此不再赘述。

在本申请实施例中，控制器可实现事件订阅、事件通知和事件执行等资源事件处理。下面对控制器进行资源事件处理的方式进行示例性说明。

针对计算集群的资源对象，可动态创建和移除资源对象对应的监测对象(Watcher)。监测对象为资源对象在控制器中的逻辑体现。

具体地，可响应于监测对象创建事件，创建监测对象(Watcher)。在本申请实施例中，不限定监测对象创建事件的具体实现形态。在一些实施例中，监测对象创建事件可实现为控制器启动事件。相应地，控制器在启动过程中，可自动创建计算集群的资源对象对应的监测对象。

对于资源对象来说，可将监测对象订阅的资源对象的标识，写入该监测对象的管控资源队列(Managed Resources)。其中，管控资源队列用于维护执行器(Reconciler)订阅的事件对象。具体地，可在启动过程中，获取监测对象创建实例；并从监测对象创建实例中获取监测对象订阅的资源对象的标识；进一步，可将监测对象订阅的资源对象的标识，写入该监测对象的管控资源队列中。其中，资源对象的标识是指唯一标识一种资源对象的信息，可用资源对象的组别、版本号和资源类型(Group、Version and Kind，GVK)进行表示。

执行器为控制器中用于响应资源事件，执行相应处理逻辑的组件。在本实施例中，控制器可将监测对象和执行器进行绑定。其中，一个监测对象可唯一绑定一个执行器。执行器可对监测对象订阅的资源对象的事件进行响应，并执行相应处理逻辑。

在本申请实施例中，控制器还可包括：动态管理组件。动态管理组件和监测对象之间可通过监测对象维护的事件通道(Generic Event)连接。其中，动态管理组件是指控制器中用于接收资源对象的事件的逻辑组件。

在本申请实施例中，控制器可将监测对象注册到动态管理组件，并建立监测对象动态管理组件之间的事件通道。控制器还可将监测对象订阅的资源对象的标识(如GVK)与监测对象的标识与之间的对应关系，写入动态管理组件的订阅队列(Subscribers)。订阅队列可实现为以GVK为索引的监测对象列表，本质是监测对象及其订阅的资源对象倒排索引。在一个资源对象的事件发生时，动态管理组件可通过订阅对象存储的监测对象的标识与监测对象订阅的资源对象的标识(如GVK)之间的对应关系，确定订阅该资源对象事件的目标监测对象；并将资源对象的事件提供给目标监测对象。具体地，动态管理组件可通过监测对象维护的事件通道，将资源对象事件提供给目标监测对象。

在本申请实施例中，动态管理组件还可包括：事件总线。事件总线用于接收资源对象的事件。在本申请实施例中，动态管理组件接收的资源对象的事件可为外部事件，也可为计算集群内部资源事件。下面对本申请实施例提供的事件处理系统进行资源事件处理的过程进行示例性说明。

如图6步骤601所示，可调用动态管理组件获取计算集群的资源对象的事件(简称为资源事件)。具体地，可调用动态管理组件中的事件总线接收计算集群的资源对象的事件。其中，事件总线可以订阅或发布形式实现。资源对象的事件可为外部事件，也可为计算集群的内部资源事件。其中，资源对象的事件可包括：资源对象的标识，用于表示发生事件的资源对象。

对于计算集群的外部事件，动态管控组件可增设外部事件接口，用户可通过调用外部事件接口发送计算集群的外部事件。对于计算集群的内部资源事件，可由控制器的动态通知组件对API服务(API Server)组件进行监测。

具体地，动态通知(Dynamic Informer)组件可维护监测对象的通知实例(Informer)。在本申请实施例中，监测对象的通知实例(Informer)是动态创建或删除的。对于新创建的监测对象，还可先判断是否存在监测对象对应的通知实例。在本申请实施例中，可调用动态管理组件记录监测对象的标识与通知实例之间的对应关系。其中，监测对象的标识可以监测对象对应的资源对象的标识进行表示。相应地，对于新创建的监测对象，可利用监测对象的标识在动态管理组件记录的监测对象的标识与通知实例之间的对应关系中进行查询；若查询到监测对象的标识对应的通知实例，则可复用该通知实例。相应地，若未查询到监测对象的标识对应的通知实例，确定控制器中不存在监测对象的通知实例；并可创建监测对象的通知实例。之后，可建立监测对象的通知实例与API服务组件之间的长连接。具体地，建立通知实例的反射器与API服务组件之间的长连接，并建立通知实例中的反射器对API服务组件中监测对象对应的资源对象的监测。

当然，还可响应于监测对象删除事件，确定监测对象删除事件关联的待删除监测对象；在不存在订阅待删除监测对象对应的资源对象的事件的监测对象的情况下，删除待删除监测对象的通知实例，实现通知实例的动态删除。

当然，在监测对象删除时，还可删除待删除监测对象的管控资源队列中订阅待删除监测对象对应的资源对象的事件的资源对象的标识；并从动态管理组件的订阅队列中，删除待删除监测对象的标识与该监测对象订阅的资源对象的标识之间的对应关系，实现动态订阅。

上述动态通知组件基于容器集群管理平台的controller-runtime框架实现了通知实例(Informer)的动态创建和删除。这样，在云产品中新增CRD类型时，无需侵入控制器底层代码，只需针对新增CRD类型对应的资源对象动态创建监测对象和动态实例，即可实现对新增CRD类型对应的资源对象的资源事件的监听、响应和处理。

基于上述通知实例，可调用监测对象的通知实例监测API服务组件中的资源对象事件；并在监测到有资源对象事件发生的情况下，获取发生的资源对象事件为资源对象的事件；进一步，可将资源对象的事件提供给动态管理组件。相应地，可调用动态管理组件获取资源对象的事件。

进一步，在步骤602中，可根据资源对象的事件，确定订阅该资源对象的事件的目标监测对象。可选地，可从资源对象的事件中，获取资源对象的标识；并利用资源对象的标识查询订阅队列，以确定资源对象的标识对应的目标监测对象。

进一步，在步骤603中，可调用动态管理组件可将资源对象的事件提供给目标监测对象。具体地，可通过监测对象维护的事件通道，将资源对象的事件提供给目标监测对象。

在一些实施例中，为了提高控制器间对各类资源事件处理的通用性，在将资源对象的事件提供给目标监测对象之前，可调用动态管理组件对资源对象的事件进行标准化处理，以得到具有标准化格式的资源对象的事件；进一步，可将具有标准化格式的资源对象的事件提供给目标监测对象。

对于目标监测对象，可将资源对象的事件提供给目标监测对象对应的执行器。在本申请一些实施例中，由于执行器为资源事件的具体处理单元，需要感知资源事件的具体类型。因此，还可在监测对象和执行器之间设置事件解析组件。相应地，可调用事件解析组件将具有标准化格式的资源事件解析为执行器支持的原始类型的资源事件。基于事件解析组件，目标监测对象可将具有标准化格式的资源对象的事件发送到事件解析组件；并调用事件解析组件可将具有标准化格式的资源对象的事件解析为原始类型；进一步，将原始类型的资源对象的事件提供给目标监测对象对应的执行器。

由于执行器的资源对象处理能力是有限的，因此，在本申请实施例中，控制器中还可设置工作队列。工作队列用于存储目标监测对象输出的资源对象的事件。控制器可根据执行器的数据处理能力，对工作队列进行流量控制，以使工作队列输出资源事件的速度与执行器的处理速度相适配。

在另一些实施例中，对于资源对象的用户来说，并非所有资源事件都需要执行器进行处理。相应地，用户可根据自己的应用逻辑和需求，设计事件过滤器。事件过滤器用于维护资源事件过滤条件，并过滤满足资源事件过滤条件的资源事件。资源事件过滤条件可由资源对象的用户根据自己的应用需求进行灵活设置。基于此，在目标监测对象将资源对象的事件提供给执行器之前，可调用事件过滤器可根据设定的事件过滤条件，对资源对象的事件进行过滤。若资源对象的事件不满足事件过滤条件，则将资源对象的事件提供给目标监测对象对应的执行器。相应地，若资源对象的事件满足事件过滤条件，则舍弃该资源对象的事件。

进一步，在步骤604中，可调用目标监测对象对应的执行器根据资源对象的事件，对该资源对象和/或目标监测对象对应的资源对象进行处理。在本申请实施例中，为了便于描述和区分，将发生资源事件的资源对象定义为第一资源对象；并将订阅第一资源对象的目标监测对象对应的资源对象，定义为第二资源对象。

在本申请实施例中，不限定目标监测对象对应的执行器根据第一资源对象的事件，对第一资源对象和/或第二资源对象进行处理的具体实施方式。具体地，可调用执行器可根据第一资源对象的事件，调用回调函数对第一资源对象和/或第二对象进行处理。其中，执行器执行的处理逻辑可由回调函数决定。关于执行器根据资源对象的事件，对该资源对象和/或目标监测对象对应的资源对象进行处理的具体实施方式可参见上述系统实施例的相关内容，在此不再赘述。

在本实施例中，控制器中增设动态管理组件和资源对象的监测对象，在事件处理时，可调用动态管理组件获取计算集群的资源事件；并根据资源事件确定订阅该资源事件的目标监测对象；目标监测对象可将资源事件提供给对应的执行器；进一步，可调用执行器根据资源事件对相关资源对象进行处理。该资源事件处理对资源事件的类型无要求，有助于提高资源事件引擎的通用性。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤601和602的执行主体可以为设备A；又比如，步骤601的执行主体可以为设备A，步骤602的执行主体可以为设备B；等等。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如601、602等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。

相应地，本申请实施例还提供一种存储有计算机指令的计算机可读存储介质，当计算机指令被一个或多个处理器执行时，致使一个或多个处理器执行上述事件处理方法中的步骤。

本申请实施例还提供一种计算机程序产品，包括：计算机程序。该计算机程序被一个或多个处理器执行时，致使一个或多个处理器执行上述事件处理方法中的步骤。在本申请实施例中，不限定计算机程序产品的具体实现形态。在一些实施例中，计算机程序产品可实现为容器集群管理平台中资源对象的控制器或者控制器的事件引擎等。

图7为本申请实施例提供的计算设备的结构示意图。如图7所示，该计算设备包括：存储器70a和处理器70b。其中，存储器70a，用于存储计算机程序。

处理器耦合至存储器，用于执行计算机程序以用于：调用动态管理组件获取计算集群的第一资源对象的事件；根据第一资源对象的事件，确定订阅第一资源对象的事件的目标监测对象；将第一资源对象的事件提供给目标监测对象，以供目标监测对象将第一资源对象的事件提供给目标监测对象对应的执行器；调用目标监测对象对应的执行器根据第一资源对象的事件，对第一资源对象和/或目标监测对象对应的第二资源对象进行处理。

可选地，处理器70b在确定订阅第一资源对象的事件的目标监测对象时，具体用于：从第一资源对象的事件中，获取第一资源对象的标识；利用第一资源对象的标识查询动态管理组件的订阅队列存储的资源对象的标识与订阅资源对象的监测对象之间的对应关系，以确定第一资源对象的标识对应的目标监测对象。

可选地，处理器70b还用于：响应于监测对象创建事件，创建第一监测对象；将第一监测对象订阅的资源对象的标识写入第一监测对象的管控资源队列；建立第一监测对象与动态管理组件之间的事件通道；将第一监测对象订阅的资源对象的标识与第一监测对象之间的对应关系写入订阅队列。

在一些实施例中，处理器70b在调用动态管理组件获取计算集群的第一资源对象的事件时，具体用于：调用动态通知组件维护的第一资源对象的通知实例监测API服务组件中的资源对象事件；在监测到有资源对象件发生的情况下，获取发生的资源对象事件为第一资源对象的事件；调用第一资源对象对应的通知实例将第一资源对象的事件提供给动态管理组件；以及，调用动态管理组件接收第一资源对象的事件。

在另一些实施例中，处理器70b在调用动态管理组件获取计算集群的第一资源对象的事件时，具体用于：调用动态管理组件接收计算集群的外部事件；从外部事件中获取外部事件对应的资源对象作为第一资源对象；并确定外部事件为第一资源对象的事件。

在一些实施例中，处理器70b还用于：在控制器不存在第一监测对象的通知实例的情况下，创建第一监测对象的通知实例；建立第一监测对象的通知实例与API服务组件之间的长连接；建立第一监测对象的通知实例中的反射器对API服务组件中第一监测对象对应的资源对象的监测。

可选地，处理器70b还用于：利用第一监测对象的标识在动态管理组件记录的监测对象的标识与通知实例之间的对应关系中进行查询；若未查询到第一监测对象的标识对应的通知实例，确定控制器不存在第一监测对象对应的资源对象的标识。

在本申请实施例中，处理器70b还用于：响应于监测对象删除事件，确定监测对象删除事件对应的待删除的第二监测对象；删除第二监测对象的管控资源队列中第二监测对象订阅的资源对象的标识；从订阅队列中删除第二监测对象订阅的资源对象的标识与第二监测对象之间的对应关系。

可选地，处理器70b还用于：从动态通知组件中删除第二监测对象的通知实例；停止第二监测对象的通知实例对第二监测对象对应的资源对象的监测。

可选地，处理器70b还用于：在目标监测对象将第一资源对象的事件提供给目标监测对象对应的执行器之前，调用事件过滤器根据设定的事件过滤条件，对第一资源对象的事件进行过滤；若第一资源对象的事件不满足事件过滤条件，则将第一资源对象的事件提供给目标监测对象对应的执行器。

可选地，处理器70b还用于：在将第一资源对象的事件提供给目标监测对象之前，调用动态管理组件对第一资源对象的事件进行标准化处理，以得到第一资源对象的事件的标准化格式；将具有标准化格式的第一资源对象的事件提供给目标监测对象。

可选地，处理器70b还用于：在目标监测对象将第一资源对象的事件提供给目标监测对象对应的执行器之前，调用目标监测对象将具有标准化描述格式的第一资源对象的事件存储至工作队列；调用事件解析组件从工作队列中获取具有标准化格式的第一资源对象的事件；并将具有标准化格式的第一资源对象的事件解析为原始类型的事件；将第一资源对象的原始类型的事件提供给目标监测对象的执行器。相应地，处理器70b在对第一资源对象和/或目标监测对象对应的第二资源对象进行处理时，具体用于：调用目标监测对象的执行器根据第一资源对象的原始类型的事件，对第一资源对象和/或第二资源对象进行处理。

在一些可选实施方式中，如图7所示，该计算设备还可以包括：通信组件70c和电源组件70d等可选组件。图7中仅示意性给出部分组件，并不意味着计算设备必须包含图7所示全部组件，也不意味着计算设备只能包括图7所示组件。

本实施例提供的计算设备，可部署资源对象的控制器，并在控制器中增设动态管理组件和资源对象的监测对象，在事件处理时，可调用动态管理组件获取计算集群的资源事件；并根据资源事件确定订阅该资源事件的目标监测对象；目标监测对象可将资源事件提供给对应的执行器；进一步，可调用执行器根据资源事件对相关资源对象进行处理。该资源事件处理对资源事件的类型无要求，有助于提高资源事件引擎的通用性。

在本申请实施例中，存储器用于存储计算机程序，并可被配置为存储其它各种数据以支持在其所在设备上的操作。其中，处理器可执行存储器中存储的计算机程序，以实现相应控制逻辑。存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

在本申请实施例中，处理器可以为任意可执行上述方法逻辑的硬件处理设备。可选地，处理器可以为中央处理器(Central Processing Unit，CPU)、图形处理器(GraphicsProcessing Unit，GPU)或微控制单元(Microcontroller Unit，MCU)；也可以为现场可编程门阵列(Field-Programmable Gate Array，FPGA)、可编程阵列逻辑器件(ProgrammableArray Logic，PAL)、通用阵列逻辑器件(General Array Logic，GAL)、复杂可编程逻辑器件(Complex Programmable Logic Device，CPLD)等可编程器件；或者为先进精简指令集(RISC)处理器(Advanced RISC Machines，ARM)或系统芯片(System on Chip，SOC)等等，但不限于此。

在本申请实施例中，通信组件被配置为便于其所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如WiFi，2G或3G，4G，5G或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件还可基于近场通信(NFC)技术、射频识别(RFID)技术、红外数据协会(IrDA)技术、超宽带(UWB)技术、蓝牙(BT)技术或其他技术来实现。

在本申请实施例中，电源组件被配置为其所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

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

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

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

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

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机的存储介质为可读存储介质，也可称为可读介质。可读存储介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (14)

1.一种事件处理系统，其特征在于，包括：控制器；所述控制器包括：动态管理组件、执行器和计算集群的资源对象对应的监测对象；

所述动态管理组件，用于获取计算集群的第一资源对象的事件；并根据所述第一资源对象的事件，确定订阅所述第一资源对象的事件的目标监测对象；将所述第一资源对象的事件提供给所述目标监测对象；所述目标监测对象将所述第一资源对象的事件提供给所述目标监测对象对应的执行器；

所述目标监测对象对应的执行器用于根据所述第一资源对象的事件，对所述第一资源对象和/或所述目标监测对象对应的第二资源对象进行处理。

2.根据权利要求1所述的系统，其特征在于，所述控制器还包括：动态通知组件；所述动态通知组件用于维护所述目标监测对象的通知实例；所述第一资源对象的通知实例用于监测API服务组件中的资源对象事件；并在监测到有资源对象件发生的情况下，获取发生的资源对象事件为所述第一资源对象的事件，以及将所述第一资源对象的事件提供给所述动态管理组件；

和/或，

所述动态管理组件，还用于：接收所述计算集群的外部事件；从所述外部事件中获取所述外部事件对应的资源对象作为所述第一资源对象；以及，确定所述外部事件为所述第一资源对象的事件。

3.根据权利要求1所述的系统，其特征在于，所述控制器还用于：

响应于监测对象创建事件，创建第一监测对象；

将所述第一监测对象订阅的资源对象的标识写入所述第一监测对象的管控资源队列；

建立所述第一监测对象与所述动态管理组件之间的事件通道；

将所述第一监测对象的标识与所述第一监测对象订阅的资源对象的标识之间的对应关系写入所述动态管理组件的订阅队列。

4.根据权利要求3所述的系统，其特征在于，所述控制器还用于：

在所述控制器不存在所述第一监测对象的通知实例的情况下，创建所述第一监测对象的通知实例；

建立所述第一监测对象的通知实例与API服务组件之间的长连接；

建立所述第一监测对象的通知实例中的反射器对所述API服务组件中所述第一监测对象对应的资源对象的监测。

5.一种事件处理方法，其特征在于，包括：

调用动态管理组件获取计算集群的第一资源对象的事件；

根据所述第一资源对象的事件，确定订阅所述第一资源对象的事件的目标监测对象；

将所述第一资源对象的事件提供给所述目标监测对象，以供所述目标监测对象将所述第一资源对象的事件提供给所述目标监测对象对应的执行器；

调用所述目标监测对象对应的执行器根据所述第一资源对象的事件，对所述第一资源对象和/或所述目标监测对象对应的第二资源对象进行处理。

6.根据权利要求5所述的方法，其特征在于，所述根据所述第一资源对象的事件，确定订阅所述第一资源对象的事件的目标监测对象，包括：

从所述第一资源对象的事件中，获取所述第一资源对象的标识；

利用所述第一资源对象的标识查询所述动态管理组件的订阅队列存储的资源对象的标识与订阅所述资源对象的监测对象之间的对应关系，以确定所述第一资源对象的标识对应的目标监测对象。

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

响应于监测对象创建事件，创建第一监测对象；

将所述第一监测对象订阅的资源对象的标识写入所述第一监测对象的管控资源队列；

建立所述第一监测对象与所述动态管理组件之间的事件通道；

将所述第一监测对象订阅的资源对象的标识与所述第一监测对象之间的对应关系写入所述订阅队列。

8.根据权利要求5所述的方法，其特征在于，所述调用动态管理组件获取计算集群的第一资源对象的事件，包括：

调用动态通知组件维护的所述第一资源对象的通知实例监测API服务组件中的资源对象事件；

在监测到有资源对象件发生的情况下，获取发生的资源对象事件为所述第一资源对象的事件；

调用所述第一资源对象对应的通知实例将所述第一资源对象的事件提供给所述动态管理组件；

调用所述动态管理组件接收所述第一资源对象的事件。

9.根据权利要求5所述的方法，其特征在于，所述调用动态管理组件获取计算集群的第一资源对象的事件，包括：

调用所述动态管理组件接收所述计算集群的外部事件；

从所述外部事件中获取所述外部事件对应的资源对象作为所述第一资源对象；

确定所述外部事件为所述第一资源对象的事件。

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

在控制器不存在所述第一监测对象的通知实例的情况下，创建所述第一监测对象的通知实例；

建立所述第一监测对象的通知实例与API服务组件之间的长连接；

建立所述第一监测对象的通知实例中的反射器对所述API服务组件中所述第一监测对象对应的资源对象的监测。

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

利用所述第一监测对象的标识在所述动态管理组件记录的监测对象的标识与通知实例之间的对应关系中进行查询；

若未查询到所述第一监测对象的标识对应的通知实例，确定所述控制器不存在第一监测对象对应的资源对象的标识。

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

响应于监测对象删除事件，确定所述监测对象删除事件对应的待删除的第二监测对象；

删除所述第二监测对象的管控资源队列中所述第二监测对象订阅的资源对象的标识；

从所述订阅队列中删除所述第二监测对象订阅的资源对象的标识与所述第二监测对象之间的对应关系；

从动态通知组件中删除所述第二监测对象的通知实例；

停止所述第二监测对象的通知实例对所述第二监测对象对应的资源对象的监测。

13.一种计算设备，其特征在于，包括：存储器和处理器；其中，所述存储器，用于存储计算机程序；

所述处理器耦合至所述存储器，用于执行所述计算机程序以用于执行权利要求5-12任一项所述方法中的步骤。

14.一种存储有计算机指令的计算机可读存储介质，其特征在于，当所述计算机指令被一个或多个处理器执行时，致使所述一个或多个处理器执行权利要求5-12任一项所述方法中的步骤。

Images