一种应用程序的更新方法、装置、电子设备和存储介质

技术领域

本发明涉及集群技术领域，尤其涉及一种应用程序的更新方法、装置、电子设备和存储介质。

背景技术

Kubernetes(即k8s)组件作为一种管理容器化应用程序的开源系统，被广泛应用于集群的应用部署中，而配置字典则是k8s组件中已部署完成的应用程序常用的配置文件加载方式。

配置字典虽然支持热更新功能，但是绝大多数的应用程序均不具备检测配置字典更新的功能，因此即使对配置字典进行了变更，应用程序仍然无法做出即时响应；现有技术为了解决上述问题，通常会在部署应用程序的容器组时，同时启动业务容器和边车容器，由边车容器获取映射到业务容器内的配置字典。

然而，在部署边车容器之后，仍然需要应用程序能够接收信号并进行热更新，但大部分业务应用并不支持该功能，同时业务应用的更新依赖于挂载到应用的配置文件的更新，而配置文件的更新依赖于与之对应的配置字典的更新；而当配置字典发生变化时，配置文件的更新并不是即时生效，存在较长的等待时间，由此常常导致业务应用的容器组出现更新延迟。

发明内容

本发明提供了一种应用程序的更新方法、装置、电子设备及存储介质，以解决应用程序的配置数据更新不及时的问题。

根据本发明的一方面，提供了一种应用程序的更新方法，包括：

创建自定义控制器并为所述自定义控制器分配自定义资源；其中，所述自定义资源用于记录配置字典与应用程序的配置关系；

通过所述自定义控制器根据所述配置关系监测所述配置字典的更新状态，并在监测到所述配置字典的更新信息时，对所述应用程序进行配置更新；

通过管理控制器根据监测到的所述应用程序的配置更新信息，执行所述应用程序的容器组更新操作。

在创建自定义控制器并为所述自定义控制器分配自定义资源之后，还包括：响应于获取到所述自定义控制器的配置关系更新请求，更新所述自定义资源记录的配置字典与应用程序的配置关系。由此基于配置关系更新请求可以根据用户不同的监测需求，调整自定义控制器的监测对象，扩展自定义控制器的监测范围。

所述创建自定义控制器并为所述自定义控制器分配自定义资源，具体包括：遍历集群中的各个应用程序，并获取各所述应用程序的监测类型；其中，所述监测类型包括主动监测应用、被动监测应用以及无监测应用；若确定当前应用程序为主动监测应用，将当前应用程序不作为所述自定义控制器的监测对象；若确定当前应用程序为被动监测应用或无监测应用，将当前应用程序作为所述自定义控制器的监测对象。如果当前应用程序为主动监测应用，其代码逻辑本身具备配置文件的检测功能，不需要将其纳入自定义控制器的监测范围，避免了冗余检测的出现；如果当前应用程序为无监测应用，则将该应用程序作为监测对象，以及时完成该应用程序的配置更新；如果当前应用程序为被动监测应用，在管理节点中创建的自定义控制器，不但可以通过k8s组件服务接口及时获知配置字典更新信息，进而完成应用程序的配置数据的实时更新，同时释放了集群中的多个边车容器，极大地节省了集群资。

所述若确定当前应用程序为被动监测应用或无监测应用，将当前应用程序作为所述自定义控制器的监测对象，具体包括：若确定当前应用程序为被动监测应用，且当前应用程序的平均被动监测时间大于等于所述自定义控制器的平均监测时间，将当前应用程序作为所述自定义控制器的监测对象，并释放当前应用程序对应的原始监测工具。如果平均被动监测时间较长，则将当前应用程序作为自定义控制器的监测对象，以进一步提高当前应用程序的配置更新效率；如果平均被动监测时间较短，则不将当前应用程序作为自定义控制器的监测对象，确保当前应用程序保持原本较高的配置更新效率；如果平均被动监测时间等于平均监测时间，同样可以将当前应用程序作为自定义控制器的监测对象，由此在保持配置更新效率不变的前提下，释放边车容器占据的集群资源。

在确定当前应用程序为主动监测应用之后，还包括：若确定当前应用程序的平均主动监测时间大于等于第一预设时间，或者当前应用程序的实时性等级大于等于第一预设等级，将当前应用程序作为所述自定义控制器的监测对象；若检测到所述当前应用程序发起的监测请求，不响应所述当前应用程序发起的监测请求。满足了当前应用程序配置数据的实时更新需求。所述将当前应用程序不作为所述自定义控制器的监测对象，包括：若确定当前应用程序的平均主动监测时间小于第一预设时间，且当前应用程序的实时性等级小于第一预设等级，将当前应用程序不作为所述自定义控制器的监测对象。基于当前应用程序自身具备的主动检测功能执行配置文件的更新操作即可，既减少了自定义控制器的监测对象数量，又避免了冗余检测的出现。

所述第一预设时间大于所述自定义控制器的平均监测时间。将第一预设时间设置为大于平均监测时间，由此对于耗时较短的应用程序，即使其检测耗时略大于平均监测时间，也同样不作为自定义控制器的监测对象，避免冗余检测的出现；而对于耗时较长的应用程序，则将其作为自定义控制器的监测对象，以此大幅度提高当前应用程序的配置数据更新效率。

所述创建自定义控制器并为所述自定义控制器分配自定义资源，包括：创建多个不同的自定义控制器并为各所述自定义控制器分配不同的自定义资源；其中，各所述自定义控制器分别与不同监测类型的应用程序相匹配；主动监测应用、被动监测应用和无监测应用的监测优先级依次递增；若检测到多个自定义控制器的监测请求，根据各所述自定义控制器分别对应的监测类型的监测优先级，依次响应各所述自定义控制器的监测请求。根据不同应用程序的监测类型不同，为不同的自定义控制器设置不同的响应优先级，在同时检测到多个监测请求时，既能确保不具备任何更新检测功能的无监测应用的优先响应，也可以确保对响应耗时较长的被动监测应用的次级响应，最大程度的确保了集群中所有应用程序的配置数据的及时更新。

根据本发明的另一方面，提供了一种应用程序的更新装置，包括：

控制器创建模块，用于创建自定义控制器并为所述自定义控制器分配自定义资源；其中，所述自定义资源用于记录配置字典与应用程序的配置关系；

配置更新执行模块，用于通过所述自定义控制器根据所述配置关系监测所述配置字典的更新状态，并在监测到所述配置字典的更新信息时，对所述应用程序进行配置更新；

容器组更新执行模块，用于通过管理控制器根据监测到的所述应用程序的配置更新信息，执行所述应用程序的容器组更新操作。

根据本发明的另一方面，提供了一种电子设备，所述电子设备包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行本发明任一实施例所述的应用程序的更新方法。

根据本发明的另一方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，所述计算机指令用于使处理器执行时实现本发明任一实施例所述的应用程序的更新方法。

本发明实施例的技术方案，通过创建完成的自定义控制器监测配置字典的更新，进而完成应用程序的配置更新，再通过管理控制器基于监测到的应用程序的配置更新信息，执行应用程序的容器组更新操作，相比于在容器组中设置边车容器，本申请通过自定义控制器对配置字典的更新监测以及应用程序的配置更新，不需要应用程序具备任何主动或者被动检测功能，具有较好的普遍适用性，同时，基于自定义控制器的配置字典监测，提高了应用程序的配置更新效率，此外，相比于在每个容器组中均需要设置边车容器，本申请仅需要在管理节点中设置一个或有限数量的几个自定义控制器，极大地降低了对集群资源的占用。

应当理解，本部分所描述的内容并非旨在标识本发明的实施例的关键或重要特征，也不用于限制本发明的范围。本发明的其它特征将通过以下的说明书而变得容易理解。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1A是根据本发明实施例一提供的一种应用程序的更新方法的流程图；

图1B是根据本发明实施例一提供的一种管理节点的结构示意图；

图2是根据本发明实施例二提供的一种应用程序的更新方法的流程图；

图3是根据本发明实施例三提供的一种应用程序的更新方法的流程图；

图4是根据本发明实施例四提供的一种应用程序的更新装置的结构示意图；

图5是实现本发明实施例的应用程序的更新方法的电子设备的结构示意图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例一

图1A为本发明实施例一提供的一种应用程序的更新方法的流程图，本实施例可适用于对k8s组件中部署的应用程序进行配置数据更新，该方法可以由应用程序的更新装置来执行，该应用程序的更新装置可以采用硬件和/或软件的形式实现，该应用程序的更新装置配置于集群中的管理节点，典型的，可以配置于服务器集群中的管理服务器，该集群包括至少一个管理节点以及至少一个工作节点。如图1A所示，该方法包括：

S101、创建自定义控制器并为所述自定义控制器分配自定义资源；其中，所述自定义资源用于记录配置字典与应用程序的配置关系。

自定义控制器可以基于用户发出的控制器创建请求创建，以图1B为例，当管理节点通过k8s组件的服务接口(即kube-APIserver)获取到用户发出的控制器创建请求时，在管理节点中创建自定义控制器，上述自定义控制器区别于k8s组件中管理控制器(即controller-manager)内的原生控制器，其用于监听用户自定义资源的变化；自定义资源是k8s组件为用户或者特定功能开放的可扩展资源，本发明实施例中的自定义资源包括数据存储模块(即ETCD模块)中的存储资源；其中，ETCD模块是k8s组件中用于数据的持久化存储的功能模块。

本发明实施例中的应用程序是通过k8s组件部署在集群中的应用，该应用可能部署在集群中的一个或多个电子设备中；配置字典是k8s组件中的一种资源名称，其以键值对的形式存储了配置数据；配置字典用于向应用程序所在的容器组中注入配置数据；配置字典对象中存储的数据可以被配置字典类型的卷引用，并由容器组中运行的容器化应用使用；配置字典与应用程序一一匹配，不同电子设备中相同的应用程序对应相同的配置字典；其中，容器组是k8s组件中的最小调度单元，一个应用程序对应一个容器组，一个容器内可以包括多个容器，同一个容器组内的容器共享网络栈和文件系统。

当管理节点获取到用户发出的控制器创建请求时，如果该控制器创建请求中不包括配置字典与应用程序的配置关系，仅为该自定义控制器分配自定义资源即可，该自定义资源中暂时不记录任何信息；如果该控制器创建请求中已包括配置字典与应用程序的配置关系，在为该自定义控制器分配自定义资源之后，即可通过自定义资源中记录相应的配置关系；其中，配置关系反映了该自定义控制器用于监测集群中部署的哪些应用程序，以及与该应用程序匹配的配置字典。

可选的，在本发明实施例中，在创建自定义控制器并为所述自定义控制器分配自定义资源之后，还包括：响应于获取到所述自定义控制器的配置关系更新请求，更新所述自定义资源记录的配置字典与应用程序的配置关系。每个自定义控制器的监测对象，不但可以在创建时基于创建请求中包括的配置关系设置完成，还可以通过用户后续发出的配置关系更新请求进行修改，由此基于配置关系更新请求可以根据用户不同的监测需求，调整自定义控制器的监测对象，扩展自定义控制器的监测范围。

S102、通过所述自定义控制器根据所述配置关系监测所述配置字典的更新状态，并在监测到所述配置字典的更新信息时，对所述应用程序进行配置更新。

当管理节点在获取到配置字典更新请求时，通过上述服务接口，将本次获取到的配置字典信息，与数据存储模块中该配置字典的前次版本进行比对，并在确定存在更新时，将更新内容存储到数据存储模块中；自定义控制器根据自定义资源中记录的配置关系，通过服务接口对数据存储模块中指定的一个或多个配置字典进行更新监测；当自定义控制器检测到上述某个配置字典存在更新时，同样根据配置关系监吗，对相应的应用程序进行配置数据更新，也即通过配置字典将配置数据注入该应用程序中。

S103、通过管理控制器根据监测到的所述应用程序的配置更新信息，执行所述应用程序的容器组更新操作。

管理控制器通过服务接口监测到上述应用程序的配置数据更新时，依次重启该应用程序所在的容器组中的各个容器，以确保该应用程序所在的每台电子设备中均保持至少一个容器处于运行状态，确保提供完整的对外服务，而在各个容器重启之后，即完成了本次更新操作。

可选的，在本发明实施例中，所述创建自定义控制器并为所述自定义控制器分配自定义资源，具体包括：遍历集群中的各个应用程序，并获取各所述应用程序的监测类型；其中，所述监测类型包括主动监测应用、被动监测应用以及无监测应用；若确定当前应用程序为主动监测应用，将当前应用程序不作为所述自定义控制器的监测对象；若确定当前应用程序为被动监测应用或无监测应用，将当前应用程序作为所述自定义控制器的监测对象。

具体的，自定义控制器还可以由管理节点自行创建，例如，在集群部署完成首次启动时，管理节点通过设置自定义控制器管理集群中各个应用程序的配置更新监测；首先，管理节点遍历集群中的全部应用程序，包括安装于管理节点以及工作节点中的应用程序，根据应用程序的监测类型不同，判断是否将当前应用程序作为监测对象；其中，主动监测应用，即应用程序自身具备对配置文件更新的主动监测功能；被动监测应用，即应用程序自身不具备主动监测功能，但基于边车容器等监测工具(即原始监测工具)被动获取配置文件更新信号；无监测应用，即应用程序自身既不具备主动监测功能，也不具备被动监测功能。

如果当前应用程序为主动监测应用，其代码逻辑本身具备配置文件的检测功能，不需要将其纳入自定义控制器的监测范围，避免了冗余检测的出现；如果当前应用程序为无监测应用，则将该应用程序作为监测对象，以及时完成该应用程序的配置更新；如果当前应用程序为被动监测应用，该应用程序所依赖的边车容器，其更新效率较低，存在严重的更新延迟，且对于该应用程序而言，需要在每个容器组中均启动一个边车容器，极大地浪费了集群资源，例如，集群中总共包括10台电子设备，每台电子设备均部署了应用程序A，在每台电子设备的应用程序A的容器组中均需要启动一个边车容器，显然集群中的多个边车容器占据了大量的集群资源，而在管理节点中创建的自定义控制器，不但可以通过k8s组件服务接口及时获知配置字典更新信息，进而完成应用程序的配置数据的实时更新，同时释放了集群中的多个边车容器，极大地节省了集群资源。

可选的，在本发明实施例中，所述若确定当前应用程序为被动监测应用或无监测应用，将当前应用程序作为所述自定义控制器的监测对象，具体包括：若确定当前应用程序为被动监测应用，获取当前应用程序的平均被动监测时间；若确定当前应用程序的平均被动监测时间大于等于所述自定义控制器的平均监测时间，将当前应用程序作为所述自定义控制器的监测对象，并释放当前应用程序对应的原始监测工具。

具体的，边车容器是通过监控配置字典对应的配置文件的校验和，若校验和发生变化则表明配置字典存在更新，进而向业务容器发送信号，业务应用基于上述信号执行热更新；被动监测时间，是边车容器从执行校验和到发出更新信号的时间，上述过程需要较长时间完成(通常耗时在10秒以上)；平均被动监测时间，是当前应用程序在不同电子设备中的各个被动监测时间的平均值；平均监测时间，是自定义控制器对各个监测对象的平均监测时间。

如果平均被动监测时间较长，即大于平均监测时间，则将当前应用程序作为自定义控制器的监测对象，以进一步提高当前应用程序的配置更新效率；如果平均被动监测时间较短，即小于平均监测时间，则不将当前应用程序作为自定义控制器的监测对象，确保当前应用程序保持原本较高的配置更新效率；特别的，如果平均被动监测时间等于平均监测时间，同样可以将当前应用程序作为自定义控制器的监测对象，由此在保持配置更新效率不变的前提下，释放边车容器占据的集群资源。

可选的，在本发明实施例中，所述创建自定义控制器并为所述自定义控制器分配自定义资源，包括：创建多个不同的自定义控制器；其中，各所述自定义控制器分别与不同监测类型的应用程序相匹配；所述主动监测应用、所述被动监测应用和所述无监测应用的监测优先级依次递增；响应于获取到多个自定义控制器的监测请求，根据各所述自定义控制器分别对应的监测类型的监测优先级，依次响应各所述自定义控制器的监测请求。

具体的，为了提高自定义控制器的监测效率，可以为集群中的不同电子设备设置不同的自定义控制器，每个自定义控制器负责监测一个或多个电子设备中的应用程序；也可以根据应用类型的不同，为不同类型的应用程序设置不同的自定义控制器，每个自定义控制器负责监测一种或多种类型的应用程序；此外，还可以根据监测类型的不同，为不同监测类型的应用程序，设置不同的自定义控制器；例如，为主动监测应用、被动监测应用和无监测应用分别设置不同的自定义控制器；由于自定义控制器均需要通过k8s组件的服务接口，监测配置字典的更新，因此，当检测到多个自定义控制器的监测请求时，根据各个自定义控制器分别对应的监测类型的监测优先级，优先响应无监测应用对应的自定义控制器发出的监测请求，以确保对不具备任何主动或被动检测功能的应用程序的优先响应。

而被动监测应用，由于其依赖的边车容器的响应耗时过长，因此，为了提高了被动监测应用的配置更新效率，次优先级响应被动监测应用；而主动监测应用，由于其本身具备自检功能且更新耗时相比于被动监测应用较短，即使通过自定义控制器无法及时完成配置数据更新，也可通过其自检功能完成配置更新，且耗时时间相对较短；由此，根据不同应用程序的监测类型不同，为不同的自定义控制器设置不同的响应优先级，在同时检测到多个监测请求时，既能确保不具备任何更新检测功能的无监测应用的优先响应，也可以确保对响应耗时较长的被动监测应用的次级响应，最大程度的确保了集群中所有应用程序的配置数据的及时更新。

本发明实施例的技术方案，通过创建完成的自定义控制器监测配置字典的更新，进而完成应用程序的配置更新，再通过管理控制器基于监测到的应用程序的配置更新信息，执行应用程序的容器组更新操作，相比于在容器组中设置边车容器，本申请通过自定义控制器对配置字典的更新监测以及应用程序的配置更新，不需要应用程序具备任何主动或者被动检测功能，具有较好的普遍适用性，同时，基于自定义控制器的配置字典监测，提高了应用程序的配置更新效率，此外，相比于在每个容器组中均需要设置边车容器，本申请仅需要在管理节点中设置一个或有限数量的几个自定义控制器，极大地降低了对集群资源的占用。

实施例二

图2为本发明实施例二提供的一种应用程序的更新方法的流程图，本实施例与上述实施例之间的关系在于，将主动监测应用选择性的加入自定义控制器的监测对象中。如图2所示，该方法包括：

S201、创建自定义控制器并为所述自定义控制器分配自定义资源；其中，所述自定义资源用于记录配置字典与应用程序的配置关系。

S202、遍历集群中的各个应用程序，并获取各所述应用程序的监测类型；其中，所述监测类型包括主动监测应用、被动监测应用以及无监测应用。

S203、若确定当前应用程序为主动监测应用，且当前应用程序的平均主动监测时间大于第一预设时间，或者当前应用程序的实时性等级大于第一预设等级，将当前应用程序作为所述自定义控制器的监测对象。

如果当前应用程序的实时性等级小于等于第一预设等级，表明当前应用程序对实时性的要求较低，此时不需要将当前应用程序作为自定义控制器的监测对象，基于当前应用程序自身具备的主动检测功能执行配置文件的更新操作即可，既减少了自定义控制器的监测对象数量，又避免了冗余检测的出现；如果当前应用程序的实时性等级大于第一预设等级，表明当前应用程序对实时性的要求较高，其自身具备的主动检测功能受到自身代码逻辑限制，无法执行高效率的更新检测操作，此时，将当前应用程序作为自定义控制器的监测对象，以满足当前应用程序配置数据的实时更新需求。

主动监测时间，是应用程序自身代码逻辑检测到配置文件更新所需的时间；平均主动监测时间，是当前应用程序在不同电子设备中的各个被主动监测时间的平均值；如果当前应用程序的平均主动监测时间小于第一预设时间，表明当前应用程序的检测耗时较短，此时同样不需要将当前应用程序作为自定义控制器的监测对象；如果当前应用程序的平均主动监测时间大于等于第一预设时间，表明当前应用程序的检测耗时较长，此时将当前应用程序作为自定义控制器的监测对象，以提高了当前应用程序的配置数据更新效率。

可选的，在本发明实施例中，所述第一预设时间大于所述自定义控制器的平均监测时间。第一预设时间可以设置为大于自定义控制器的平均监测时间，例如，将第一预设时间设置为平均监测时间的整数倍，且整数倍的数值大于1；这是由于即使将主动监测应用纳入自定义控制器的监测范围，其应用程序本身的监测逻辑依然会执行自检操作，由此产生冗余检测；因此，将第一预设时间设置为大于平均监测时间，由此对于耗时较短的应用程序，即使其检测耗时略大于平均监测时间，也同样不作为自定义控制器的监测对象，避免冗余检测的出现；而对于耗时较长的应用程序，则将其作为自定义控制器的监测对象，以此大幅度提高当前应用程序的配置数据更新效率。

S204、若检测到所述当前应用程序发起的监测请求，不响应所述当前应用程序发起的监测请求。

在将主动监测程序加入自定义控制器之后，由于该应用的更新监测已由自定义控制器执行，且自定义控制器的监测耗时相比于应用程序的自检耗时更短，因此，应用程序的自检功能实际上为一种冗余检测，此时不再响应主动监测应用发出的监测请求。

S205、通过所述自定义控制器根据所述配置关系监测所述配置字典的更新状态，并在监测到所述配置字典的更新信息时，对所述应用程序进行配置更新。

S206、通过管理控制器根据监测到的所述应用程序的配置更新信息，执行所述应用程序的容器组更新操作。

本发明实施例的技术方案，在确定当前应用程序为主动监测应用之后，如果当前应用程序的平均主动监测时间大于第一预设时间，或者当前应用程序的实时性等级大于第一预设等级，将当前应用程序作为自定义控制器的监测对象，满足了当前应用程序配置数据的实时更新需求；如果当前应用程序的平均主动监测时间小于等于第一预设时间，或者当前应用程序的实时性等级小于等于第一预设等级，将当前应用程序不作为自定义控制器的监测对象，基于当前应用程序自身具备的主动检测功能执行配置文件的更新操作即可，既减少了自定义控制器的监测对象数量，又避免了冗余检测的出现。

实施例三

图3为本发明实施例三提供的一种应用程序的更新方法的流程图，在本发明实施例中，不同监测类型的应用程序执行不同的监测策略。如图3所示，该方法包括：

S301、创建自定义控制器并为所述自定义控制器分配自定义资源；其中，所述自定义资源用于记录配置字典与应用程序的配置关系；执行S302。

S302、遍历集群中的各个应用程序，并获取各所述应用程序的监测类型；其中，所述监测类型包括主动监测应用、被动监测应用以及无监测应用。若当前应用程序为主动监测应用，执行S303；若当前应用程序为被动监测应用，执行S304；若当前应用程序为无监测应用，执行S305。

S303、判断当前应用程序的平均主动监测时间是否大于等于第一预设时间，以及当前应用程序的实时性等级是否大于等于第一预设等级；若是，执行S305；若否，执行S306。

S304、判断当前应用程序的平均被动监测时间是否大于等于所述自定义控制器的平均监测时间；若是，执行S305；若否，执行S306。

S305、当前应用程序作为所述自定义控制器的监测对象；执行S307。

S306、当前应用程序不作为所述自定义控制器的监测对象；执行S307。

S307、通过所述自定义控制器根据所述配置关系监测所述配置字典的更新状态，并在监测到所述配置字典的更新信息时，对所述应用程序进行配置更新；执行S307。

S308、通过管理控制器根据监测到的所述应用程序的配置更新信息，执行所述应用程序的容器组更新操作。

本发明实施例的技术方案，如果当前应用程序为被动监测应用，且平均被动监测时间较长，则将当前应用程序作为自定义控制器的监测对象，以进一步提高当前应用程序的配置更新效率；如果当前应用程序为被动监测应用，且平均被动监测时间较短，则不将当前应用程序作为自定义控制器的监测对象，确保当前应用程序保持原本较高的配置更新效率；如果当前应用程序为主动监测应用，且平均主动监测时间较长或者实时性等级较高，将当前应用程序作为自定义控制器的监测对象，满足了当前应用程序配置数据的实时更新需求；如果当前应用程序为主动监测应用，且平均主动监测时间较短以及实时性等级较低，将当前应用程序不作为自定义控制器的监测对象，基于当前应用程序自身具备的主动检测功能执行配置文件的更新操作即可，既减少了自定义控制器的监测对象数量，又避免了冗余检测的出现。

实施例四

图4是本发明实施例四所提供的一种应用程序的更新装置的结构框图，该装置具体包括：

控制器创建模块401，用于创建自定义控制器并为所述自定义控制器分配自定义资源；其中，所述自定义资源用于记录配置字典与应用程序的配置关系；

配置更新执行模块402，用于通过所述自定义控制器根据所述配置关系监测所述配置字典的更新状态，并在监测到所述配置字典的更新信息时，对所述应用程序进行配置更新；

容器组更新执行模块403，用于通过管理控制器根据监测到的所述应用程序的配置更新信息，执行所述应用程序的容器组更新操作。

本发明实施例的技术方案，通过创建完成的自定义控制器监测配置字典的更新，进而完成应用程序的配置更新，再通过管理控制器基于监测到的应用程序的配置更新信息，执行应用程序的容器组更新操作，相比于在容器组中设置边车容器，本申请通过自定义控制器对配置字典的更新监测以及应用程序的配置更新，不需要应用程序具备任何主动或者被动检测功能，具有较好的普遍适用性，同时，基于自定义控制器的配置字典监测，提高了应用程序的配置更新效率，此外，相比于在每个容器组中均需要设置边车容器，本申请仅需要在管理节点中设置一个或有限数量的几个自定义控制器，极大地降低了对集群资源的占用。

可选的，应用程序的更新装置，还包括：

配置关系更新请求获取模块，用于响应于获取到所述自定义控制器的配置关系更新请求，更新所述自定义资源记录的配置字典与应用程序的配置关系。

可选的，控制器创建模块401，具体用于遍历集群中的各个应用程序，并获取各所述应用程序的监测类型；其中，所述监测类型包括主动监测应用、被动监测应用以及无监测应用；若确定当前应用程序为主动监测应用，将当前应用程序不作为所述自定义控制器的监测对象；若确定当前应用程序为被动监测应用或无监测应用，将当前应用程序作为所述自定义控制器的监测对象。

可选的，控制器创建模块401，具体还用于若确定当前应用程序为被动监测应用，且当前应用程序的平均被动监测时间大于等于所述自定义控制器的平均监测时间，将当前应用程序作为所述自定义控制器的监测对象，并释放当前应用程序对应的原始监测工具。

可选的，控制器创建模块401，具体还用于若确定当前应用程序的平均主动监测时间大于等于第一预设时间，或者当前应用程序的实时性等级大于等于第一预设等级，将当前应用程序作为所述自定义控制器的监测对象；若检测到所述当前应用程序发起的监测请求，不响应所述当前应用程序发起的监测请求；若确定当前应用程序的平均主动监测时间小于第一预设时间，且当前应用程序的实时性等级小于第一预设等级，将当前应用程序不作为所述自定义控制器的监测对象。

可选的，所述第一预设时间大于所述自定义控制器的平均监测时间。

可选的，控制器创建模块401，具体还用于创建多个不同的自定义控制器并为各所述自定义控制器分配不同的自定义资源；其中，各所述自定义控制器分别与不同监测类型的应用程序相匹配；主动监测应用、被动监测应用和无监测应用的监测优先级依次递增；若检测到多个自定义控制器的监测请求，根据各所述自定义控制器分别对应的监测类型的监测优先级，依次响应各所述自定义控制器的监测请求。

上述装置可执行本发明任意实施例所提供的应用程序的更新方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本发明任意实施例提供的应用程序的更新方法。

实施例五

图5示出了可以用来实施本发明的实施例的电子设备10的结构示意图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备(如头盔、眼镜、手表等)和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本发明的实现。

如图5所示，电子设备10包括至少一个处理器11，以及与至少一个处理器11通信连接的存储器，如只读存储器(ROM)12、随机访问存储器(RAM)13等，其中，存储器存储有可被至少一个处理器执行的计算机程序，处理器11可以根据存储在只读存储器(ROM)12中的计算机程序或者从存储单元18加载到随机访问存储器(RAM)13中的计算机程序，来执行各种适当的动作和处理。在RAM 13中，还可存储电子设备10操作所需的各种程序和数据。处理器11、ROM 12以及RAM 13通过总线14彼此相连。输入/输出(I/O)接口15也连接至总线14。

电子设备10中的多个部件连接至I/O接口15，包括：输入单元16，例如键盘、鼠标等；输出单元17，例如各种类型的显示器、扬声器等；存储单元18，例如磁盘、光盘等；以及通信单元19，例如网卡、调制解调器、无线通信收发机等。通信单元19允许电子设备10通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

处理器11可以是各种具有处理和计算能力的通用和/或专用处理组件。处理器11的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的处理器、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。处理器11执行上文所描述的各个方法和处理，例如应用程序的更新方法。

在一些实施例中，应用程序的更新方法可被实现为计算机程序，其被有形地包含于计算机可读存储介质，例如存储单元。在一些实施例中，计算机程序的部分或者全部可以经由ROM和/或通信单元而被载入和/或安装到异构硬件加速器上。当计算机程序加载到RAM并由处理器执行时，可以执行上文描述的应用程序的更新方法的一个或多个步骤。备选地，在其他实施例中，处理器可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行应用程序的更新方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本发明的方法的计算机程序可以采用一个或多个编程语言的任何组合来编写。这些计算机程序可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器，使得计算机程序当由处理器执行时使流程图和/或框图中所规定的功能/操作被实施。计算机程序可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本发明的上下文中，计算机可读存储介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的计算机程序。计算机可读存储介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。备选地，计算机可读存储介质可以是机器可读信号介质。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在异构硬件加速器上实施此处描述的系统和技术，该异构硬件加速器具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给异构硬件加速器。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)、区块链网络和互联网。

计算系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务中，存在的管理难度大，业务扩展性弱的缺陷。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发明中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本发明的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。