CN113254209B - 一种容量管理方法、装置、电子设备及可读存储介质 - Google Patents
一种容量管理方法、装置、电子设备及可读存储介质 Download PDFInfo
- Publication number
- CN113254209B CN113254209B CN202110590507.7A CN202110590507A CN113254209B CN 113254209 B CN113254209 B CN 113254209B CN 202110590507 A CN202110590507 A CN 202110590507A CN 113254209 B CN113254209 B CN 113254209B
- Authority
- CN
- China
- Prior art keywords
- index
- module
- target
- custom
- capacity
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5072—Grid computing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/508—Monitor
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Debugging And Monitoring (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请实施例提供了一种容量管理方法、装置、电子设备及可读存储介质,其中,所述方法包括:监控模块获取自定义指标并向指标模块写入所述自定义指标;所述自定义指标为所述指标模块中已注册的指标;所述指标模块用于存储所述自定义指标;当管理模块监听到目标事件时,所述管理模块创建目标对象;其中,所述目标对象用于获取所述指标模块存储的所述自定义指标,并基于所述自定义指标,对目标应用进行容量调整。本申请提供的技术方案,至少可以缓解现有的扩缩容方法由于受限于指标的类型,而导致的扩缩容效果较差的问题。
Description
技术领域
本申请涉及计算机技术领域,具体涉及一种容量管理方法、装置、电子设备及可读存储介质。
背景技术
现有的knative设计架构中,通常是基于hpa策略或kpa策略对应用进行动态扩缩容,即根据应用的cpu指标或rps指标对应用进行扩缩容。然而,当无法获取某一应用的cpu指标和rps指标时,将无法实现该应用的动态扩缩容。可见,现有的扩缩容方法受到现有指标类型的限制,存在扩缩容的效果较差的问题。
发明内容
本申请提供的一种容量管理方法、装置、电子设备及可读存储介质,可以缓解现有的扩缩容方法由于受限于指标的类型,而导致的扩缩容效果较差的问题。
具体技术方案如下:
在本申请实施的第一方面,首先提供了一种容量管理方法,包括:
监控模块获取自定义指标并向指标模块写入所述自定义指标;所述自定义指标为所述指标模块中已注册的指标;所述指标模块用于存储所述自定义指标;
当管理模块监听到目标事件时,所述管理模块创建目标对象;其中,所述目标对象用于获取所述指标模块存储的所述自定义指标,并基于所述自定义指标,对目标应用进行容量调整。
在本申请实施的第二方面,还提供了一种容量管理方法,应用于上述第一方面所述的容量管理系统中的目标对象,所述方法包括:
从指标模块中,获取自定义指标;
判断所述自定义指标是否满足扩缩容条件;
在所述自定义指标满足所述扩缩容条件的情况下,对所述目标应用进行容量调整。
在本申请实施的第三方面,还提供了一种容量管理装置,包括:
获取模块,用于从指标模块中,获取自定义指标;
判断模块,用于判断所述自定义指标是否满足扩缩容条件;
调整模块,用于在所述自定义指标满足所述扩缩容条件的情况下,对所述目标应用进行容量调整。
在本申请的第四方面,还提供了一种电子设备,包括处理器、通信接口、存储器和通信总线,其中,处理器,通信接口,存储器通过通信总线完成相互间的通信;
存储器,用于存放计算机程序;
处理器,用于执行存储器上所存放的程序时,实现执行上述任一所述的容量管理方法的步骤。
在本申请实施的第五方面,还提供了一种计算机可读存储介质,所述计算机可读存储介质中存储有指令,当其在计算机上运行时,使得计算机执行上述任一所述的容量管理方法。
在本申请实施的第六方面,还提供了一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述任一所述的容量管理方法。
本申请实施例中,通过在容量管理系统部署监控模块和管理模块,其中,监控模块可以获取自定义指标,并可将所获取的自定义指标写入指标模块。管理模块可以创建用于执行扩缩容策略的目标对象,所述目标对象可以从所述指标模块中获取自定义指标。这样,在监控模块将所获取到的自定义指标写入指标模块之后,目标对象可以从指标模块获取该自定义指标,然后,目标对象可以对所获取到的自定义指标进行逻辑判断,以确定是否需要对目标应用进行进行容量调整,并且在确定需要对目标应用进行容量调整的情况下,对目标应用的容量进行调整。
此外,由于相关人员可以自行定义自定义指标的指标类型,因此,所述自定义指标可以是任意能够反映目标应用的工作状态的指标。相对于现有技术中仅能够根据应用的cpu指标或rps指标对应用进行扩缩容而言,本申请提供的容量管理方法,可以根据任意类型的指标对目标应用的容量进行调整,从而克服了现有技术中的扩缩容方法,由于受到现有指标类型的限制,导致的扩缩容的效果较差的问题。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。
图1为本申请实施例提供的一种容量管理系统的流程图;
图2为本申请实施例提供的一种容量管理方法的流程图之一;
图3为本申请实施例提供的一种容量管理方法的流程图之一;
图4为本申请实施例中一种容量管理装置的结构示意图;
图5是本申请实施例中一种电子设备的结构图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述。
在knative设计架构中,可以基于knative service模块和其相应的Controller将应用部署于服务器集群,在部署应用的同时,还可以设置应用的扩缩容策略,以实现应用的自动扩缩容。
请参见图1,一种容量管理系统的系统框图,该容量管理系统可以用于实现本申请实施例提供的容量管理方法。所述容量管理系统为在knative设计架构中构建的系统,其中,该容量管理系统中的knative service模块、策略模块和指标模块为knative设计架构中常用的模块,所述knative service模块用于部署目标应用,同时,所述knative service模块还用于在策略模块中创建扩缩容策略。所述策略模块用于接收并存储knativeservice模块创建的各种应用的扩缩容策略。所述指标模块用于存放各种用于指示是否对应用进行扩缩容的指标,例如,可以用于存储现有的cpu指标或rps指标等。
请进一步参见图1,所述容量管理系统中的监控模块和管理模块为本申请实施例为实现本申请中的容量管理方法所部署的功能模块,其中,所述监控模块,可以用于监听策略模块中的创建事件,并在策略模块中的创建事件为目标策略的创建事件时,解析目标策略的配置信息,并基于所解析得到的配置信息获取自定义指标,然后,将所获取到的自定义指标存入指标模块。所述管理模块,可以同样用于监听策略模块中的创建事件,并在策略模块中的创建事件为目标策略的创建事件时,解析目标策略的配置信息,然后,基于配置信息创建目标对象,目标对象可以从指标模块获取自定义指标,并根据所获取的自定义指标对目标应用的容量进行调整。
本申请实施例中所述的目标应用可以部署于服务器集群,其中,所述目标应用可以仅为服务器集群提供服务,也可以为服务器集群所服务的外部用户提供服务。例如,所述目标应用所提供的服务可以是:对服务器集群所接收到的数据进行接收即存储。在此情况下,由于目标应用不提供对外的访问接口,因此,无法获取其cpu指标或rps指标,也即无法基于常规手段实现对目标应用的扩缩容。在此情况下,可以采用本申请实例所提供的容量管理方法对所述目标应用的容量进行调整。具体而言:
请参见图2,图2是本申请实施例提供的一种容量管理方法,应用于容量管理系统,所述方法包括:
步骤201、监控模块获取自定义指标并向指标模块写入所述自定义指标;所述自定义指标为所述指标模块中已注册的指标;所述指标模块用于存储所述自定义指标。
步骤202、当管理模块监听到目标事件时,所述管理模块创建目标对象;其中,所述目标对象用于获取所述指标模块存储的所述自定义指标,并基于所述自定义指标,对目标应用进行容量调整。
上述服务器集群可以是各种服务平台的服务器集群,其中,所述服务器集群可以是Kubernete(k8s)集群。在knative设计架构中,可以基于knative service模块和其相应的Controller将上述目标应用部署于服务器集群,在部署目标应用的同时,还可以设置目标应用的扩缩容策略。其中,在目标应用部署的过程中,所述扩缩容策略将映射为策略模块(PodAutoScaler)中的一个属性,此外,可以自定义扩缩容策略的名称,例如,可以声明目标应用的扩缩容策略为kafka策略(此处仅为是示例性的说明,实际场景中可自定义设置),并且可以在kafka策略的策略内容中写入上述自定义指标以及具体的扩缩容条件等。下文以目标应用的扩缩容策略为kafka策略为例,对本申请提供的容量管理方法作进一步的解释说明。
上述监控模块和管理模块可以是相关人员预先部署的控制器,例如,可以用adapter-controller表示监控模块,用mq-controller表示管理模块,并且可以预先将监控模块和管理模块分别部署于服务器集群,并通过监控模块和管理模块分别监听目标事件。
本申请实施例中,所述目标事件与所述目标应用的扩缩容策略相关联,其中,所述扩缩容策略包括以下信息中的至少一种:自定义指标、扩缩容判断条件或处理策略。所述处理策略可以是指:在确定自定义指标满足扩缩容条件的情况下,如何通过目标对象对目标应用进行扩缩容的具体策略。例如,在本申请一个实施例中,所述自定义指标可以包括:消息队列中的待处理消息的数量;所述扩缩容判断条件可以包括:当待处理消息的数量超过预设阈值时,对目标应用进行扩容;所述处理策略可以包括:当判断自定义指标满足扩容条件的情况下,在服务器集群中,增加启动预设个用于运行所述目标应用的pod。这样,当目标对象获取到所述自定义指标,且通过判断,确定所述自定义指标的指标指大于所述预设阈值时,所述目标对象可以在服务器集群中,增加启动预设个用于运行所述目标应用的pod(此处仅为是示例性的说明,实际场景中可自定义设置)。
这样,当监控模块监听到目标事件时,可以解析上述kafka策略的策略内容,以确定上述自定义指标的内容,当监控模块解析得到自定义指标之后,可以向指标模块注册所述自定义指标,以便于后续自定义指标的通信,其中,所述指标模块可以是服务器集群中的一个存储模块,例如,所述指标模块可以是服务器集群中的Metrics Server组件。监控模块可以基于所解析的内容,实时获取所述自定义指标,且可将所获取到的自定义指标实时写入指标模块。同时,当管理模块监听到目标事件时,可以解析上述kafka策略中的扩缩容条件,这样,可以基于扩缩容条件创建目标对象(k8s hpa),以便于目标对象获取所述指标模块存储的所述自定义指标,并基于所述自定义指标,对目标应用进行容量调整。
具体而言,按照Metrics Server接入规范,通过部署adapter-controller,该adapter-controller在Metrics Server中注册一个MetricsProvider对象,在MetricsProvider对象逻辑中,MetricsProvider对象解析AutoScalerProvider对象中申明的kafka配置,并与kafka建立连接,然后读取应有监听的topic下面的所有分区,并将所有分区的自定义指标汇总,以提供给Metrics Server读取,这样k8shpa就可以从MetricsServer中获取到应有监听的kafka自定义指标,并根据扩缩容条件对目标应用进行容量调整。
此外,在部署所述mq-controller时,可以按照k8s crd接入规范,实现mq-controller对PodAutoScaler对象的监听。当应用注释(Annotations)中申明应用的扩缩容策略为kafka策略时,mq-controller负责对应用进行扩缩容管理。其中,knative service模块部署的应用会自动生成PodAutoScaler对象(策略模块),mq-controller监听到PodAutoScaler对象创建后,解析其里面的应用名称和kafka属性,并创建k8s hpa对象,k8shpa对象的Spec字段中定义了应用的名称、指标名称和扩缩容基数等。
可以理解的是,上述自定义指标可以是与所述目标应用关联的指标。一种可能的实施例中,所述自定义指标可以反映所述目标应用当前的工作状态,例如,所述自定义指标可以反映所述目标应用的消息队列中的队列状态,其中,所目标应用用于消费消息队列中的消息。这样,即可实现基于消息队列的队列状态信息对目标应用进行容量调整。此外,所述自定义指标还可以是所述目标应用的cpu指标或rps指标等。可以理解的是,由于在不同的场景下,所能够获取到的应用的指标类型可能不同,因此,所述自定义指标的指标类型可以由相关人员根据实际情况进行选取,即本申请实施例中,对于自定义指标的指标类型不作限定。
该实施方式中,通过监控模块获取自定义指标,并将自定义指标存储于指标模块,这样,当管理模块接收到目标事件时,创建目标对象,目标对象可以从指标模块中获取自定义指标,并根据所获取的自定义指标对目标应用进行容量调整。由于相关人员可以自行定义自定义指标的指标类型,因此,所述自定义指标可以是任意能够反映目标应用的工作状态的指标。相对于现有技术中仅能够根据应用的cpu指标或rps指标对应用进行扩缩容而言,本申请提供的容量管理方法,可以根据任意类型的指标对目标应用的容量进行调整,从而克服了现有技术中的扩缩容方法,由于受到现有指标类型的限制,导致的扩缩容的效果较差的问题。
此外,采用本申请实例所提供的容量管理方法,由于可以实现对目标应用的容量进行自动调节,从而有利于节省集群资源、实现服务serverless。
本申请另一实施例还提供了另一种容量管理方法,本实施例阐述了:如何实现自定义指标在指标模块与目标对象之间的传递过程。具体而言,在上述实施例的基础上,本实施例提供的方法还包括以下步骤:所述监控模块获取自定义指标并向指标模块写入所述自定义指标之前,所述方法还包括:
所述监控模块向所述指标模块注册所述自定义指标与接口;所述接口用于与所述目标对象进行所述自定义指标的通信。
该实施方式中,通过在容量管理系统部署监控模块和管理模块,其中,监控模块可以获取自定义指标,并可将所获取的自定义指标写入指标模块。管理模块可以创建用于执行扩缩容策略的目标对象,所述目标对象可以从所述指标模块中获取自定义指标。这样,在监控模块将所获取到的自定义指标写入指标模块之后,目标对象可以从指标模块获取该自定义指标,然后,目标对象可以对所获取到的自定义指标进行逻辑判断,以确定是否需要对目标应用进行进行容量调整,并且在确定需要对目标应用进行容量调整的情况下,对目标应用的容量进行调整。
此外,由于相关人员可以自行定义自定义指标的指标类型,因此,所述自定义指标可以是任意能够反映目标应用的工作状态的指标。相对于现有技术中仅能够根据应用的cpu指标或rps指标对应用进行扩缩容而言,本申请提供的容量管理方法,可以根据任意类型的指标对目标应用的容量进行调整,从而克服了现有技术中的扩缩容方法,由于受到现有指标类型的限制,导致的扩缩容的效果较差的问题。
本申请另一实施例还提供了另一种容量管理方法,本实施例阐述了:管理模块和监控模块监听目标事件的具体过程,具体地,在上述实施例的基础上,本实施例提供的方法包括以下步骤:
所述管理模块监听策略模块(PodAutoScaler)的事件信息;
当所述事件信息指示所述策略模块的当前策略为目标策略,且事件类型为创建事件时,所述管理模块监听到所述目标事件。
可以理解的是,上述服务器集群上所部署的各种应用的扩缩容策略均可部署于上述策略模块,且不同策略对应的控制器均可对策略模型进行监听,例如,当某一应用声明的扩缩容策略为kpa策略时,则由kpa策略对应的控制器对该应用进行容量调整。
上述目标策略可以为kafka策略,相应地,上述目标事件可以为kafka策略的创建事件,即策略模块接收到目标应用写入kafka策略的事件。在此情况下,监控模块和管理模块监听到目标事件,并可分别解析kafka策略,以便于后续实现对目标应用的容量调整。
本申请另一实施例还提供了另一种容量管理方法,本实施例阐述了:自定义指标的具体内容。具体地,在上述实施例的基础上,本实施例提供的方法包括以下步骤:所述自定义指标包括如下至少一项:所述目标应用的消息队列中的消息数量、预设时间段内所述消息队列中的消息数量的变化量。
其中,服务器集群可以将所接收到的目标消息存储于所述消息队列,所述目标应用可以从所述消息队列中读取进行消息消息队列中的目标消息。在本申请一个具体实施例中,所述消息队列可以是订单信息的任务队列,用户在对某一商品下单之后,订单信息(如用户账号、商品信息、订单金额和交易时间等)将会被上传至服务器集群,服务器集群在接收到所述订单信息之后,可以以待处理消息的形式存储于所述消息队列中,这样,后续目标应用在读取到该待处理消息时,可以解析该待处理消息中的相关数据,并将解析得到的数据进行存储。
具体地,所述消息队列中的消息数量可以是指:所述消息队列中,待目标应用消费的消息的数量。这样,当消息队列中的消息数量累积较多时,可以增大所述目标应用的容量,这样,可以提高目标应用对消息队列中消息的消费速度,从而缓解所述消息队列中消息存储的压力。相应地,当所述消息队列中的消息数量较少时,可以适当减小所述目标应用的容量,以释放目标应用所占用的物理资源。
此外,所述预设时间段内所述消息队列中的消息数量的变化量:可以是指预设时间段内消息队列中消息数量的增加量,或者,消息数量的减少量,其中,所述预设时间段可以根据实际需要设置的一个时长,例如,在本申请一个实施例中,所述预设时间段可以是60s。这样,当预设时间段内,消息队列中的消息增加量超过一定数量时,即消息队列中,消息的增速较大时,则可以适当增大所述目标应用的容量,以降低消息队列中消息数量的增速,避免消息队列中出现消息积压严重的问题。相应地,当预设时间段所述消息队列中消息的减少量超过一定数量时,即消息队列中,消息减小速度较大时,则可以适当减小所述目标应用的容量,以降低所述消息队列中消息的减小速度。从而确保存入目标队列的消息速度,与目标应用消费目标队列中的消息速度相匹配。
可以理解的是,目标对象可以基于目标队列中,消息数量与消息数量的变化量中的其中一项指标,对目标应用的容量进行管理,当然,目标对象还可以同时即可该两项指标对目标应用的容量进行管理。
本申请另一实施例还提供了另一种容量管理方法,本实施例阐述了:目标策略信息的具体内容,以及目标对象对目标应用进行容量调整的具体过程。具体地,在上述实施例的基础上,本实施例提供的方法包括以下步骤:所述管理模块创建目标对象,包括:
所述管理模块解析所述目标事件,得到目标策略信息;其中,所述目标策略信息至少包括:所述自定义指标对应的扩缩容条件;
所述管理模块基于所述目标策略信息,创建所述目标对象,所述目标对象基于所述扩缩容条件和所述自定义指标,对所述目标应用进行容量调整。
具体地,所述扩缩容条件可以包括扩容子条件和缩容子条件,这样,在所述自定义指标满足所述扩容子条件的情况下,所述目标对象可以对所述目标应用进行扩容;在所述自定义指标满足所述缩容子条件的情况下,所述目标对象可以对所述目标应用进行缩容。
在本申请一个实施例中,所述自定义指标包括如下至少一项:所述目标应用的消息队列中的消息数量、预设时间段内所述消息队列中的消息数量的变化量。所述扩容子条件包括以下条件中的至少一种:所述消息数量大于第一预设值,或者,所述消息增加量大于第二预设值;所述缩容子条件包括以下条件中的至少一种:所述消息数量小于第三预设值,或者,所述消息减少量大于所述第一预设值,且所述消息数量小于第四预设值。
具体地,可以预先确定所述目标队列中的正常波动范围,其中,所述第一预设值可以所述正常波动范围中的最大值,所述第三预设值可以是所述正常波动范围的最小值。这样,当所述消息数量大于第一预设值,即所述消息队列中所积压的消息数量超过正常范围时,可以确定需要对目标应用进行扩容,以缓解消息队列中存在消息积压的问题。相应地,当所述消息数量小于第三预设值时,即所述消息队列中所存储的消息数量少于正常范围时,则可能所述目标应用消费的消息速度过快,为避免资源浪费,可以适当减小所述目标应用的容量。
上述第一预设值可以根据所述预设时长确定,例如,当所述预设时长为60s时,所述第一预设值的取值可以为60。上述第四预设值的取值可以小于所述第三预设值,例如,所述第四预设值可以为所述第三预设值的二分之一。这样,当消息队列中每秒增大的消息数量超过1条时,确定消息存入消息队列中的速度过快,且目标应用消费消息的速度过慢,此时,可以适当增大目标应用的容量,以提高目标应用消费消息的速度。相应地,当消息队列中每秒减少的消息数量超过1条,且所述消息速度小于第四预设值时,确定消息存入消息队列中的速度过慢,且目标应用消费消息的速度过快,并且所述消息队列中剩余的消息数量小于正常范围。因此,此时可以适当减小目标应用的容量,以减小目标应用消费消息的速度。
本申请另一实施例还提供了另一种容量管理方法,本实施例阐述了:监控模块和管理模块部署于服务器集群中的部署方式。具体地,在上述实施例的基础上,本实施例提供的方法包括以下步骤:
所述监控模块获取自定义指标并向指标模块写入所述自定义指标之前,所述方法还包括:将所述监控模块与所述管理模块中的至少一者,通过镜像文件部署于目标集群,所述目标应用为部署于所述目标集群的应用。
具体地,相关人员可以在预先编写所述监控模块和管理模块的相关程序,然后,将所述监控模块与所述管理模块中的至少一者,通过镜像文件部署于目标集群。例如,可以将所述监控模块与所述管理模块分别以镜像文件的方式部署于所述服务器集群,此外,还可以将所述监控模块与所述管理模块中,一者以镜像文件的方式部署于所述服务器集群,另一者由相关人员手动部署于所述服务器集群,对此,不作限制。
该实施方式中,通过采用镜像文件的形式部署所述监控模块和/或管理模块,相对于常规技术手段中采用的手动部署方式而言,可以提高部署的效率。同时,由于镜像文件在制作时,通常是经过严格的审核的文件,因此,相对于常规技术手段中采用的手动部署方式而言,可以提高所部署得到的模块的稳定性和安全性。
请参见图3,图3为本申请实施例提供的另一种容量管理方法,所述容量管理方法应用于上述实施例中的目标对象,所述方法包括以下步骤:
步骤301、从指标模块中,获取自定义指标;
步骤302、判断所述自定义指标是否满足扩缩容条件;
步骤303、在所述自定义指标满足所述扩缩容条件的情况下,对所述目标应用进行容量调整。
具体地,由于所述管理模块在监听到目标事件时,创建目标对象。因此,所述管理模块可以在监听到目标事件时,对目标事件进行解析,得到所述扩缩容条件,然后,基于所述扩缩容条件创建所述目标对象,即所述目标对象在构建时,已存储有所述扩缩容条件。因此,目标对象在从指标模块获取到自定义指标的情况下,可以判断所获取到的自定义指标是否满足扩缩容条件,并且可以在自定义指标满足扩缩容条件的情况下,对目标应用的容量进行调整。在自定义指标不满足扩缩容条件的情况下,则无需做额外的调整,换言之,可以视作保持所述目标应用的容量不变。
该实施方式中,所述监控模块可以每隔一定时长,获取自定义指标,并且实时更新所述指标模块中的自定义指标。相应地,所述目标对象可以每隔一定时长从所述指标模块获取最新的自定义指标,并基于所述最新的自定义指标判断是否满足扩缩容条件。从而实现对目标应用的容量进行自动调节的技术效果。
本申请另一实施例还提供了另一种容量管理方法,本实施例与上述实施例的区别在于进一步阐述了:自定义指标和扩缩容条件的具体内容。具体地,在上述实施例的基础上,本实施例提供的方法包括以下步骤:
所述自定义指标包括如下至少一项:所述目标应用的消息队列中的消息数量、预设时间段内所述消息队列中的消息变化量,所述消息变化量包括消息增加量或消息减少量;
所述扩缩容条件包括扩容子条件和/或缩容子条件,其中,所述扩容子条件包括以下条件中的至少一种:所述消息数量大于第一预设值,或者,所述消息增加量大于第二预设值;
所述缩容子条件包括以下条件中的至少一种:所述消息数量小于第三预设值,或者,所述消息减少量大于所述第一预设值,且所述消息数量小于第四预设值。
具体地,可以预先确定所述目标队列中的正常波动范围,其中,所述第一预设值可以所述正常波动范围中的最大值,所述第三预设值可以是所述正常波动范围的最小值。这样,当所述消息数量大于第一预设值,即所述消息队列中所积压的消息数量超过正常范围时,可以确定需要对目标应用进行扩容,以缓解消息队列中存在消息积压的问题。相应地,当所述消息数量小于第三预设值时,即所述消息队列中所存储的消息数量少于正常范围时,则可能所述目标应用消费的消息速度过快,为避免资源浪费,可以适当减小所述目标应用的容量。
上述第一预设值可以根据所述预设时长确定,例如,当所述预设时长为60s时,所述第一预设值的取值可以为60。上述第四预设值的取值可以小于所述第三预设值,例如,所述第四预设值可以为所述第三预设值的二分之一。这样,当消息队列中每秒增大的消息数量超过1条时,确定消息存入消息队列中的速度过快,且目标应用消费消息的速度过慢,此时,可以适当增大目标应用的容量,以提高目标应用消费消息的速度。相应地,当消息队列中每秒减少的消息数量超过1条,且所述消息速度小于第四预设值时,确定消息存入消息队列中的速度过慢,且目标应用消费消息的速度过快,并且所述消息队列中剩余的消息数量小于正常范围。因此,此时可以适当减小目标应用的容量,以减小目标应用消费消息的速度。
本申请另一实施例还提供了另一种容量管理方法,本实施例与上述实施例的区别在于进一步阐述了:容量调整的具体过程。具体地,在上述实施例的基础上,本实施例提供的方法包括以下步骤:
所述在所述自定义指标满足所述扩缩容条件的情况下,对所述目标应用进行容量调整,包括:
在所述自定义指标满足所述扩容子条件的情况下,对所述目标应用进行扩容;
在所述自定义指标满足所述缩容子条件的情况下,对所述目标应用进行缩容。
具体地,在所述服务器集群中,可以开启多个pod运行所述目标应用。在对目标应用的容量进行调整时,可以是调整所述服务器集群中启动的运行目标应用的pod的数量。例如,当需要增大所述目标应用的容量时,可以增加启动预设个用于运行所述目标应用的pod,相应地,当需要减小所述目标应用的容量时,可以关闭预设个已经启动的pod。
具体地,上述kafka策略中,还可以包括扩容基数和缩容基数,这样,在管理模块解析得到kafka策略中的配置信息之后,可以获取所述扩容基数和缩容基数,并可在创建目标对象时,将所述扩容基数和缩容基数传递至目标对象。如此,目标对象在对目标应用进行扩缩容的过程中,基于所述扩容基数和缩容基数对目标应用进行扩缩容。
其中,所述扩容基数可以是指在对目标应用进行扩容时,每次增加启动的、用于运行目标应用的pod的数量;相应地,所述缩容基数可以是指在对目标应用进行缩容时,每次关闭的运行有目标应用的pod的数量。所述扩容基数和缩容基数的取值可以相同,也可以不同。
例如,在本申请一个实施例中,所述第一扩缩容基数和第二扩缩容基数的取值均为N,N为大于0的整数。这样,所述目标对象确定所述自定义指标满足缩容子条件时,则在所述服务器集群中,关闭N个运行有所述目标应用的pod,以实现所述目标应用的缩容。相应地,当所述目标对应确定所述自定义指标满足所述缩容子条件时,则在现有pod的基础上,再启动N个用于运行所述目标应用的pod,以实现所述目标应用的扩容。在该实施例中,N的取值可以自定义设计,本发明实施例对此无特别限制。例如,N可以取值为1。
此外,由于对目标应用的容量进行调整之后,目标应用的消息队列的队列状态信息在较短的时间内不会存在较大的变化。因此,可以在每次对目标应用的容量进行调整之后,等待预设时长,以使调整之后的pod的工作状态相对稳定之后,再获取所述自定义指标,并再次基于所获取到的自定义指标判断所述目标应用是否满足扩缩容条件。然后,按照上述容量管理方法,对目标应用的容量进行调整,其中,所述预设时长可以根据实际情况进行选取,例如,所述预设时长可以是5分钟-30分钟。
该实施方式中,通过基于扩缩容基数实现对目标应用的容量进行调节,这样,可以使得目标应用的容量有规律的恢复至与消息队列中的消息数量和消息变化量相匹配,从而可以避免过渡增大目标应用的容量,或者,过渡减小目标应用的容量。
示例性的,现以图1所示的系统架构为例,对本发明实施例所提供的扩缩容策略进行示例说明。
请参见图1,在本申请一个实施例中,以目标策略为kafka策略为例,对基于图1所示的容量管理系统,对目标应用的容量进行管理的过程作进一步的解释说明:
当监控模块监听到策略模块的创建事件为kafka策略的创建事件时,读取kafka策略中的配置信息,并且,监控模块在读取到kafka策略中的配置信息之后,在指标模块中注册一个MetricsProvider对象,在MetricsProvider对象逻辑中,MetricsProvider对象解析策略模块中申明的kafka配置,并与kafka建立连接,然后读取应有监听的topic下面的所有分区,并将所有分区的自定义指标汇总,以提供给指标模块读取。同时,管理模块在监听到策略模块的创建事件为kafka策略的创建事件时,创建目标对象,目标对象从所述指标模块中获取自定义指标,并判断自定义指标是否满足扩缩容条件,在自定义指标满足扩缩容条件的情况下,对目标应用的容量进行调整,从而实现对目标应用的容量调整过程。其中,可以通过将所述自定义指标与预设阈值进行对比,以确定所述自定义指标是否满足扩缩容条件。示例性的,一方面,当所述自定义指标的值超过预设阈值的两倍时,确认所述自定义指标满足扩容条件,所述目标对象对所述目标应用进行扩容;另一方面,当所述自定义指标的值小于所述预设阈值的二分之一时,确认所述自定义指标满足缩容条件,所述目标对象对所述目标应用进行缩容。
通过本方案,能够基于监控模块与管理模块的前述部署,实现对任意自定义指标的获取,并能够以此为依据进行后续的扩容或缩容的容量管理。相较于现有技术仅能够基于cpu指标和rps指标实现容量控制的方案,本方案对自定义指标的类型并无特别限制,而且能够基于这些自定义指标实现动态扩缩容,例如,能够基于knative应用消息的队列状态实现动态扩缩容,这也能够在一定程度上节省集群资源,扩缩容效果较好。
请参见图4,图4为本申请实施例提供的一种容量管理装置400,所述装置包括:
获取模块401,用于从指标模块中,获取自定义指标;
判断模块402,用于判断所述自定义指标是否满足扩缩容条件;
调整模块403,用于在所述自定义指标满足所述扩缩容条件的情况下,对所述目标应用进行容量调整。
可选地,所述自定义指标包括如下至少一项:所述目标应用的消息队列中的消息数量、预设时间段内所述消息队列中的消息变化量,所述消息变化量包括消息增加量或消息减少量;
所述扩缩容条件包括扩容子条件和/或缩容子条件,其中,所述扩容子条件包括以下条件中的至少一种:所述消息数量大于第一预设值,或者,所述消息增加量大于第二预设值;
所述缩容子条件包括以下条件中的至少一种:所述消息数量小于第三预设值,或者,所述消息减少量大于所述第一预设值,且所述消息数量小于第四预设值。
可选地,所述调整模块403,具体用于在所述自定义指标满足所述扩容子条件的情况下,基于第一扩缩容基数,对所述目标应用进行扩容;
所述调整模块403,还用于在所述自定义指标满足所述缩容子条件的情况下,基于第二扩缩容基数,对所述目标应用进行缩容。
上述容量管理装置400能够实现本申请方法实施例的容量管理方法能够实现的各个过程,以及达到相同的有益效果,为避免重复,这里不再赘述。
本申请实施例还提供了一种电子设备,如图5所示,包括处理器501、通信接口502、存储器503和通信总线504,其中,处理器501,通信接口502,存储器503通过通信总线504完成相互间的通信,
存储器503,用于存放计算机程序;
处理器501,用于执行存储器503上所存放的程序时,实现如前述任一实施例所述的容量管理方法。
上述终端提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect,简称PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture,简称EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示,图5中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
通信接口用于上述终端与其他设备之间的通信。
存储器可以包括随机存取存储器(Random Access Memory,简称RAM),也可以包括非易失性存储器(non-volatile memory),例如至少一个磁盘存储器。可选地,存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,简称CPU)、网络处理器(Network Processor,简称NP)等;还可以是数字信号处理器(Digital Signal Processing,简称DSP)、专用集成电路(Application SpecificIntegrated Circuit,简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array,简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
在本申请提供的又一实施例中,还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有指令,当其在计算机上运行时,使得计算机执行上述实施例中任一所述的容量管理方法。
在本申请提供的又一实施例中,还提供了一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述实施例中任一所述的容量管理方法。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用相关的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
Claims (10)
1.一种容量管理方法,其特征在于,应用于容量管理系统,所述方法包括:
监控模块获取自定义指标并向指标模块写入所述自定义指标;所述自定义指标为所述指标模块中已注册的指标;所述指标模块用于存储所述自定义指标;
当管理模块监听到目标事件时,所述管理模块创建目标对象;其中,所述目标对象用于获取所述指标模块存储的所述自定义指标,并基于所述自定义指标,对目标应用进行容量调整;
所述监控模块,用于监听策略模块中的创建事件,并在策略模块中的创建事件为目标策略的创建事件时,解析目标策略的配置信息,并基于所解析得到的配置信息获取自定义指标,将所获取到的自定义指标存入指标模块;
所述管理模块,用于监听策略模块中的创建事件,并在策略模块中的创建事件为目标策略的创建事件时,解析目标策略的配置信息,基于配置信息创建目标对象;
所述监控模块获取自定义指标并向指标模块写入所述自定义指标之前,所述方法还包括:
所述监控模块向所述指标模块注册所述自定义指标与接口;所述接口用于与所述目标对象进行所述自定义指标的通信。
2.根据权利要求1所述的方法,其特征在于,所述管理模块创建目标对象,包括:
所述管理模块解析所述目标事件,得到目标策略信息;其中,所述目标策略信息至少包括:所述自定义指标对应的扩缩容条件;
所述管理模块基于所述目标策略信息,创建所述目标对象,所述目标对象基于所述扩缩容条件和所述自定义指标,对所述目标应用进行容量调整。
3.根据权利要求1所述的方法,其特征在于,所述自定义指标包括如下至少一种:所述目标应用的消息队列中的消息数量、预设时间段内所述消息队列中的消息数量的变化量。
4.根据权利要求1所述的方法,其特征在于,所述监控模块获取自定义指标并向指标模块写入所述自定义指标之前,所述方法还包括:将所述监控模块与所述管理模块中的至少一者,通过镜像文件部署于目标集群,所述目标应用为部署于所述目标集群的应用。
5.根据权利要求1所述的方法,其特征在于,所述基于所述自定义指标,对目标应用进行容量调整,包括:
从指标模块中,获取自定义指标;
判断所述自定义指标是否满足扩缩容条件;
在所述自定义指标满足所述扩缩容条件的情况下,对所述目标应用进行容量调整。
6.根据权利要求5所述的方法,其特征在于,所述自定义指标包括如下至少一项:所述目标应用的消息队列中的消息数量、预设时间段内所述消息队列中的消息变化量,所述消息变化量包括消息增加量或消息减少量;
所述扩缩容条件包括扩容子条件和/或缩容子条件;
其中,所述扩容子条件包括以下条件中的至少一种:所述消息数量大于第一预设值,或者,所述消息增加量大于第二预设值;
所述缩容子条件包括以下条件中的至少一种:所述消息数量小于第三预设值,或者,所述消息减少量大于所述第一预设值,且所述消息数量小于第四预设值。
7.根据权利要求6所述的方法,其特征在于,所述在所述自定义指标满足所述扩缩容条件的情况下,对所述目标应用进行容量调整,包括:
在所述自定义指标满足所述扩容子条件的情况下,对所述目标应用进行扩容;
在所述自定义指标满足所述缩容子条件的情况下,对所述目标应用进行缩容。
8.一种容量管理装置,其特征在于,包括:
监控模块,用于监听策略模块中的创建事件,并在策略模块中的创建事件为目标策略的创建事件时,解析目标策略的配置信息,并基于所解析得到的配置信息获取自定义指标,将所获取到的自定义指标存入指标模块;
管理模块,用于监听策略模块中的创建事件,并在策略模块中的创建事件为目标策略的创建事件时,解析目标策略的配置信息,基于配置信息创建目标对象;
所述监控模块向所述指标模块注册所述自定义指标与接口;所述接口用于与所述目标对象进行所述自定义指标的通信;
所述目标对象包括:
获取模块,用于从指标模块中,获取自定义指标;
判断模块,用于判断所述自定义指标是否满足扩缩容条件;
调整模块,用于在所述自定义指标满足所述扩缩容条件的情况下,对目标应用进行容量调整。
9.一种电子设备,其特征在于,包括处理器、通信接口、存储器和通信总线,其中,处理器,通信接口,存储器通过通信总线完成相互间的通信;
存储器,用于存放计算机程序;
处理器,用于执行存储器上所存放的程序时,实现权利要求1-7任一所述的方法的步骤。
10.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现如权利要求1-7中任一所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110590507.7A CN113254209B (zh) | 2021-05-28 | 2021-05-28 | 一种容量管理方法、装置、电子设备及可读存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110590507.7A CN113254209B (zh) | 2021-05-28 | 2021-05-28 | 一种容量管理方法、装置、电子设备及可读存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113254209A CN113254209A (zh) | 2021-08-13 |
CN113254209B true CN113254209B (zh) | 2023-08-29 |
Family
ID=77185195
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110590507.7A Active CN113254209B (zh) | 2021-05-28 | 2021-05-28 | 一种容量管理方法、装置、电子设备及可读存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113254209B (zh) |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107231264A (zh) * | 2017-07-25 | 2017-10-03 | 北京百度网讯科技有限公司 | 用于管理云服务器的容量的方法和装置 |
CN109067862A (zh) * | 2018-07-23 | 2018-12-21 | 北京邮电大学 | API Gateway自动伸缩的方法与装置 |
CN109446032A (zh) * | 2018-12-19 | 2019-03-08 | 福建新大陆软件工程有限公司 | Kubernetes副本扩缩容的方法及系统 |
CN110971430A (zh) * | 2018-09-29 | 2020-04-07 | 北京国双科技有限公司 | 自动化扩容缩容的控制方法、装置、存储介质及处理器 |
CN111526031A (zh) * | 2019-12-20 | 2020-08-11 | 西安抱朴通信科技有限公司 | 一种业务虚拟网络功能vnf的扩缩容方法及设备 |
CN111858257A (zh) * | 2020-07-28 | 2020-10-30 | 浪潮云信息技术股份公司 | 一种实现获取容器集群资源使用数据的系统及方法 |
CN112181649A (zh) * | 2020-09-22 | 2021-01-05 | 广州品唯软件有限公司 | 一种容器资源调整方法、装置、计算机设备及存储介质 |
CN112799854A (zh) * | 2021-04-15 | 2021-05-14 | 腾讯科技(深圳)有限公司 | 任务处理方法、装置、电子设备及可读存储介质 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9547534B2 (en) * | 2014-10-10 | 2017-01-17 | International Business Machines Corporation | Autoscaling applications in shared cloud resources |
US10547672B2 (en) * | 2017-04-27 | 2020-01-28 | Microsoft Technology Licensing, Llc | Anti-flapping system for autoscaling resources in cloud networks |
US10747568B2 (en) * | 2017-05-30 | 2020-08-18 | Magalix Corporation | Systems and methods for managing a cloud computing environment |
-
2021
- 2021-05-28 CN CN202110590507.7A patent/CN113254209B/zh active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107231264A (zh) * | 2017-07-25 | 2017-10-03 | 北京百度网讯科技有限公司 | 用于管理云服务器的容量的方法和装置 |
CN109067862A (zh) * | 2018-07-23 | 2018-12-21 | 北京邮电大学 | API Gateway自动伸缩的方法与装置 |
CN110971430A (zh) * | 2018-09-29 | 2020-04-07 | 北京国双科技有限公司 | 自动化扩容缩容的控制方法、装置、存储介质及处理器 |
CN109446032A (zh) * | 2018-12-19 | 2019-03-08 | 福建新大陆软件工程有限公司 | Kubernetes副本扩缩容的方法及系统 |
CN111526031A (zh) * | 2019-12-20 | 2020-08-11 | 西安抱朴通信科技有限公司 | 一种业务虚拟网络功能vnf的扩缩容方法及设备 |
CN111858257A (zh) * | 2020-07-28 | 2020-10-30 | 浪潮云信息技术股份公司 | 一种实现获取容器集群资源使用数据的系统及方法 |
CN112181649A (zh) * | 2020-09-22 | 2021-01-05 | 广州品唯软件有限公司 | 一种容器资源调整方法、装置、计算机设备及存储介质 |
CN112799854A (zh) * | 2021-04-15 | 2021-05-14 | 腾讯科技(深圳)有限公司 | 任务处理方法、装置、电子设备及可读存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN113254209A (zh) | 2021-08-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109358816B (zh) | 一种分布式存储系统的流控方法及装置 | |
CN110289994B (zh) | 一种集群容量调整方法及装置 | |
CN105656810B (zh) | 一种更新应用程序的方法及装置 | |
CN108540533B (zh) | 一种应答请求的方法和装置 | |
CN110933178B (zh) | 调整集群系统内的节点配置的方法及服务器 | |
CN110187995B (zh) | 一种熔断对端节点的方法及熔断装置 | |
CN109560976B (zh) | 一种消息延迟的监控方法及装置 | |
CN111988240B (zh) | 一种数据发送方法、装置、电子设备及存储介质 | |
CN109739627B (zh) | 任务的调度方法、电子设备及介质 | |
CN112367384B (zh) | 基于Kafka集群的动态限速方法、装置以及计算机设备 | |
CN111291252A (zh) | 一种每秒查询率的调整方法、装置、电子设备及存储介质 | |
US20150286548A1 (en) | Information processing device and method | |
CN113254209B (zh) | 一种容量管理方法、装置、电子设备及可读存储介质 | |
CN111949421B (zh) | Sdk调用方法、装置、电子设备和计算机可读存储介质 | |
US10599195B2 (en) | Method and apparatus for controlling hot plug operation of CPU in mobile terminal | |
CN110209548B (zh) | 服务控制方法、系统、电子设备及计算机可读存储介质 | |
CN112612578A (zh) | 一种虚拟机监控方法和装置 | |
CN110955579A (zh) | 一种基于Ambari的大数据平台的监测方法 | |
CN111092945A (zh) | 一种基于系统资源的抽样数据推送和接收方主动保护方法 | |
CN110929102B (zh) | 一种数据处理方法、装置及电子设备 | |
CN114465958B (zh) | 一种输入输出的控制方法、装置及介质 | |
CN116166424A (zh) | 一种应用系统自动扩缩容方法、装置、设备以及存储介质 | |
CN108494853B (zh) | 一种海量设备状态自维护方法及其装置和系统 | |
CN114745277B (zh) | 公有云跨域专线的弹性伸缩方法、装置、电子设备及介质 | |
CN114296906B (zh) | 业务动态伸缩方法、装置、设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |