CN116662020B - 应用服务动态管理方法、系统、电子设备及存储介质 - Google Patents

Abstract

本申请公开了应用服务动态管理方法、系统、电子设备及存储介质，涉及计算机应用技术领域，通过监测应用服务的调用信息判断是单端调用还是多端调用，若属于单端调用，则计算该应用服务的请求并发量是否达到预设的并发量阈值，如果达到并发量阈值则根据集群系统的系统资源动态分配服务资源，如果未达到并发量阈值则根据预设标准回收服务资源，若应用服务属于多端调用，则根据不同终端的请求量占比动态分配服务额度。由此通过监测应用服务的调用信息，根据设定的相关阈值和标准动态管理分配相应的服务资源和服务额度，使得不同的应用服务和终端设备能够充分利用资源，提高了服务效率和集群资源的利用率，保障了服务水平，提高系统稳定性。

Description

应用服务动态管理方法、系统、电子设备及存储介质

技术领域

本申请涉及计算机应用技术领域，特别是涉及一种应用服务动态管理方法、系统、电子设备及存储介质。

背景技术

当前以人工智能和大数据为基础的智能化浪潮正在推动产业升级和换代，在人工智能产业化应用中，高并发是一个重要而基础的场景。然而传统的单个服务器处理能力有限，无法处理高并发业务请求，相关技术中将多台服务器构建成为一个服务器集群系统，共同处理外部请求。

集群将应用服务以应用接口的方式向外提供服务，而现有集群通常采用静态的资源分配方式，即事先根据预估需求将资源分配给各个计算节点，因此不同的应用服务无法根据实际需求实时动态规划分配相关资源，难以适应复杂多变的场景，导致资源分配不均衡，利用率低。

发明内容

本申请旨在至少解决现有技术中存在的技术问题之一。为此，本申请实施例提供了一种应用服务动态管理方法、系统、电子设备及存储介质，能够监测应用服务的调用信息，从而动态管理分配相应的服务资源和服务额度，提高集群资源的利用率。

第一方面，本申请实施例提供了一种应用服务动态管理方法，包括：

监测所述应用服务的调用信息，并根据所述调用信息判断所述应用服务的调用类型；其中，所述调用类型包括单端调用和多端调用；

若所述调用类型为单端调用，则计算所述应用服务的请求并发量是否达到预设的并发量阈值；若达到所述并发量阈值，则根据所述集群系统的系统资源对所述应用服务动态分配服务资源；若未达到所述并发量阈值，则根据预设标准回收所述应用服务的服务资源；

若所述调用类型为多端调用，则根据不同终端的请求量占比动态分配所述应用服务的服务额度。

在本申请的一些实施例中，若所述调用类型为单端调用，则计算所述应用服务的请求并发量是否达到预设的并发量阈值，包括：

以第一预设时间为周期获取所述应用服务的请求服务数量和请求服务平均时间；

根据所述请求服务数量、所述请求服务平均时间和所述第一预设时间计算所述请求并发量；

判断所述请求并发量是否达到所述并发量阈值；其中，所述并发量阈值由请求百分比和请求时间百分比计算得到。

在本申请的一些实施例中，所述集群系统为K8s集群；所述若达到所述并发量阈值，则根据所述集群系统的系统资源对所述应用服务动态分配服务资源，包括：

若所述系统资源的使用量未达到所述集群系统的资源总量，则在所述K8s集群中创建Pod对象，根据所述Pod对象创建所述容器，自动分配所述应用服务的所述服务资源至所述容器；

若所述系统资源的使用量达到所述集群系统的资源总量，则检测每个所述应用服务对应的所述容器，得到每个所述应用服务的服务资源状态；

基于所述服务资源状态，分配所述集群系统中的所述系统资源。

在本申请的一些实施例中，所述基于所述服务资源状态，分配所述集群系统中的所述系统资源，包括：

检测每个所述应用服务的所述服务资源状态是否满足回收标准；

若每个所述服务资源状态均不满足所述回收标准，则产生系统资源不足告警；

若所述服务资源状态满足所述回收标准，则根据预设标准回收对应的所述应用服务的所述服务资源，得到回收资源；

将所述回收资源分配至所述请求并发量达到所述并发量阈值的所述应用服务。

在本申请的一些实施例中，所述若未达到所述并发量阈值，则根据预设标准回收所述应用服务的服务资源，包括：

以第二预设时间为周期扫描所述容器的日志，得到所述容器的使用频率；

在预设数量个所述第二预设时间后，判断所述容器的使用频率是否满足第一回收标准；其中，所述第一回收标准为所述容器的使用频率为第一预设频率；

若所述容器的使用频率满足所述第一回收标准，则根据第一预设标准回收待回收资源；其中，所述第一预设标准为将满足所述容器运行的最低服务资源以外的服务资源作为所述待回收资源。

在本申请的一些实施例中，所述若未达到所述并发量阈值，则根据预设标准回收所述应用服务的服务资源，包括：

以第三预设时间为周期扫描每个所述容器的状态，判断所述容器的状态是否满足第二回收标准；其中，所述第二回收标准为所述容器的状态为宕机状态；

若检测所述容器的状态满足所述第二回收标准，则根据第二预设标准回收待回收资源；其中，所述第二预设标准为将所述容器的全部所述服务资源作为所述待回收资源。

在本申请的一些实施例中，所述若未达到所述并发量阈值，则根据预设标准回收所述应用服务的服务资源，包括：

以第四预设时间为周期扫描所述应用服务的日志，得到所述应用服务的使用频率，并判断所述应用服务的使用频率是否满足第三回收标准；其中，所述第三回收标准为所述应用服务的使用频率低于第二预设频率；

若检测所述应用服务的使用频率满足所述第三回收标准，则根据第三预设标准回收待回收资源；其中，所述第三预设标准将对所述服务资源进行预设加权计算得到的服务资源作为所述待回收资源。

在本申请的一些实施例中，所述集群系统为K8s集群，所述监测所述应用服务的调用信息之前，还包括：

设置所述应用服务的所述服务资源的最小资源阈值和最大资源阈值；

当所述应用服务所使用的服务资源低于所述最小资源阈值时，在所述K8s集群中删除对应的Pod对象，以删除所述容器自动释放所述应用服务的所述服务资源；

当所述应用服务所使用的服务资源高于所述最大资源阈值时，在所述K8s集群中创建对应的Pod对象，以创建所述容器自动增加所述应用服务的所述服务资源。

在本申请的一些实施例中，所述终端具有唯一的终端编号；所述若所述调用类型为多端调用，则根据不同终端的请求量占比动态分配所述应用服务的服务额度，包括：

获取所述应用服务的初始服务额度，平均分配所述初始服务额度至每个所述终端；其中，所述终端调用所述应用服务；

以第五预设时间为周期检测每个所述终端的服务使用信息，并根据所述服务使用信息计算对应的所述终端的所述请求量占比；

基于所述请求量占比，根据所述终端编号动态分配所述应用服务的服务额度。

在本申请的一些实施例中，所述基于所述请求量占比，根据所述终端编号动态分配所述应用服务的服务额度，包括：

根据所述终端编号，回收所述请求量占比低于预设请求量占比的所述终端的所述服务额度，得到回收服务额度；

根据所述终端编号，将所述回收服务额度分配至所述请求量占比高于预设请求量占比的所述终端。

在本申请的一些实施例中，所述基于所述请求量占比，根据所述终端编号动态分配所述应用服务的服务额度之后，还包括：

设置消息队列，并将所述请求量占比低于所述预设请求量占比的所述终端输入至所述消息队列，对所述终端的请求依次排队处理；

为所述请求量占比高于所述预设请求量占比的终端添加优先级，对所述终端的请求按所述优先级处理。

第二方面，本申请实施例还提供了一种应用服务动态管理系统，应用如本申请第一方面实施例所述的应用服务动态管理方法，包括：

服务判断模块，用于监测所述应用服务的调用信息，并根据所述调用信息判断所述应用服务的调用类型；其中，所述调用类型包括单端调用和多端调用；

单边调用模块，用于若所述调用类型为单端调用，则计算所述应用服务的请求并发量是否达到预设的并发量阈值；若达到所述并发量阈值，则根据系统资源对所述应用服务动态分配服务资源；若未达到所述并发量阈值，则根据预设标准回收所述应用服务的服务资源；

多端调用模块，用于若所述调用类型为多端调用，则根据不同终端的请求量占比动态分配所述应用服务的服务额度。

第三方面，本申请实施例还提供了一种电子设备，包括存储器、处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现如本申请第一方面实施例所述的应用服务动态管理方法。

第四方面，本申请实施例还提供了一种计算机可读存储介质，所述存储介质存储有程序，所述程序被处理器执行实现如本申请第一方面实施例所述的应用服务动态管理方法。

本申请实施例至少包括以下有益效果：

本申请实施例提供了一种应用服务动态管理方法、系统、电子设备及存储介质，其中，方法中通过监测应用服务的调用信息判断应用服务的调用类型是单端调用还是多端调用，若应用服务属于单端调用，则计算该应用服务的请求并发量是否达到预设的并发量阈值，如果达到并发量阈值则根据集群系统的系统资源对应用服务动态分配服务资源，如果未达到并发量阈值则根据预设标准回收该应用服务的服务资源，若应用服务属于多端调用，则根据不同终端的请求量占比动态分配应用服务的服务额度。由此通过监测应用服务的调用信息，根据设定的相关阈值和标准动态管理分配相应的服务资源和服务额度，使得不同的应用服务和终端设备能够充分利用资源，提高了服务效率和集群资源的利用率。

本申请的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1是本申请一个实施例提供的应用服务动态管理方法的流程示意图；

图2是图1中步骤S102的流程示意图；

图3是图1中步骤S102的另一流程示意图；

图4是图3中步骤S302的流程示意图；

图5是图1中步骤S102的另一流程示意图；

图6是图1中步骤S102的另一流程示意图；

图7是图1中步骤S102的另一流程示意图；

图8是图1中步骤S101之前的流程示意图；

图9是图1中步骤S103的流程示意图；

图10是图9中步骤S903的流程示意图；

图11是图9中步骤S903之后的流程示意图；

图12是本申请一个实施例提供的集群系统流程图；

图13是本申请一个实施例提供的单端调用应用服务流程图；

图14是本申请一个实施例提供的多端调用应用服务流程图；

图15是本申请一个实施例提供的应用服务动态管理系统模块示意图；

图16是本申请一个实施例提供的电子设备的结构示意图。

附图标记：服务判断模块 100、单端调用模块 200、多端调用模块 300、电子设备1000、处理器 1001、存储器 1002。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能理解为对本申请的限制。

在本申请的描述中，需要理解的是，涉及到方位描述，例如上、下、前、后、左、右等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。

在本申请的描述中，若干的含义是一个或者多个，多个的含义是两个以上，大于、小于、超过等理解为不包括本数，以上、以下、以内等理解为包括本数。如果有描述到第一、第二只是用于区分技术特征为目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量或者隐含指明所指示的技术特征的先后关系。

本申请的描述中，除非另有明确的限定，设置、安装、连接等词语应做广义理解，所属技术领域技术人员可以结合技术方案的具体内容合理确定上述词语在本申请中的具体含义。

当前以人工智能和大数据为基础的智能化浪潮正在推动产业升级和换代，在人工智能产业化应用中，高并发是一个重要而基础的场景。然而传统的单个服务器处理能力有限，无法处理高并发业务请求，相关技术中将多台服务器构建成为一个服务器集群系统，共同处理外部请求。在实际的场景使用中集群将应用服务以应用接口的方式向外提供，通常采用静态的资源分配方式，即事先根据预估需求将资源分配给各个计算节点，而对应用服务调用后的使用情况缺少数据方面的统计和监测，无法以应用服务为对象进行动态的资源规划和分配，难以适应复杂多变的新场景，导致资源分配不均衡，利用率低。

基于此，本申请实施例提供了一种应用服务动态管理方法、系统、电子设备及存储介质，以应用服务为对象，通过监测应用服务的调用信息，根据设定的相关阈值和标准动态管理分配相应的服务资源和服务额度，使得不同的应用服务和终端设备能够充分利用资源，提高了服务效率和集群资源的利用率。

本申请实施例提供应用服务动态管理方法、系统、电子设备及存储介质，具体通过如下实施例进行说明，首先描述本申请实施例中的应用服务动态管理方法。

本申请实施例提供的应用服务动态管理方法，涉及计算机技术领域，尤其涉及计算机应用技术领域。本申请实施例提供的应用服务动态管理方法可应用于终端中，也可应用于服务器端中，还可以是运行于终端或服务器端中的计算机程序。举例来说，计算机程序可以是操作系统中的原生程序或软件模块；可以是本地(Native)应用程序(APP，Application)，即需要在操作系统中安装才能运行的程序，如支持应用服务动态管理的客户端，即只需要下载到浏览器环境中就可以运行的程序。总而言之，上述计算机程序可以是任意形式的应用程序、模块或插件。其中，终端通过网络与服务器进行通信。该应用服务动态管理方法可以由终端或服务器执行，或由终端和服务器协同执行。

在一些实施例中，终端可以是智能手机、平板电脑、笔记本电脑、台式计算机或者智能手表等。服务器可以是独立的服务器，也可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(ContentDelivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器；也可以是区块链系统中的服务节点，该区块链系统中的各服务节点之间组成点对点（P2P，PeerTo Peer）网络，P2P协议是一个运行在传输控制协议（TCP，Transmission ControlProtocol）协议之上的应用层协议。服务器上可以安装应用服务动态管理系统的服务端，通过该服务端可以与终端进行交互，例如服务端上安装对应的软件，软件可以是实现应用服务动态管理方法的应用等，但并不局限于以上形式。终端与服务器之间可以通过蓝牙、USB（Universal Serial Bus，通用串行总线）或者网络等通讯连接方式进行连接，本实施例在此不做限制。

本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

下面描述本发明实施例中的应用服务动态管理方法。

参照图1所示，本申请实施例提供了一种应用服务动态管理方法，应用于集群系统，集群系统包括多个容器，每一个或多个容器承载一种应用服务，该应用服务动态管理方法包括但不限于以下步骤S101至步骤S103。

步骤S101，监测应用服务的调用信息，并根据调用信息判断应用服务的调用类型。

可以理解的是，应用服务指的是运行在集群系统中的应用程序或服务，可以是单个应用程序，也可以是一个由多个应用程序构成的服务。集群系统是指将多台物理或虚拟计算机（节点）组合在一起，通过集中管理和协同工作的方式来提供计算资源和服务的系统。而容器是一种轻量级的虚拟化技术，它将应用程序和其依赖的组件（如库、环境变量等）打包在一起，以便在不同的计算机环境中进行移植和运行。由此应用服务以容器化的形式部署在集群系统中，充分利用集群系统的资源和管理能力来提供各种功能和服务。

在一些实施例中，通过设置监测节点，可以监测应用服务的调用信息，也可以使用日志记录或监控工具获取应用服务的调用信息，例如调用的相关地址和参数等。然后分析调用信息判断应用服务的调用类型为单端调用还是多端调用，具体的，在单端调用中只有一个终端设备与应用服务进行通信，而多端调用是多个不同终端设备或平台同时调用该应用服务。

步骤S102，若调用类型为单端调用，则计算应用服务的请求并发量是否达到预设的并发量阈值；若达到并发量阈值，则根据集群系统的系统资源对应用服务动态分配服务资源；若未达到并发量阈值，则根据预设标准回收应用服务的服务资源。

在一些实施例中，如果调用类型为单端调用，则计算应用服务的请求并发量是否达到预设的并发量阈值，从而判断该应用服务是否为高并发调用。可以理解的是，高并发调用指的是在短时间内同时有大量请求发送到应用服务，可能导致服务器负载过高、响应时间延长甚至系统崩溃。如果该应用服务的请求并发量达到了预设的并发量阈值，则认为这是高并发调用，需要根据集群系统的系统资源对应用服务动态分配服务资源去处理高并发的请求；如果该应用服务的请求并发量并未达到预设的并发量阈值，则根据预设标准回收相关的服务资源。可以理解的是，服务资源可以包括但不限于计算资源、存储资源、网络资源、带宽资源和虚拟资源等，由此可以动态的管理各种应用服务的资源，有效提高资源的利用率。

步骤S103，若调用类型为多端调用，则根据不同终端的请求量占比动态分配应用服务的服务额度。

在一些实施例中，如果应用服务同时被多个不同终端设备或平台调用，则该应用服务的调用类型为多端调用，则针对不同终端设备计算调用应用服务的请求量占比，从而根据请求量占比动态分配应用服务的服务额度至终端。示例性的，终端A对应用服务的请求量占比高，终端B和终端C对该应用服务的请求量占比低，则会分配更多的服务额度至终端A。具体的，服务额度是指云服务提供商对用户在一定时间范围内使用特定服务的限制，服务额度可以是关于某项资源的最大使用量，也可以是关于某个功能的限制，可以包括请求速率、连接数、API调用次数等方面的限制，本申请实施例对此不做限制。

由此通过监测应用服务的调用信息，根据设定的相关阈值和标准动态管理分配相应的服务资源和服务额度，使得不同的应用服务和终端设备能够充分利用资源，提高了服务效率和集群资源的利用率。

参照图2所示，在本申请的一些实施例中，上述步骤S102还可以包括但不限于以下步骤S201至步骤S203。

步骤S201，以第一预设时间为周期获取应用服务的请求服务数量和请求服务平均时间。

在一些实施例中，以第一预设时间为周期获取应用服务的请求服务数量和请求服务平均时间，具体的，可以设置服务监测节点，以第一预设时间为周期获取服务请求日志相关信息，从而根据服务请求日志中获取该应用服务在第一预设时间范围内的请求服务数量和请求服务平均时间，本实施例对此不做限制。

步骤S202，根据请求服务数量、请求服务平均时间和第一预设时间计算请求并发量。

在一些实施例中，根据请求服务数量、请求服务平均时间和第一预设时间计算请求并发量，具体的，将请求服务数量和请求服务平均时间的乘积除于第一预设时间可以计算平均请求并发量，即C=nL/T，其中C代表平均请求并发量，n代表请求服务数量，L代表请求服务平均时间，T代表第一预设时间。进一步的，根据平均请求并发量计算请求并发量峰值作为请求并发量，C1=C+3*sqrt(C)。可以理解的是，第一预设时间可以设置为10分钟或者30分钟，本领域技术人员可以根据实际需求设置，本申请实施例对此不做限制。

步骤S203，判断请求并发量是否达到并发量阈值。

在一些实施例中，并发量阈值由请求百分比和请求时间百分比计算得到，具体的，请求百分比是指该应用服务的请求量在所有应用服务的请求总量中的占比，请求时间百分比是指该应用服务响应的时间在一天中的占比。并发量阈值S=((pct1*PV)/(24*60*60*pct2))/N，其中，pct1代表请求百分比，PV代表请求总量，pct2代表请求时间百分比，N代表集群系统终端服务器数量。

在一些实施例中，并发量阈值还可以根据额定标准，例如在一个具有2核CPU和4GB内存的单服务节点上，默认情况下可以支持最多500个并发请求，本实施例对此不做限制。

参照图3所示，在本申请的一些实施例中，上述步骤S102还可以包括但不限于以下步骤S301至步骤S303。

步骤S301，若系统资源的使用量未达到集群系统的资源总量，则在K8s集群中创建Pod对象，根据Pod对象创建容器，自动分配应用服务的服务资源至容器。

在一些实施例中，集群系统为K8s集群，K8s集群是指使用Kubernetes（简称K8s）进行容器编排和管理的一组物理或虚拟计算机集合。可以理解的是，K8s集群中的资源是由集群中的各个节点提供的，每个节点都有自己的计算资源和存储资源，并通过网络连接在一起。集群的资源总量取决于节点的数量、每个节点的硬件规格和配置，以及集群的网络带宽和存储容量等，因此集群系统的资源总量具有一定限度。

在一些实施例中，如果系统资源的使用量未达到K8s集群的资源总量，则在K8s集群中创建Pod对象，根据Pod对象创建容器，自动分配应用服务的服务资源至容器。可以理解的是，在K8s集群中，Pod是最小的调度单元，它是由一个或多个容器组成的逻辑组。当创建Pod时，可以定义容器的资源请求和限制，即所需的CPU和内存资源等服务资源。由此根据创建的Pod对象自动创建相关规格的容器并自动分配该应用服务的服务资源，实现应用服务的扩容，达到负载均衡减缓服务压力以满足高并发请求。

步骤S302，若系统资源的使用量达到集群系统的资源总量，则检测每个应用服务对应的容器，得到每个应用服务的服务资源状态。

在一些实施例中，如果系统资源的使用量达到K8s集群的资源总量，则自动触发整体服务容器日志的扫描指令，检测每个应用服务对应的日志，从而得到每个应用服务的服务资源状态。可以理解的是，通过日志扫描的方法监测应用服务的运行状态和资源消耗情况，分析应用服务的日志，获取关键指标和信息，例如CPU使用率、内存占用、网络流量等，这些指标可以反映应用服务的资源利用情况和性能表现。

步骤S303，基于服务资源状态，分配集群系统中的系统资源。

在一些实施例中，根据每个应用服务对应的服务资源状态，分配集群系统中的系统资源，例如应用服务S1和应用服务S2被调用请求的次数低，所使用的服务资源较少，因此可以将其对应的服务资源分配部分至高并发的应用服务S3中，从而在系统资源使用量达到资源总量的情况下也能动态管理分配服务资源，充分提供了资源的利用率。

参照图4所示，在本申请的一些实施例中，上述步骤S303还可以包括但不限于以下步骤S401至步骤S404。

步骤S401，检测每个应用服务的服务资源状态是否满足回收标准。

在一些实施例中，检测每个应用服务的服务资源状态是否满足回收标准，例如是否预设时间内不调用该应用服务，或者调用该应用服务的次数低于预设次数等，从而判断该应用服务是否有相关的空闲资源可以回收至系统资源中，本实施例对此不做限制。

步骤S402，若每个服务资源状态均不满足回收标准，则产生系统资源不足告警。

在一些实施例中，如果每个服务资源状态均不满足回收标准，即所有应用服务当前的服务资源都处于被使用的状态，说明集群系统中的资源总量不够，对应产生系统资源不足告警，从而提醒增加外部资源以满足各个应用服务的并发请求。

步骤S403，若服务资源状态满足回收标准，则根据预设标准回收对应的应用服务的服务资源，得到回收资源。

在一些实施例中，如果服务资源状态满足回收标准，例如该应用服务长期不被调用，则根据预设标准回收对应的应用服务的服务资源，得到回收资源。具体的，可以回收该应用服务的全部服务资源，也可以按照调用应用服务的最低服务资源标准回收部分服务资源，本实施例对此不做限制。

步骤S404，将回收资源分配至请求并发量达到并发量阈值的应用服务。

在一些实施例中，将回收资源重新分配至请求并发量达到并发量阈值的应用服务，进一步提高了集群系统的稳定性和资源利用率。

参照图5所示，在本申请的一些实施例中，上述步骤S102还可以包括但不限于以下步骤S501至步骤S503。

步骤S501，以第二预设时间为周期扫描容器的日志，得到容器的使用频率。

在一些实施例中，如果应用服务的请求并发量未达到并发量阈值，则以第二预设时间为周期扫描容器的日志，得到容器的使用频率。具体的，通过扫描容器的输出输入日志，可以获取容器的活动记录和使用情况，包括容器的请求和响应日志、访问日志等。根据这些日志，可以分析容器的活跃度和使用频率。

具体的，第二预设时间可以设置为24小时或12小时，例如，在每天的晚上11点对容器的日志进行扫描，得到该容器当日的使用频率，本实施例对此不做限制。

步骤S502，在预设数量个第二预设时间后，判断容器的使用频率是否满足第一回收标准。

在一些实施例中，第一回收标准为容器的使用频率为第一预设频率，具体的，在预设数量个第二预设时间后，如果容器的使用频率为第一预设频率，则该容器满足第一回收标准。示例性的，预设数量为7，第二预设时间为24小时，第一预设频率为0，因此在连续7个24小时后，容器的使用频率为0，即该容器已经七天没被使用则其满足第一回收标准。

可以理解的是，对于经常使用的容器，可以认定其为当前服务的一部分，并保留它们的资源。这样可以确保这些容器能够继续提供服务，并满足用户的需求。至于长期不再使用的容器，也就是不活跃或使用频率很低的容器，可以被判定为不再需要的资源。这些容器所占用的资源可以被视为废弃资源，并可以进行资源回收。具体的，资源回收包括停止容器、销毁容器实例以及释放相关的计算资源，从而确保集群中的资源能够最大限度地用于支持活跃的服务，减少资源的浪费。

步骤S503，若容器的使用频率满足第一回收标准，则根据第一预设标准回收待回收资源。

在一些实施例中，第一预设标准为将满足容器运行的最低服务资源以外的服务资源作为待回收资源。示例性的，当前容器的服务资源为2核CPU和4GB内存，而满足该容器运行的最低服务资源为0.1核CPU和0.1GB内存，当其满足第一回收标准，则根据第一预设标准回收1.9核CPU和3.9GB内存的待回收资源，本实施例对此不做限制。

参照图6所示，在本申请的一些实施例中，上述步骤S102还可以包括但不限于以下步骤S601至步骤S602。

步骤S601，以第三预设时间为周期扫描每个容器的状态，判断容器的状态是否满足第二回收标准。

在一些实施例中，如果应用服务的请求并发量未达到并发量阈值，则以第三预设时间为周期扫描每个容器的状态，判断容器的状态是否满足第二回收标准，具体的，第二回收标准是容器的状态为宕机状态。可以理解的是，第三预设时间可以和第二预设时间相同也可以不同，本领域技术人员可以根据实际需求设置。

在一些实施例中，定期扫描集群系统中的容器状态，获取容器的当前状态信息，对于状态为"exited"或"stopped"的容器，认为是宕机状态。可以理解的是，容器死机或者进入死循环，又或者版本不更新导致无法正常使用都有可能导致容器宕机，因此可以对宕机状态的容器进行资源回收。

步骤S602，若检测容器的状态满足第二回收标准，则根据第二预设标准回收待回收资源。

在一些实施例中，第二预设标准为将容器的全部服务资源作为待回收资源，如果检测容器的状态满足第二回收标准，更回收该容器的全部服务资源，还可以删除该容器实例等，本实施例对此不做限制。

参照图7所示，在本申请的一些实施例中，上述步骤S102还可以包括但不限于以下步骤S701至步骤S702。

步骤S701，以第四预设时间为周期扫描应用服务的日志，得到应用服务的使用频率，并判断应用服务的使用频率是否满足第三回收标准。

在一些实施例中，如果应用服务的请求并发量未达到并发量阈值，则以第四预设时间为周期扫描应用服务的日志，得到应用服务的使用频率，具体的，第三预设时间可以设置为24小时或12小时，例如，在每天的晚上11点对应用服务的请求日志进行扫描，得到该应用服务当日的使用频率，然后判断应用服务的使用频率是否满足第三回收标准。第三回收标准为应用服务的使用频率低于第二预设频率，示例性的，第二预设频率可以为10或者20。

可以理解的是，第三回收标准还可以是预设数量个第四预设时间内，应用服务的使用频率低于第二预设频率，预设数量可以是1或者3，例如连续三个第四预设时间内应用服务的使用频率低于10次，本实施例对此不做限制。

步骤S702，若检测应用服务的使用频率满足第三回收标准，则根据第三预设标准回收待回收资源。

在一些实施例中，当该应用服务的使用频率较低时，对应使用的服务资源少，因此可以将满足第三回收标准的应用服务根据第三预设标准进行资源回收，具体的，第三预设标准将对服务资源进行预设加权计算得到的服务资源作为待回收资源。

可以理解的是，根据预设加权计算可以按比例减少低频率服务的容器数量，从而回收相关资源，可以根据请求次数、请求频率设置权重系数，也可以直接根据请求量占比加权计算对应的待回收资源，本实施例对此不做限制。

参照图8所示，在本申请的一些实施例中，上述步骤S101之前，还可以包括但不限于以下步骤S801至步骤S803。

步骤S801，设置应用服务的服务资源的最小资源阈值和最大资源阈值。

在一些实施例中，设置应用服务的服务资源的最小资源阈值和最大资源阈值，可以限制应用服务使用的资源范围，以确保系统的稳定性和可靠性。最小资源阈值表示应用服务所需的最低资源要求，而最大资源阈值表示应用服务能够使用的最高资源限制。具体的，在签约一个新的应用服务时，参考其他应用服务的实际情况初始化将该应用服务的最小资源阈值和最大资源阈值设置为平均资源阈值，也可以根据实际需求设置。

步骤S802，当应用服务所使用的服务资源低于最小资源阈值时，在K8s集群中删除对应的Pod对象，以删除容器自动释放应用服务的服务资源。

在一些实施例中，当应用服务所使用的服务资源低于最小资源阈值时，通过在K8s集群中删除对应的Pod对象可以实现减少资源，避免服务资源的浪费，提高资源的利用率。可以理解的是，删除Pod对象后，Kubernetes会自动检测到Pod的状态变更，并将相应的容器停止，Kubernetes发送停止容器的命令，使其正常关闭并释放资源，在容器停止后，相关的资源，如CPU、内存等，将被释放，并变为可供其他容器使用。

步骤S803，当应用服务所使用的服务资源高于最大资源阈值时，在K8s集群中创建对应的Pod对象，以创建容器自动增加应用服务的服务资源。

在一些实施例中，当应用服务所使用的服务资源高于最大资源阈值时，而且系统资源并未达到集群系统的资源总量，则可以通过在K8s集群中创建对应的Pod对象，从而创建容器自动增加应用服务的服务资源。具体的，通过定义和提交Pod的规格和配置文件，可以创建一个新的Pod对象，Pod规格中可以包含容器的资源请求和限制，如CPU和内存的需求量。一旦创建了Pod，Kubernetes将根据Pod规格中的配置，自动创建相应的容器，并自动分配所需的资源，如CPU、内存等，由此满足应用程序的高并发请求。

参照图9所示，在本申请的一些实施例中，上述步骤S103还可以包括但不限于以下步骤S901至步骤S903。

步骤S901，获取应用服务的初始服务额度，平均分配初始服务额度至每个终端；其中，终端调用应用服务。

可以理解的是，不同终端设备具有唯一的终端编号，例如自动分配的id或者设置的特殊编号。根据终端编号可以对不同的终端分配服务额度。在一些实施例中，如果应用服务的调用类型为多端调用，则根据不同终端的编号和请求量占比动态分配服务额度。

具体的，在签约一个新的应用服务时，获取该应用服务的初始服务额度，例如可以同时处理100个请求，如果有5个终端设备同时调用该应用服务，则平均分配初始服务额度至每个终端，即每个终端可以同时调用20次该应用服务，即应用服务同时处理100个来自不同终端的请求。

步骤S902，以第五预设时间为周期检测每个终端的服务使用信息，并根据服务使用信息计算对应的终端的请求量占比。

在一些实施例中，以第五预设时间为周期检测每个终端的服务使用信息，具体的，设置服务监测节点案子第五预设时间为周期检测每个终端的服务使用信息，可以通过日志获取，然后根据服务使用信息计算对应的终端的请求量占比，计算每个终端对应用服务的请求量占总请求量的比例，可以得到每个终端的请求量占比。

示例性的，第五预设时间为30分钟，在30分钟内如果终端A对应用服务的请求次数为10次，终端B对应用服务的请求次数为20次，终端C对应用服务的请求次数为70次，则计算终端A的请求量占比为10/(10+20+70)=10%，终端B的请求量占比为20/(10+20+70)=20%,终端C的请求量占比为70/(10+20+70)=70%。

步骤S903，基于请求量占比，根据终端编号动态分配应用服务的服务额度。

在一些实施例中，基于请求量占比，根据终端编号动态分配应用服务的服务额度，如果终端A和终端B的请求量占比较低，而终端C的请求量占比较高，则根据终端编号可以快速准确地回收请求量占比较低的终端的服务额度，然后再根据终端编号快速准确地分配相关服务额度，以满足终端对应用服务的请求。

在本申请的一些实施例中，对于每个应用服务不同的调用方只采用单个主线程处理请求，因此在主线程总的资源或服务额度监控中对每个终端设置特殊编号，监测服务额度的使用情况，从而便于将资源倾斜给请求量大的终端。具体的，如果请求量较大的应用服务，则调整服务器的负载均衡策略，将请求量较大的服务分配更多的CPU和内存资源，从而提高服务器的响应速度和稳定性。并且通过监测服务器CPU和内存的使用情况，收集服务器的负载信息，使用权重轮询方式调整负载策略，对请求量高的终端进行负载倾斜，增加服务器资源的分配。而且还可以根据请求量的大小，将请求量较大的服务分配更多的CPU和内存资源，扩充负载资源，通过监控服务器性能，及时发现服务器资源不足或过剩的情况，并调整服务器资源。

参照图10所示，在本申请的一些实施例中，上述步骤S903还可以包括但不限于以下步骤S1001至步骤S1002。

步骤S1001，根据终端编号，回收请求量占比低于预设请求量占比的终端的服务额度，得到回收服务额度。

在一些实施例中，如果计算终端的请求量占比低于预设请求量占比，则根据终端编号回收该终端的服务额度。示例性的，终端A的请求量占比为10%，预设请求量占比为30%，说明终端A对应用服务的请求所使用的服务额度较少，因此可以对应回收相关的服务额度。

步骤S1002，根据终端编号，将回收服务额度分配至请求量占比高于预设请求量占比的终端。

在一些实施例中，如果计算终端的请求量占比高于预设请求量占比，则根据终端编号分配服务额度至该终端。示例性的，终端C的请求量占比为70%，预设请求量占比为30%，说明终端C对应用服务的请求所使用的服务额度较多，目前的服务额度不能满足请求需求，可以通过加权分配剩余的服务额度至终端C，本实施例对此不做限制。

参照图11所示，在本申请的一些实施例中，上述步骤S903之后还可以包括但不限于以下步骤S1101至步骤S1102。

步骤S1101，设置消息队列，并将请求量占比低于预设请求量占比的终端输入至消息队列，对终端的请求依次排队处理。

在一些实施例中，设置消息队列，将请求量占比低于预设请求量占比的终端输入至消息队列中，从而对终端的请求依次排队处理。示例性的，终端A的请求量占比为10%，终端B的请求量占比为20%，而预设的请求量占比为30%，如果接收到终端A和B的请求时，集群系统在处理其他请求，则将终端A和终端B的相关请求信息输入至消息队列中等待排队处理。

步骤S1102，为请求量占比高于预设请求量占比的终端添加优先级，对终端的请求按优先级处理。

在一些实施例中，为请求量占比高于预设请求量占比的终端添加优先级，对终端的请求按优先级处理，从而优先处理请求量占比高的终端的请求，由此可以倾斜服务器更多的资源到请求量高的端上，避免请求量过大导致服务器崩溃或响应时间不稳定的情况，本实施例对此不做限制。

以下通过一个智慧交通场景作为本申请一个实施例说明。

交通监控摄像每天要产生大量的图片和视频数据，通过集群系统的资源分配可以提升交通系统的分析效率等。参照图12所示的集群系统流程图，通过应用服务的调用信息可以判断其调用类型为单端调用还是多端调用，如果是单端调用则判断该应用服务的请求并发量是否达到并发量阈值，如果达到并发量阈值则增加服务资源，否则根据预设标准回收服务资源，如果是多端调用则监测不同终端的请求量占比，并判断是否高于预设请求量占比，如果高于预设请求量占比则分配服务额度至对应的终端，否则回收终端的服务额度。

具体的，参照图13所示的单端调用应用服务流程图，在智慧交通场景下，终端设备例如摄像头设备调用应用服务过程中，早晚上班高峰期人车流量大时会遇到短时间内大量请求该应用服务的情况，导致当前应用服务并发量迅速攀升。因此设置监测节点以第一预设时间为周期检测该应用服务是否为高并发服务，通过计算请求并发量并对比并发量阈值，通过增加或者删除容器实现集群系统中服务资源的分配。

参照图14所示的多端调用应用服务流程图，在智慧交通场景中，多个终端设备例如摄像头设备同时使用一个应用服务的情况时常出现，如不同的道路摄像头同时使用保存拍摄视频应用服务的场景，在此场景中难免会出现不同道路人车流量不同导致终端设备请求应用服务次数不同的情况。集群系统在正常使用能力时采用各个设备或节点平均分配资源的策略，并设置监测节点按第五预设时间为周期检查不同终端的资源使用信息，从而将该应用服务的服务额度根据请求量占比分配。

由此通过监测应用服务的调用信息，根据设定的相关阈值和标准动态管理分配相应的服务资源和服务额度，使得不同的应用服务和终端设备能够充分利用资源，提高了服务效率和集群资源的利用率。根据应用服务具体资源情况预设并发量阈值，或者根据实际的业务需求设置并发量阈值，在应用服务调用到达预设的并发量阈值时，对集群系统中系统资源动态分配，保障了服务水平，提高系统稳定性和资源利用率，还提供应用服务的监测机制，保障服务调用的安全性和服务数据的可监测性。本发明实施例还提供一种应用服务动态管理系统，可以实现上述应用服务动态管理方法，参照图15所示，在本申请一些实施例中，应用服务动态管理系统包括：

服务判断模块100，用于监测应用服务的调用信息，并根据调用信息判断应用服务的调用类型；其中，调用类型包括单端调用和多端调用；

单边调用模块200，用于若调用类型为单端调用，则计算应用服务的请求并发量是否达到预设的并发量阈值；若达到并发量阈值，则根据系统资源对应用服务动态分配服务资源；若未达到并发量阈值，则根据预设标准回收应用服务的服务资源；

多端调用模块300，用于若调用类型为多端调用，则根据不同终端的请求量占比动态分配应用服务的服务额度。

本实施例的应用服务动态管理系统的具体实施方式与上述应用服务动态管理方法的具体实施方式基本一致，在此不再一一赘述。

图16示出了本申请实施例提供的电子设备1000。电子设备1000包括：处理器1001、存储器1002及存储在存储器1002上并可在处理器1001上运行的计算机程序，计算机程序运行时用于执行上述的应用服务动态管理方法。

处理器1001和存储器1002可以通过总线或者其他方式连接。

存储器1002作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序，如本申请实施例描述的应用服务动态管理方法。处理器1001通过运行存储在存储器1002中的非暂态软件程序以及指令，从而实现上述的应用服务动态管理方法。

存储器1002可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储执行上述的应用服务动态管理方法。此外，存储器1002可以包括高速随机存取存储器1002，还可以包括非暂态存储器1002，例如至少一个储存设备存储器件、闪存器件或其他非暂态固态存储器件。在一些实施方式中，存储器1002可选包括相对于处理器1001远程设置的存储器1002，这些远程存储器1002可以通过网络连接至该电子设备1000。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

实现上述的应用服务动态管理方法所需的非暂态软件程序以及指令存储在存储器1002中，当被一个或者多个处理器1001执行时，执行上述的应用服务动态管理方法，例如，执行图1中的方法步骤S101至步骤S103、图2中的方法步骤S201至步骤S203、图3中的方法步骤S301至步骤S303、图4中的方法步骤S401至步骤S404、图5中的方法步骤S501至步骤S503、图6中的方法步骤S601至步骤S602、图7中的方法步骤S701至步骤S7023、图8中的方法步骤S801至步骤S803、图9中的方法步骤S901至步骤S903、图10中的方法步骤S1001至步骤S1002、图11中的方法步骤S1101至步骤S1102。

本申请实施例还提供了一种存储介质，存储介质为计算机可读存储介质，该存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述应用服务动态管理方法。存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至该处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本申请实施例提供的应用服务动态管理方法、系统、电子设备及存储介质，通过监测应用服务的调用信息判断应用服务的调用类型是单端调用还是多端调用，若应用服务属于单端调用，则计算该应用服务的请求并发量是否达到预设的并发量阈值，如果达到并发量阈值则根据集群系统的系统资源对应用服务动态分配服务资源，如果未达到并发量阈值则根据预设标准回收该应用服务的服务资源，若应用服务属于多端调用，则根据不同终端的请求量占比动态分配应用服务的服务额度。由此通过监测应用服务的调用信息，根据设定的相关阈值和标准动态管理分配相应的服务资源和服务额度，使得不同的应用服务和终端设备能够充分利用资源，提高了服务效率和集群资源的利用率，保障了服务水平，提高系统稳定性。

以上所描述的实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质（或非暂时性介质）和通信介质（或暂时性介质）。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息（诸如计算机可读指令、数据结构、程序模块或其他数据）的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘（DVD）或其他光盘存储、磁盒、磁带、储存设备存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包括计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

还应了解，本申请实施例提供的各种实施方式可以任意进行组合，以实现不同的技术效果。以上是对本申请的较佳实施进行了具体说明，但本申请并不局限于上述实施方式，熟悉本领域的技术人员在不违背本申请精神的共享条件下还可作出种种等同的变形或替换。

Claims (13)

1.一种应用服务动态管理方法，应用于集群系统，所述集群系统包括多个容器，每一个或多个所述容器承载一种所述应用服务，其特征在于，包括：

监测所述应用服务的调用信息，并根据所述调用信息判断所述应用服务的调用类型；其中，所述调用类型包括单端调用和多端调用；

若所述调用类型为单端调用，则计算所述应用服务的请求并发量是否达到预设的并发量阈值；若达到所述并发量阈值，则根据所述集群系统的系统资源对所述应用服务动态分配服务资源；若未达到所述并发量阈值，则根据预设标准回收所述应用服务的服务资源；

若所述调用类型为多端调用，则根据不同终端的请求量占比动态分配所述应用服务的服务额度；

若所述调用类型为单端调用，则计算所述应用服务的请求并发量是否达到预设的并发量阈值，包括：

以第一预设时间为周期获取所述应用服务的请求服务数量和请求服务平均时间；

根据所述请求服务数量、所述请求服务平均时间和所述第一预设时间计算所述请求并发量，包括：将所述请求服务数量和所述请求服务平均时间的乘积除于所述第一预设时间计算平均请求并发量，C=nL/T，其中C代表所述平均请求并发量，n代表所述请求服务数量，L代表所述请求服务平均时间，T代表所述第一预设时间；根据所述平均请求并发量计算请求并发量峰值作为所述请求并发量，C1=C+3*sqrt(C)，其中C1代表所述请求并发量；

判断所述请求并发量是否达到所述并发量阈值；其中，所述并发量阈值由请求百分比和请求时间百分比计算得到。

2.根据权利要求1所述的应用服务动态管理方法，其特征在于，所述集群系统为K8s集群；所述若达到所述并发量阈值，则根据所述集群系统的系统资源对所述应用服务动态分配服务资源，包括：

若所述系统资源的使用量未达到所述集群系统的资源总量，则在所述K8s集群中创建Pod对象，根据所述Pod对象创建所述容器，自动分配所述应用服务的所述服务资源至所述容器；

若所述系统资源的使用量达到所述集群系统的资源总量，则检测每个所述应用服务对应的所述容器，得到每个所述应用服务的服务资源状态；

基于所述服务资源状态，分配所述集群系统中的所述系统资源。

3.根据权利要求2所述的应用服务动态管理方法，其特征在于，所述基于所述服务资源状态，分配所述集群系统中的所述系统资源，包括：

检测每个所述应用服务的所述服务资源状态是否满足回收标准；

若每个所述服务资源状态均不满足所述回收标准，则产生系统资源不足告警；

若所述服务资源状态满足所述回收标准，则根据预设标准回收对应的所述应用服务的所述服务资源，得到回收资源；

将所述回收资源分配至所述请求并发量达到所述并发量阈值的所述应用服务。

4.根据权利要求1所述的应用服务动态管理方法，其特征在于，所述若未达到所述并发量阈值，则根据预设标准回收所述应用服务的服务资源，包括：

以第二预设时间为周期扫描所述容器的日志，得到所述容器的使用频率；

在预设数量个所述第二预设时间后，判断所述容器的使用频率是否满足第一回收标准；其中，所述第一回收标准为所述容器的使用频率为第一预设频率；

若所述容器的使用频率满足所述第一回收标准，则根据第一预设标准回收待回收资源；其中，所述第一预设标准为将满足所述容器运行的最低服务资源以外的服务资源作为所述待回收资源。

5.根据权利要求1所述的应用服务动态管理方法，其特征在于，所述若未达到所述并发量阈值，则根据预设标准回收所述应用服务的服务资源，包括：

以第三预设时间为周期扫描每个所述容器的状态，判断所述容器的状态是否满足第二回收标准；其中，所述第二回收标准为所述容器的状态为宕机状态；

若检测所述容器的状态满足所述第二回收标准，则根据第二预设标准回收待回收资源；其中，所述第二预设标准为将所述容器的全部所述服务资源作为所述待回收资源。

6.根据权利要求1所述的应用服务动态管理方法，其特征在于，所述若未达到所述并发量阈值，则根据预设标准回收所述应用服务的服务资源，包括：

以第四预设时间为周期扫描所述应用服务的日志，得到所述应用服务的使用频率，并判断所述应用服务的使用频率是否满足第三回收标准；其中，所述第三回收标准为所述应用服务的使用频率低于第二预设频率；

若检测所述应用服务的使用频率满足所述第三回收标准，则根据第三预设标准回收待回收资源；其中，所述第三预设标准将对所述服务资源进行预设加权计算得到的服务资源作为所述待回收资源。

7.根据权利要求1至6任一项所述的应用服务动态管理方法，其特征在于，所述集群系统为K8s集群；所述监测所述应用服务的调用信息之前，还包括：

设置所述应用服务的所述服务资源的最小资源阈值和最大资源阈值；

当所述应用服务所使用的服务资源低于所述最小资源阈值时，在所述K8s集群中删除对应的Pod对象，以删除所述容器自动释放所述应用服务的所述服务资源；

当所述应用服务所使用的服务资源高于所述最大资源阈值时，在所述K8s集群中创建对应的Pod对象，以创建所述容器自动增加所述应用服务的所述服务资源。

8.根据权利要求1所述的应用服务动态管理方法，其特征在于，所述终端具有唯一的终端编号；所述若所述调用类型为多端调用，则根据不同终端的请求量占比动态分配所述应用服务的服务额度，包括：

获取所述应用服务的初始服务额度，平均分配所述初始服务额度至每个所述终端；其中，所述终端调用所述应用服务；

以第五预设时间为周期检测每个所述终端的服务使用信息，并根据所述服务使用信息计算对应的所述终端的所述请求量占比；

基于所述请求量占比，根据所述终端编号动态分配所述应用服务的服务额度。

9.根据权利要求8所述的应用服务动态管理方法，其特征在于，所述基于所述请求量占比，根据所述终端编号动态分配所述应用服务的服务额度，包括：

根据所述终端编号，回收所述请求量占比低于预设请求量占比的所述终端的所述服务额度，得到回收服务额度；

根据所述终端编号，将所述回收服务额度分配至所述请求量占比高于预设请求量占比的所述终端。

10.根据权利要求9所述的应用服务动态管理方法，其特征在于，所述基于所述请求量占比，根据所述终端编号动态分配所述应用服务的服务额度之后，还包括：

设置消息队列，并将所述请求量占比低于所述预设请求量占比的所述终端输入至所述消息队列，对所述终端的请求依次排队处理；

为所述请求量占比高于所述预设请求量占比的终端添加优先级，对所述终端的请求按所述优先级处理。

11.一种应用服务动态管理系统，其特征在于，应用如权利要求1至10中任一项所述的应用服务动态管理方法，包括：

服务判断模块，用于监测所述应用服务的调用信息，并根据所述调用信息判断所述应用服务的调用类型；其中，所述调用类型包括单端调用和多端调用；

单边调用模块，用于若所述调用类型为单端调用，则计算所述应用服务的请求并发量是否达到预设的并发量阈值；若达到所述并发量阈值，则根据系统资源对所述应用服务动态分配服务资源；若未达到所述并发量阈值，则根据预设标准回收所述应用服务的服务资源；

多端调用模块，用于若所述调用类型为多端调用，则根据不同终端的请求量占比动态分配所述应用服务的服务额度。

12.一种电子设备，其特征在于，包括存储器、处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至10中任一项所述的应用服务动态管理方法。

13.一种计算机可读存储介质，其特征在于，所述存储介质存储有程序，所述程序被处理器执行实现如权利要求1至10中任一项所述的应用服务动态管理方法。