CN112732425B - 一种应用管理方法、装置、电子设备及存储介质 - Google Patents

一种应用管理方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
CN112732425B
CN112732425B CN202011634870.6A CN202011634870A CN112732425B CN 112732425 B CN112732425 B CN 112732425B CN 202011634870 A CN202011634870 A CN 202011634870A CN 112732425 B CN112732425 B CN 112732425B
Authority
CN
China
Prior art keywords
server
application program
application
candidate
access
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
Application number
CN202011634870.6A
Other languages
English (en)
Other versions
CN112732425A (zh
Inventor
王绎超
方学阳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing QIYI Century Science and Technology Co Ltd
Original Assignee
Beijing QIYI Century Science and Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Beijing QIYI Century Science and Technology Co Ltd filed Critical Beijing QIYI Century Science and Technology Co Ltd
Priority to CN202011634870.6A priority Critical patent/CN112732425B/zh
Publication of CN112732425A publication Critical patent/CN112732425A/zh
Application granted granted Critical
Publication of CN112732425B publication Critical patent/CN112732425B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • 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
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • 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/5019—Workload prediction
    • 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/502—Proximity

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)
  • Information Transfer Between Computers (AREA)

Abstract

本申请涉及一种应用管理方法、装置、电子设备及存储介质。其中方法包括：获取服务器集群中各服务器对每个应用程序在预设时段内的访问量；基于访问量，确定各候选策略的总网络开销；候选策略为服务器集群中的各服务器部署应用程序的可实施策略；根据目标策略，调度应用程序的镜像文件；其中，目标策略在各候选策略中的总网络开销最小。采用本申请的方案可以在有限的边缘服务器资源条件下，充分发挥边缘计算的优势，减少终端设备访问应用程序的网络开销，提升用户的服务质量；并且，各服务器中设置有Docker容器，如此，在对应用程序进行调度时，可以采用对应用程序的镜像文件进行调度的方式，这更加便于对应用程序的调取和部署，提高部署效率。

Description

一种应用管理方法、装置、电子设备及存储介质
技术领域
本申请涉及计算技术领域，尤其涉及一种应用管理方法、装置、电子设备及存储介质。
背景技术
随着移动设备的广泛使用和通信技术的快速发展，以及工业互联网、自动驾驶、智能交通、安防监控、智慧城市等场景的普及，形成一种边缘计算系统，包括：远离终端部署的云计算中心，以及部署于更靠近终端网络边缘的边缘服务器，由边缘服务器提供计算和存储服务。
但是，由于边缘服务器的存储和计算资源是有限的，应用程序无法在每个边缘服务器中进行部署，导致在无法直接访问各个边缘服务器中的应用程序的情况下，网络开销（包括网络延时）过大的问题。
针对相关技术中存在的技术问题，目前尚未提供有效的解决方案。
发明内容
为了解决上述技术问题，本申请提供了一种应用管理方法、装置、电子设备及存储介质。
第一方面，本申请实施例提供了一种应用管理方法，包括：
获取服务器集群中各服务器对每个应用程序在预设时段内的访问量，所述访问量包括：直接访问量或间接访问量；
基于所述访问量，确定各候选策略的总网络开销；所述候选策略为所述服务器集群中的各服务器部署应用程序的可实施策略；
根据目标策略，调度所述应用程序的镜像文件；其中，所述目标策略在各候选策略中的总网络开销最小。
第二方面，本申请实施例提供了一种数据处理装置，包括：
第一确定模块，用于获取服务器集群中各服务器对每个应用程序在预设时段内的访问量，所述访问量包括：直接访问量或间接访问量；
第二确定模块，用于基于所述访问量，确定各候选策略的总网络开销；所述候选策略为所述服务器集群中的各服务器部署应用程序的可实施策略；
调度模块，用于根据目标策略，调度所述应用程序的镜像文件；其中，所述目标策略在各候选策略中的总网络开销最小。
第三方面，本申请实施例提供了一种电子设备，包括：处理器、通信接口、存储器和通信总线，其中，所述处理器、通信接口和存储器通过通信总线完成相互间的通信；
所述存储器，用于存放计算机程序；
所述处理器，用于执行所述计算机程序时，实现如前述任一项所述的处理方法。
第四方面，本申请实施例提供了一种存储介质，所述存储介质包括存储的程序，其中，所述程序运行时执行如前任一项所述的方法步骤。
本申请实施例提供的上述技术方案与现有技术相比具有如下优点：
本申请实施例提供的该方法，在多边缘服务器环境中，可以根据服务器集群的当前的总网络开销，得到可实施的部署方案，然后确定该部署方案下，对各个应用程序的部署进行调整后可以得到更优的总网络开销，因此可以确定更优的总网络开销下，服务器集群中部署各个应用程序的目标服务器，进而，采用本申请的方案可以在有限的边缘服务器资源条件下，充分发挥边缘计算的优势，减少终端设备访问应用程序的网络开销，提升用户的服务质量；并且，本发明实施例中，各服务器中设置有Docker容器，如此，在对应用程序进行调度时，可以采用对应用程序的镜像文件进行调度的方式，这更加便于对应用程序的调取和部署，提高部署效率。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种服务器集群系统的框图；
图2为本申请实施例提供的一种应用管理方法的流程示意图；
图3为本申请另一实施例提供的一种应用管理方法的流程示意图；
图4为本申请另一实施例提供的一种应用管理方法的流程示意图；
图5为本申请另一实施例提供的一种应用管理方法的流程示意图；
图6为本申请另一实施例提供的一种服务器集群系统的框图；
图7为本申请另一实施例提供的一种应用管理装置的框图；
图8为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。
如图1所示，本申请实施例提供了一种服务器集群系统，包括：云计算中心服务器（为便于说明，后续简称为：云计算中心）1和边缘服务器2；每个云计算中心服务器1连接有至少一个边缘服务器2，当边缘服务器存在多个时，各个边缘服务器2之间一般情况下可以是两两之间相互通信连接。
云计算中心服务器1一般用于管控不同的应用程序在各个边缘服务器2上的部署；在一般情况下，云计算中心服务器1并不直接为覆盖区域中的终端设备提供服务，而是由系统中的各个边缘服务器2，分别向各边缘服务器2所属的局部区域中的终端设备提供服务。
如背景技术所述，由于边缘服务器的计算资源与服务能力也是有限的，在每个边缘服务器中都部署所有应用程序的方式，既会造成较大的资源浪费，又在技术与成本上难以实现。因此，在计算器集群场景中，就会出现直接访问与间接访问两种情况。
示例性的一种场景中，可以有多个边缘服务器2，以2个为例，为便于区分，给他们命名为2a和2b。进一步的，当终端设备位于某一边缘服务器2a的服务服务区域内，并需要访问某一应用程序B时，会存在如下所述3种情况：
（1）、边缘服务器2a中部署有应用程序B，此时，可以由边缘服务器2a直接为终端设备提供应用程序B的相应服务，换言之，终端设备可以通过边缘服务器2a对应用程序B进行直接访问。
（2）、当应用程序B并未部署在边缘服务器2a上，边缘服务器2a便需要通过对部署有应用程序B的相邻的边缘服务器2b进行访问，以使终端设备达到访问应用程序B的目的，即终端设备通过边缘服务器2a对部署于边缘服务器2b上的应用程序B进行间接访问。
（3）、当所有边缘服务器2（包括2a和2b）上均未部署有应用程序B时，则终端设备通过边缘服务器2a访问位于云计算中心服务器1中的应用程序B，以使终端设备达到访问应用程序B的目的，即终端设备对应用程序B进行间接访问。
对于上述三种情况，终端设备对应用程序B进行访问造成的网络开销，存在如下所述大小关系：（1）<（2）<（3）。
由上可知，对于任意一个边缘服务器而言，应用程序的部署方式不同，会影响该边缘服务器的网络开销；从而，对于包含多个边缘服务器的服务器集群而言，应用程序的部署方式不同也直接影响到系统整体的总网络开销。本发明实施例正是基于降低系统的总网络开销的考虑，提出一种应用管理方法，通过调整应用程序的部署位置，来优化整个系统的网络开销。
本申请实施例提供一种应用管理方法，该方法可以应用于云计算中心或任一边缘服务器，但实际场景中，云计算中心一般用于管理所有边缘服务器，因此，在示例性的一种实施例中，该方法可以应用于云计算中心。
示例性的，如图2所示，该方法包括但不限于如下所述的步骤S1至S3：
步骤S1，获取服务器集群中各服务器对每个应用程序在预设时段内的访问量，访问量包括：直接访问量或间接访问量。
具体的，服务器集群，是指用于一起提供同一种服务的多个服务器的集合。在本申请中，服务器集群中的服务器，可以是如前所述的边缘服务器或者云计算中心服务器。一般情况下，在服务器集群中，云计算中心服务器中会部署有所有的应用程序。
预设时间段，可以是预设得到，用于进行访问量统计的时间段；并且，对于应用部署的每个时间点，其对应的预设时间段一般各不相同。
示例性的，可以选择与当前时间点（进行目标策略确定的时间点）最接近的历史时间段作为预设时间段，并且以该预设时间段中的访问量作为分析数据，用于分析得到目标策略。举例的：对于时间点18:00来说，预设时间段可以是17:30~17:59；对于时间点20:00来说，由于17:30~17:59距离当前时间太久，再根据该时间段中的各应用程序的访问量进行应用部署，则可能会存在差异性过大的问题，因此采用的预设时间段为19:30~19:59。
此外，对于不同时间或对不同应用程序进行访问的间接访问的网络开销可能会存在差异，因此预设时间段在选择过程中，可以选择得到与需要进行应用部署的时间段对应的时间段（例如：前一天的同一时间段，或者前一周的同一时间段等），因而可以使得到的预计访问量更加匹配于应用部署的时间段的真实情况，以使得应用部署的网络开销更小。
示例性的，由于对应用程序的访问访问量可能存在周期性（例如：每天、每周、每月等）变化的情况，因此，还可以前一周期的同一时间段的访问量，作为目标策略对应的时间段的分析数据。举例的：在当前需要分析的时间段是12月20号19:30~19:59时，可以基于12月19号19:30~19:59的访问量实现本方案。
另，可以理解的是，本发明实施例对于预设时间段的时段长度无特别限制，前述举例中的29分钟仅为示例性的说明本方案。实际场景中，预设时间段的时段长度可以自定义预设，例如，预设时间段的时段长度可以为：6小时、24小时（1天）或60分钟等，不再赘述。
在一些实施例中，如前述的方法，对于任意一个服务器中的任意一个应用程序，所述步骤S1中获取每个服务器对每个应用程序在预设时段内的访问量，如前所述，访问量包括：直接访问量或间接访问量。此时，S1具体可以是如下所述步骤S101或S102中的一种：
步骤S101，在预设时间段内，获取应用程序直接接受客户端访问的次数，得到服务器针对应用程序的直接访问量。其中，直接访问量，可以是在预设时间段内，当应用程序部署于本服务器上时，本服务器接受所服务的终端设备直接访问时的访问量。
或者，
步骤S102，在预设时间段内，获取服务器中转客户端的访问请求的次数，得到服务器针对应用程序的间接访问量；其中，服务器用于为客户端访问周边服务器进行中转，周边服务器当前部署有所述应用程序。其中，间接访问量，可以是在预设时间段内，当应用程序未部署于向终端设备提供服务的服务器上时，该服务器需要对周边服务器中部署的应用程序进行访问，才可使终端设备能够对应用程序进行访问的访问量。
因此，对于某一服务器对某一应用程序进行访问的访问量，只存在直接访问量或间接访问量中的一种。但是，对于整个服务器集群而言，基于各边缘服务器中部署的应用程序的不同，S1步骤获取到的访问量可能包括直接访问量与间接访问量。例如，S1步骤获取到的访问量可以包括但不限于：边缘服务器A1针对应用程序的直接访问量、边缘服务器A2针对应用程序的间接访问量。
步骤S2，基于访问量，确定各候选策略的总网络开销；候选策略为服务器集群中的各服务器部署应用程序的可实施策略。
具体的，可实时策略，可以是预计得到的，将各个应用程序分别部署至服务器集群内的某一服务器上之后，各个服务器仍可正常提供服务，或者各个应用程序可以完成部署到服务器中的部署策略。
在获取访问量之后，可以基于预设时间段内，访问量中的直接访问量以及间接访问量，根据各个候选策略，得到应用从当前部署的服务器迁移至预计服务器的预计情况中，各个服务器或者客户端对该应用进行访问时，预计的直接访问量以及间接访问量。
步骤S3，根据目标策略，调度应用程序的镜像文件；其中，目标策略在各候选策略中的总网络开销最小。
具体的，在确定各个候选策略对应的总网络开销之后，即可从中确定总网络开销最小的候选策略，并将该候选策略记为目标策略。
在确定目标策略之后，即可确定各个应用程序将要部署至的服务器，因此，可以根据目标策略对各个应用程序进行调度。
本发明实施例中，各服务器中安装有Docker容器（或称为Docker引擎），如此，可以通过在Docker容器中部署应用程序的镜像文件，实现对应用程序的部署。在此情况下，当需要对应用程序进行调度时，只需要调度应用程序的镜像文件即可。
具体而言，通过Docker容器，将应用以及依赖包打包到一个可移植的镜像文件中，然后发布到安装了Docker引擎的服务器上；接收到镜像文件的服务器可以通过运行镜像文件，完成在本服务器中启动该应用的目的，从而可以在各个边缘服务器中方便的进行应用程序的部署和迁移。本发明实施例中，通过采用Docker容器，可以实现虚拟化的应用部署，进而确保各个应用程序的隔离性，一台服务器中可以运行很多容器，从而提升了服务器的资源利用率。
基于本实施例中的方案，在多边缘服务器环境中，可以根据服务器集群的当前的总网络开销，得到满足可实施的部署方案，然后确定该部署方案下，对各个应用程序的部署进行调整后可以得到更优的总网络开销，因此可以确定更优的总网络开销下，服务器集群中部署各个应用程序的目标服务器，进而，采用本申请的方案可以在有限的边缘服务器资源条件下，充分发挥边缘计算的优势，减少终端设备访问应用程序的网络开销，提升用户的服务质量。
在一些实施例中，如前述的方法，服务器为边缘服务器；周边服务器为：服务器的相邻边缘服务器，或者云计算中心服务器。
具体的，接受客户端（即：终端设备）访问的服务器一般为边缘服务器，在边缘服务器中未部署有应用程序时，边缘服务器便需要从相邻服务器中访问应用程序，进一步的，当相邻边缘服务器中也未部署有所需访问的应用程序时，便需要对云计算中心服务器中访问该应用程序。
其中一种可选的实现方式中，当存在一个客户端，需要通过一个或多个（通常情况下只需要一次中转，但部分特殊场景中可能需要多次中转）中转服务器中转后才能访问得到应用程序时，所述方法还包括如下所述步骤A1至A3：
步骤A1，确定访问链路中的中转服务器数量；
具体的，访问链路可以是客户端通过中转服务器对部署有相应应用程序的边缘服务器进行访问时的链路，其中，一般情况下会选择最短的链路进行访问，中转服务器是用于中转客户端的访问请求的服务器；因此，中转服务器数量与访问链路中的中转服务器的数量相等。在访问链路中，由于除该部署有相应应用程序的边缘服务器之外的其它服务器中，不存在该客户端所要访问的应用程序，因此可以将除部署有相应应用程序的边缘服务器之外的其他服务器都记为中转服务器。
步骤A2，在访问链路中，确定客户端对中转服务器进行访问的第一子网络开销，以及中转服务器对访问链路中的相邻的中转服务器访问的第二子网络开销。
具体的，第一子网络开销，为客户端对中转服务器进行访问时的单次网络开销。
第二子网络开销，为中转服务器对访问链路中的相邻的中转服务器访问时的单次网络开销。
步骤A3，根据中转服务器数量与第二子网络开销的乘积，以及第一子网络开销，得到间接访问网络开销。
具体的，在一般情况下，为了使访问链路最短，因此在进行多次中转时，该访问链路中的每个中转服务器只进行一次中转，因而，中转的次数与中转服务器数量一致。
在确定中转服务器数量以及第二子网络开销的乘积，即可确定中转访问对应的网络开销，最后再将乘积与第一子网络开销相加，即可得到间接访问网络开销。
如图3所示，在一些实施例中，如前述的方法，所述步骤S2基于访问量，确定各候选策略的总网络开销，包括如下所述步骤S21至S24：
步骤S21，遍历服务器集群中的各服务器部署各应用程序的可实施策略，得到多个候选策略。
具体的，其中一种遍历的方法可以是，确定各应用程序部署于各服务器时的部署策略，然后基于各个服务器的资源上限等信息，从所有部署策略中，筛选得到可实施策略，进而得到候选策略。
步骤S22，对于任意一种候选策略，根据各服务器针对各应用程序的直接访问量以及间接访问量，确定该候选策略中各服务器针对各应用程序的预计访问方式。
具体的，可以根据预设时间段中的访问量，得到当应用程序部署于边缘服务器中时，各服务器针对于该应用程序的直接访问量以及间接访问量；由于根据候选策略中，可以预计得到，应用程序预计部署的预设服务器，因此可以根据各服务器针对于该应用程序的直接访问量以及间接访问量，确定在候选策略中，各服务器对该应用程序是进行直接访问还是间接访问，即确定预计访问方式。
举例的：当存在服务器A、服务器B以及服务器C时，当原应用部署策略中，应用程序A部署于服务器A时，服务器A针对于应用程序A的直接访问量为100，服务器B针对于服务器A中的应用程序A的间接访问量为200，服务器C针对于服务器A中的应用程序A的直接访问量为300；则当将应用程序A按照某一候选策略部署于服务器C时，可以得到服务器A对服务器C中的应用程序A的访问方式是间接访问，且访问量为100；服务器B对服务器C中的应用程序A的访问方式是间接访问，且访问量为200；服务器C对应用程序A的访问方式则是直接访问，且访问量为300。
步骤S23，基于预计访问方式，确定各服务器针对各应用程序的预计网络开销与预计访问量。
由上可知，对于每一个应用程序来说，各个服务器对该应用程序的访问量是按照预设时间段中各个服务器对该应用程序的访问量确定的，本方案基于时间的周期性变化进行计算，可以视作当前时刻的访问量与预设时间段的访问量相同，那么，发生变化的只是服务器对该应用程序的访问方式发生变化。
此外，由于直接访问的网络开销以及间接访问的网络开销都是相对固定的，因此，当确定预计访问量以及访问方式之后，即可确定每个服务器针对每个应用程序的预计网络开销。
步骤S24，基于预计网络开销，获取该候选策略对应的总网络开销。
具体的，在确定每个服务器针对每个应用程序的预计网络开销之后，通过将所有预计网络开销相加，即可得到候选策略对应的总网络开销。
进而，通过本实施例中的方法，可以基于预设时间段内的访问量，快速确定各个候选策略的总网络开销，可以有效提高数据处理的效率。
在一些实施例中，如前述的方法，所述步骤S23基于预计网络开销，获取该候选策略对应的总网络开销，可以采用如下所述步骤S231或S232中的其中一个方法实现：
步骤S231，基于预计网络开销与预计访问量，确定该候选策略中每个应用程序对应的单个应用网络开销；并获取单个应用网络开销之和，得到该候选策略对应的总网络开销。
具体的，在得到某一候选策略的各个预计网络开销之后，可以确定与每一个应用程序对应的所有预计网络开销，进而可以通过相加得到每个应用程序对应的单个应用网络开销。
最后再根据单个应用网络开销之和，即可得到该候选策略对应的总网络开销。
或者，
步骤S232，基于预计网络开销与预计访问量，确定该候选策略中每个服务器对应的单个服务器网络开销；并获取单个服务器网络开销之和，得到该候选策略对应的总网络开销。
具体的，在得到某一候选策略的各个预计网络开销之后，可以确定与每一个服务器对应的所有预计网络开销，进而可以通过相加得到每个服务器对应的单个服务器网络开销。
最后再根据单个服务器网络开销之和，即可得到该候选策略对应的总网络开销。
进而，通过本实施例中的方法，可以通过两种方式确定总网络开销，进而，可以根据实际应用部署的情况，在两种部署方式中选定更适合的计算方式，以快速确定总网络开销。例如：当对少量应用程序进行部署的调整时，可以通过计算应用程序的单个应用网络开销的变化，确定总网络开销；当对服务器集群中的服务器进行增减时，可以通过计算单个服务器网络开销的变化，确定总网络开销。
如图4所示，在一些实施例中，如前述的方法，所述步骤S21遍历服务器集群中的各服务器部署应用程序的可实施策略，得到多个候选策略，包括如下所述步骤S211至S213：
步骤S211，遍历在各服务器中部署应用程序的部署策略。
具体的，部署策略，可以是将各个应用程序都部署在服务器集群中时的策略。
步骤S212，确定部署策略中，各个候选服务器的可用资源量，以及各个候选服务器预计部署的应用程序的总资源占用量。
具体的，可用资源量，可以是服务器可使用的计算资源量。一般的，每个服务器的可用资源量都是固定不变的。
资源占用量，可以是服务器中部署的所有应用程序需要占用的资源总量。
由于，一般情况下，每个应用程序的可用资源量都是相对固定的。因此，在确定服务器中部署的所有应用程序之后，即可确定各个候选服务器预计部署的应用程序的总资源占用量。
可选的，候选服务器中资源的类型包括以下至少一项：CPU资源、运行内存资源或存储资源。
步骤S213，在可用资源量大于或等于总资源占用量时，将部署策略作为候选策略。
根据各个服务器对应的可用资源量与总资源占用量，可以确定各个服务器是否能够按照部署策略，部署对应的目标应用。
并且，在可用资源量小于总资源占用量时，说明该服务器无法按照部署策略，完成应用程序的部署任务。反之，在可用资源量大于或等于总资源占用量时，说明该服务器可以完成部署任务，进而可以将该部署策略作为候选策略。
因此，应用程序部署的目标就是在各个服务器的资源约束条件下，确定每个应用程序的部署方案，使得系统中访问应用程序的总网络开销最小。
通过本实施例中的方法，可以筛选得到可实施的候选策略，以免因为造成应用程序无法正确部署至服务器中，导致客户端无法访问该应用程序的情况。
根据前述实施例中的方法，可以对服务器集群中的所有应用程序都进行统一的调度；但是，当预设时间段内，只有数量较少的一个或多个第一应用程序的访问量发生较大变化时，为了减少需要分析的可实施策略的数量，可以只获取第一应用程序的部署方式发生变化的可实施策略，以减少需遍历的可实施策略的数量，提高处理效率。
基于上述原因，在一些实施例中，如前述的方法，所述步骤S21遍历服务器集群中的各服务器部署应用程序的可实施策略，得到多个候选策略，具体包括：
在第二应用程序的部署方式不变的前提下，遍历服务器集群中的各服务器部署第一应用程序的可实施策略，得到多个候选策略；其中，第二应用程序为除第一应用程序之外的其他应用程序。
具体的，第一应用程序，可以是需要在各个服务器之间进行迁移的应用程序。其中，第一应用程序，可以是所有应用程序中的一个或多个。
第二应用程序，可以是不需要在各个服务器之间进行迁移的应用程序。
因此，基于本实施例中的方案，可以在部分应用程序进行迁移时，只需在需要进行迁移的第一应用程序对应的候选策略中，选择得到最终的目标策略。相应的，在进行应用程序的后续调度过程中，也只需要调度第一应用程序即可，可以有效降低数据迁移量，提高迁移效率。
在一些实施例中，如前述的方法，所述步骤S2确定各候选策略的总网络开销之前，方法还包括如下所述步骤C1和C2：
步骤C1，获取应用程序在预设时段内访问量的变化率。
具体的，可以将预设时间段拆分为多个连续且时长相同的子时间段，并确定各个子时间段中接收的访问量，然后计算后一子时间段的访问量与前一子时间段的访问量之间的差值，之后，计算该差值与前一子时间段的访问量比值，即可得到各个时间段对应的访问量之间的变化率。可以理解，变化率可以是增长率，也可以是下降率。
步骤C2，在变化率达到预设变化率阈值时，执行确定各候选策略的总网络开销的步骤。
具体的，变化率阈值，可以是预先设置的，用于限定是否执行下一步骤的数值。可选的，变化率阈值，可以根据实际应用中网络开销对系统的影响程度进行调整，一般的，当网络开销对系统的影响越大，变化率阈值越小。
通过本实施例中的方法，可以无需按照固定周期对各个应用程序进行重新部署，只需检测应用程序的变化率达到预设变化率阈值，检测的信息简单，同时又能及时调整部署，以适应终端设备对应用程序的访问量变化情况。
示例性的一种实施例中，当整个服务器集群中包含一个云计算中心服务器和个边缘服务器/>时，边缘服务器可以用/>来表示。每个边缘服务器/>都服务一块区域，该区域内的终端设备通过客户端访问部署于服务器集群内应用程序时，都会经过该边缘服务器。边缘服务器/>的CPU资源为/>，运行内存资源为/>，存储资源为/>。边缘服务器之间也可以相互连接，设/>代表边缘服务器/>和边缘服务器/>之间的连接情况，若/>则表示边缘服务器/>和边缘服务器/>之间可以相互访问。
可以采用下述方法构建得到，用于确定服务器集群系统的某一候选策略可行性的访问开销模型：
1.将应用程序打包为Docker镜像文件，然后统计各镜像文件运行所需的CPU资源、运行内存资源以及存储资源，为后续的应用部署提供基础。设应用程序有n个，可以用来表示，第i个应用程序d i所需的CPU资源为cpu i，运行内存资源为/>，存储资源为disk i/>。
2.监控边缘服务器节点中各个应用的访问量：在每个边缘服务器节点中部署监控模块，得到当前时间段各应用程序的访问量。设预设时间段内边缘服务器所服务的区域内，监控得到的各个应用程序的访问量分别为/>。
3.构建整个系统的访问开销模型：设每个应用程序的部署方案为，如果/>表示应用d i部署在边缘服务器节点e j中。如果某一应用程序在所有边缘服务器中都没有部署，则只能访问云计算中心服务器。设直接访问所在区域的边缘服务器的网络开销为a，访问相邻边缘服务器的网络开销为b，访问云计算中心的网络开销为/>，通常来说/>。在边缘服务器e j的服务区域内访问应用d i，存在以下几种情况
a.如果应用程序d i部署在边缘服务器e j中，边缘服务器ej针对应用程序di的直接访问开销c i =a×p i j，a为终端设备直接访问所在区域的边缘服务器中的应用程序时，对应的单次网络开销,p i j为终端设备针对应用程序di的直接访问量。
b.对相邻的边缘服务器进行间接访问时：如果应用程序d i没有部署在边缘服务器e j中，边缘服务器e j则从相邻的其他边缘服务器中查找该应用程序d i。如果相邻边缘服务器中存在应用程序d，访问开销为c i =b×p i j。b为访问相邻边缘服务器中的应用程序时的单次网络开销。
c.对云计算中心服务器进行间接访问时：如果相邻的其他边缘服务器中也没有部署应用d i，则需要从云计算中心服务器访问应用程序d i，访问开销为：c i =z×p i j。z为访问云计算中心服务器中的应用程序时的单次网络开销。
可以得到整个系统中访问应用程序的总开销为：
。
此外还需要考虑边缘服务器节点的资源约束条件。对于，需要满足：
将应用程序打包为Docker镜像文件进行应用程序部署或调度时，可以统计各镜像文件运行所需的CPU资源、运行内存资源或存储资源，为后续的应用部署提供基础。设应用程序有n个，可以用D={d 1 ,d 1 ,…,d 1 }来表示，第i个应用程序d i所需的CPU资源为cpu i，运行内存资源为memory i，存储资源为disk i。
对于任一服务器e j，其中e j满足，/>，其中需要部署的应用程序需要满足如下至少一种：
其中，x ij用于表征应用程序d i是否部署在服务器e j中，一般的，当x ij =1时，表征应用程序d i部署在服务器e j中。服务器e j的最大CPU资源为cpu i max，最大运行内存资源为memory i max，最大存储资源为disk i max，即对于服务器来说，资源约束条件可以包括但不限于如下至少一种：最大CPU资源，最大运行内存资源，最大存储资源。
基于前述计算公式，可以得到包含前述各计算公式的应用部署模型，然后对该模型求解最优解。该计算模型实际为非线性0-1整数规划问题，这种情况下，如果服务器数量较多，解空间太大造成常规方法的计算复杂度太大，可以采用遗传算法、蚁群算法、粒子群算法等启发式算法进行求解，在可接受的计算成本内得到近似最优解。该近似最优解所对应的候选策略，即为应用程序的最优部署方案（也即目标策略）后，就可以将Docker镜像文件迁移到相应的服务器中运行。
如图5所示，在一些实施例中，如前述的方法，所述步骤S3根据目标策略，调度应用程序的镜像文件，包括如下所述步骤S311至S313：
步骤S311，根据目标策略，确定用于部署应用程序的目标服务器。
具体的，在得到各个候选策略之后，可以根据前述实施例中的方法预计得到各个候选策略对应的总网络开销，因而可以在所有总网络开销中选择得到最小的最小总网络开销，然后将对应于最小总网络开销的候选策略作为目标策略，进而可以根据目标策略中对各个应用程序的部署信息，确定用于部署应用程序的目标服务器。
步骤S312，向目标服务器发送部署指令，部署指令用于指示目标服务器部署应用程序对应的镜像文件。
具体的，部署指令，可以是由云计算中心服务器生成的，用于指示目标服务器部署应用程序对应的镜像文件的指令。部署指令可以包括但不限于镜像文件信息或镜像文件（自身）中的至少一种，其中，镜像文件信息可以包括但不限于：镜像文件的路径、名称或其他自定义唯一标识中的至少一种。
在该实施例中，各目标服务器在接收到部署指令之后，即可根据部署指令完成对镜像文件的安装部署。具体而言，任意一个目标服务器在接收到部署指令后，此时，可能有两种情况：若部署指令中仅携带了镜像文件信息，也即并未直接携带镜像文件自身，则目标服务器可根据镜像文件信息下载相应的镜像文件，再运行该镜像文件以进行应用程序的安装部署；或者，若部署指令直接携带了镜像文件，则目标服务器接收到部署指令后，可直接运行该镜像文件以进行应用程序的安装部署。
步骤S313，向当前部署有应用程序的边缘服务器发送解除部署指令，解除部署指令用于指示边缘服务器解除部署镜像文件。
具体的，解除部署指令，由云计算中心服务器生成并发送至边缘服务器，用于使边缘服务器对指定的应用程序的镜像文件进行解除部署的指令。解除部署指令可以包括但不限于镜像文件信息，如前所述，镜像文件信息可以包括但不限于镜像文件的路径、名称或其他自定义唯一标识中的至少一种。
在该实施例中，各当前部署有应用程序的边缘服务器在接收到解除部署指令之后，即可根据解除部署指令完成对镜像文件的解除部署处理。具体而言，任意一个当前部署有应用程序的边缘服务器在接收到解除部署指令后，可对镜像文件信息对应的镜像文件解除部署，示例性的，解除部署处理可以包括但不限于：卸载、删除、禁用镜像文件中的至少一种。
可选的，云计算中心服务器在确定目标服务器完成安装应用程序之后，将解除部署指令发送至当前部署有应用程序的边缘服务器，该边缘服务器在接受到解除部署指令之后，解除部署镜像文件；进一步的，还可以对镜像文件进行删除，以避免镜像文件占用周边服务器的计算资源。
在前述图5所示的实施例中，是由云计算中心通过发送指令的方式实现镜像文件的调度。除此之外，步骤S3还可以有其他的实施方式。在一些实施例中，所述步骤S3调度应用程序的镜像文件，还可以通过但不限于以下两种方法实现：
示例性的一种实施例中，云计算中心直接向目标服务器发送应用程序的镜像文件，以使得目标服务器运行镜像文件以安装所述应用程序。
具体的，向目标服务器发送镜像文件的行为，可以是由云计算中心服务器执行的，相应地，目标服务器在接收到镜像文件之后，即可通过目标服务器中安装的Docker容器，来运行应用程序的镜像文件，完成应用程序的安装部署。
在该实施例中，云计算中心还可以向当前部署有应用程序的边缘服务器发送解除部署指令，完成整个服务器集群系统的整体配置。
在该实施例中，云计算中心无需发送调度指令，而是直接向目标服务器发送镜像文件，这即意味着指示目标服务器运行该镜像文件以完成应用程序的安装部署，进而可以使镜像文件的部署的步骤更少，减少发生传输错误的概率，提高部署的精准度。
或者，
示例性的另一种实施例中，云计算中心还可以向当前部署有应用程序的边缘服务器发送部署转移指令，部署转移指令用于指示边缘服务器向目标服务器发送应用程序的镜像文件，以使得目标服务器运行镜像文件以安装应用程序。
在该实现方法中，转移部署指令，用于使接收得到该指令的边缘服务器，能够将其安装的镜像文件，进行转移部署，并且转移部署指令中可以包括安装镜像文件的目标服务器的地址信息，以及，需要进行转移部署的镜像文件和/或镜像文件信息（例如：名称、安装位置或存储位置等），以使边缘服务器根据转移部署指令确定需要进行转移部署的镜像文件，以及，目标服务器（也即转移部署的镜像文件的接收方）。
相应地，当前部署有应用程序的边缘服务器在接收得到转移部署指令之后，即可确定转移部署指令中指定的镜像文件与目标服务器，从而，向目标服务器发送该镜像文件或镜像文件信息中的至少一种。那么，目标服务器在接收到该镜像文件和/或镜像文件信息之后，即可在Docker容器中运行该镜像文件，完成应用程序的安装部署。
在该实施例中，接收到转移部署指令的边缘服务器，还可以将自身部署的该镜像文件对应的应用程序进行解除部署处理。具体处理方式可参照前文，不再重复。
在该实施例中，云计算中心在确定出目标策略后，只需要向服务器集群中的部分服务器（也即：当前部署有应用程序的边缘服务器）发送转移部署指令，即可以使镜像文件的传输在各个边缘服务器之间进行，换言之，云计算中心可以间接实现对整个服务器集群系统的整体调度，这有利于降低云计算中心服务器的数据传输压力，同时可以提高应用的部署效率。
通过本实施例中的方法，由于各边缘服务器中设置有Docker容器，因此，可以通过镜像文件的调度实现对目标应用程序的便捷迁移，实际场景中，可以根据云计算中心服务器或者边缘服务器的性能，选择前述任意一种方式来进行迁移，以提高应用程序的迁移效率。
综上，本发明实施例所提供的应用管理方法中的方法，能够在多边缘服务器环境中，通过采用将应用程序以Docker镜像文件在边缘服务器中进行安装，可以更加便于应用程序的迁移和部署。同时，本发明实施例能够根据应用程序的访问量，在边缘服务器资源约束条件下构建访问开销模型，求解得到在满足资源约束条件下的最优的应用部署方案，进而再根据应用部署方案调度应用程序的Docker镜像文件。本文提出的应用部署方案在有限的边缘服务器资源条件下，充分发挥边缘计算的优势，减少终端设备的网络开销，提升应用服务的服务质量。
如图6所示，对前述实施例中的方法进行应用的一个应用例中：
云计算中心服务器1可以包括：应用Docker镜像打包模块、部署决策模块、应用运行模块以及Docker镜像调度模块；
其中，部署决策模块，可以用于实现前述实施例中：根据获取的访问量，确定各候选策略的总网络开销，然后基于总网络开销，从各候选策略中总网络开销最小的目标策略，并根据目标策略确定对各个应用程序进行调度的部署策略。
应用Docker镜像打包模块：将应用程序打包为镜像文件，并得到各镜像文件运行所需的CPU资源、运行内存资源及存储资源，作为应用部署的基础。
Docker镜像调度模块：根据部署决策模块计算得到的目标策略，将各个应用程序的镜像文件调度到相应的边缘服务器上。
应用运行模块：云计算中心服务器中安装了所有应用程序，从而为各个边缘服务器，以及为各个边缘服务器所在区域内的终端设备（即：客户端）提供服务。
边缘服务器2可以包括：应用运行模块、应用访问量监控模块以及通信模块；
应用运行模块：可以是每个边缘服务器上安装的Docker容器，进而可以运行应用程序的镜像文件，从而为边缘服务器所在区域内的终端设备提供服务。
应用访问量监控模块：监控当前时间段每个应用的访问量数据，为应用的部署决策提供依据。
通信模块：负责与相邻的边缘服务器和云计算中心服务器进行网络数据通信，将应用程序的镜像文件的迁移至其他边缘服务器，或者将访问量数据发送至云计算中心服务器，或者将终端设备的访问请求的中转至其他边缘服务器或云计算中心服务器。
根据本申请的另一方面，还提供一种应用管理装置，包括：
第一确定模块11，用于获取服务器集群中各服务器对每个应用程序在预设时段内的访问量，访问量包括：直接访问量或间接访问量；
第二确定模块12，用于基于访问量，确定各候选策略的总网络开销；候选策略为服务器集群中的各服务器部署应用程序的可实施策略；
调度模块13，用于根据目标策略，调度应用程序的镜像文件；其中，目标策略在各候选策略中的总网络开销最小。
可选的，第一确定模块11，用于对于任意一个服务器中的任意一个应用程序，在所述预设时间段内，获取所述应用程序直接接受客户端访问的次数，得到所述服务器针对所述应用程序的所述直接访问量；或者，在所述预设时间段内，获取所述服务器中转所述客户端的访问请求的次数，得到所述服务器针对所述应用程序的间接访问量；其中，所述服务器用于为所述客户端访问周边服务器进行中转，所述周边服务器当前部署有所述应用程序。
可选的，所述服务器为边缘服务器；所述周边服务器为：所述服务器的相邻边缘服务器或者云计算中心服务器。
可选的，第二确定模块12，用于遍历所述服务器集群中的各服务器部署各应用程序的可实施策略，得到多个所述候选策略；对于任意一种所述候选策略，根据各服务器针对各应用程序的直接访问量以及间接访问量，确定该候选策略中各服务器针对各应用程序的预计访问方式；基于所述预计访问方式，确定各服务器针对各应用程序的预计网络开销与预计访问量；基于所述预计网络开销，获取该候选策略对应的总网络开销。
可选的，第二确定模块12，用于基于所述预计网络开销与所述预计访问量，确定该候选策略中每个所述应用程序对应的单个应用网络开销；并获取所述单个应用网络开销之和，得到该候选策略对应的所述总网络开销；或者，基于所述预计网络开销与所述预计访问量，确定该候选策略中每个所述服务器对应的单个服务器网络开销；并获取所述单个服务器网络开销之和，得到该候选策略对应的所述总网络开销。
可选的，第二确定模块12，用于遍历在各服务器中部署应用程序的部署策略；确定所述部署策略中，各个候选服务器的可用资源量，以及各个所述候选服务器预计部署的应用程序的总资源占用量；在所述可用资源量大于或等于所述总资源占用量时，将所述部署策略作为所述候选策略。
可选的，所述候选服务器中资源的类型包括以下至少一项：CPU资源、运行内存资源或存储资源。
可选的，第二确定模块12，用于在第二应用程序的部署方式不变的前提下，遍历所述服务器集群中的各服务器部署第一应用程序的可实施策略，得到多个所述候选策略；其中，所述第二应用程序为除所述第一应用程序之外的其他应用程序。
可选的，该装置还包括：执行确定模块，用于在确定各候选策略的总网络开销之前，获取所述应用程序在预设时段内访问量的变化率；在所述变化率达到预设变化率阈值时，执行所述确定各候选策略的总网络开销的步骤。
可选的，调度模块13，用于根据所述目标策略，确定用于部署所述应用程序的目标服务器；向所述目标服务器发送部署指令，所述部署指令用于指示所述目标服务器部署所述应用程序的镜像文件；向当前部署有所述应用程序的边缘服务器发送解除部署指令，所述解除部署指令用于指示所述边缘服务器解除部署所述应用程序的镜像文件。
可选的，调度模块13，用于向所述目标服务器发送所述应用程序的镜像文件，以使得所述目标服务器运行所述镜像文件以安装所述应用程序；或者，向当前部署有所述应用程序的边缘服务器发送部署转移指令，所述部署转移指令用于指示所述边缘服务器向所述目标服务器发送所述应用程序的镜像文件，以使得所述目标服务器运行所述镜像文件以安装所述应用程序。
基于本实施例中的方案，在多边缘服务器环境中，可以根据服务器集群的当前的总网络开销，得到满足可实施的部署方案，然后确定该部署方案下，对各个应用程序的部署进行调整后可以得到更优的总网络开销，因此可以确定更优的总网络开销下，服务器集群中部署各个应用程序的目标服务器，进而，采用本申请的方案可以在有限的边缘服务器资源条件下，充分发挥边缘计算的优势，减少终端设备访问应用程序的网络开销，提升用户的服务质量。
如图8所示，根据本申请的另一个实施例，还提供一种电子设备，电子设备可以包括：处理器1501、通信接口1502、存储器1503和通信总线1504，其中，处理器1501，通信接口1502，存储器1503通过通信总线1504完成相互间的通信。
存储器1503，用于存放计算机程序；
处理器1501，用于执行存储器1503上所存放的程序时，实现上述方法实施例的步骤。
上述电子设备提到的总线可以是外设部件互连标准(Peripheral ComponentInterconnect ，PCI) 总线或扩展工业标准结构(Extended Industry StandardArchitecture，EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
通信接口用于上述电子设备与其他设备之间的通信。
存储器可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(DigitalSignalProcessing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
本申请实施例还提供一种存储介质，存储介质包括存储的程序，其中，程序运行时执行上述方法实施例的方法步骤。
需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述仅是本发明的具体实施方式，使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。

Claims (13)

1.一种应用管理方法，其特征在于，包括：
获取服务器集群中各服务器对每个应用程序在预设时段内的访问量，所述访问量包括：直接访问量或间接访问量；
基于所述访问量，确定各候选策略的总网络开销，包括：遍历所述服务器集群中的各服务器部署各应用程序的可实施策略，得到多个所述候选策略；对于任意一种所述候选策略，根据各服务器针对各应用程序的直接访问量以及间接访问量，确定该候选策略中各服务器针对各应用程序的预计访问方式；基于所述预计访问方式，确定各服务器针对各应用程序的预计网络开销与预计访问量；基于所述预计网络开销，获取该候选策略对应的总网络开销；所述候选策略为所述服务器集群中的各服务器部署应用程序的可实施策略；
根据目标策略，调度所述应用程序的镜像文件；其中，所述目标策略在各候选策略中的总网络开销最小。
2.根据权利要求1所述的方法，其特征在于，对于任意一个服务器中的任意一个应用程序，所述获取各服务器对每个应用程序在预设时段内的访问量，包括：
在所述预设时段内，获取所述应用程序直接接受客户端访问的次数，得到所述服务器针对所述应用程序的所述直接访问量；
或者，在所述预设时段内，获取所述服务器中转所述客户端的访问请求的次数，得到所述服务器针对所述应用程序的间接访问量；其中，所述服务器用于为所述客户端访问周边服务器进行中转，所述周边服务器当前部署有所述应用程序。
3.根据权利要求2所述的方法，其特征在于，所述服务器为边缘服务器；所述周边服务器为：所述服务器的相邻边缘服务器或者云计算中心服务器。
4.根据权利要求1所述的方法，其特征在于，所述基于所述预计网络开销，获取该候选策略对应的总网络开销，包括：
基于所述预计网络开销与所述预计访问量，确定该候选策略中每个所述应用程序对应的单个应用网络开销；并获取所述单个应用网络开销之和，得到该候选策略对应的所述总网络开销；
或者，基于所述预计网络开销与所述预计访问量，确定该候选策略中每个所述服务器对应的单个服务器网络开销；并获取所述单个服务器网络开销之和，得到该候选策略对应的所述总网络开销。
5.根据权利要求1所述的方法，其特征在于，所述遍历所述服务器集群中的各服务器部署应用程序的可实施策略，得到多个所述候选策略，包括：
遍历在各服务器中部署应用程序的部署策略；
确定所述部署策略中，各个候选服务器的可用资源量，以及各个所述候选服务器预计部署的应用程序的总资源占用量；
在所述可用资源量大于或等于所述总资源占用量时，将所述部署策略作为所述候选策略。
6.根据权利要求5所述的方法，其特征在于，所述候选服务器中资源的类型包括以下至少一项：CPU资源、运行内存资源或存储资源。
7.根据权利要求1-6任一项所述的方法，其特征在于，所述遍历所述服务器集群中的各服务器部署应用程序的可实施策略，得到多个所述候选策略，包括：
在第二应用程序的部署方式不变的前提下，遍历所述服务器集群中的各服务器部署第一应用程序的可实施策略，得到多个所述候选策略；其中，所述第二应用程序为除所述第一应用程序之外的其他应用程序。
8.根据权利要求1-6任一项所述的方法，其特征在于，所述确定各候选策略的总网络开销之前，所述方法还包括：
获取所述应用程序在预设时段内访问量的变化率；
在所述变化率达到预设变化率阈值时，执行所述确定各候选策略的总网络开销的步骤。
9.根据权利要求1-6任一项所述的方法，其特征在于，所述根据目标策略，调度所述应用程序的镜像文件，包括：
根据所述目标策略，确定用于部署所述应用程序的目标服务器；
向所述目标服务器发送部署指令，所述部署指令用于指示所述目标服务器部署所述应用程序的镜像文件；
向当前部署有所述应用程序的边缘服务器发送解除部署指令，所述解除部署指令用于指示所述边缘服务器解除部署所述应用程序的镜像文件。
10.根据权利要求9所述的方法，其特征在于，所述调度所述应用程序的镜像文件，包括：
向所述目标服务器发送所述应用程序的镜像文件，以使得所述目标服务器运行所述镜像文件以安装所述应用程序；
或者，向当前部署有所述应用程序的边缘服务器发送部署转移指令，所述部署转移指令用于指示所述边缘服务器向所述目标服务器发送所述应用程序的镜像文件，以使得所述目标服务器运行所述镜像文件以安装所述应用程序。
11.一种应用管理装置，其特征在于，包括：
第一确定模块，用于获取服务器集群中各服务器对每个应用程序在预设时段内的访问量，所述访问量包括：直接访问量或间接访问量；
第二确定模块，用于基于所述访问量，确定各候选策略的总网络开销包括：遍历所述服务器集群中的各服务器部署各应用程序的可实施策略，得到多个所述候选策略；对于任意一种所述候选策略，根据各服务器针对各应用程序的直接访问量以及间接访问量，确定该候选策略中各服务器针对各应用程序的预计访问方式；基于所述预计访问方式，确定各服务器针对各应用程序的预计网络开销与预计访问量；基于所述预计网络开销，获取该候选策略对应的总网络开销；所述候选策略为所述服务器集群中的各服务器部署应用程序的可实施策略；
调度模块，用于根据目标策略，调度所述应用程序的镜像文件；其中，所述目标策略在各候选策略中的总网络开销最小。
12.一种电子设备，其特征在于，包括：处理器、通信接口、存储器和通信总线，其中，所述处理器、通信接口和存储器通过通信总线完成相互间的通信；
所述存储器，用于存放计算机程序；
所述处理器，用于执行所述计算机程序时，实现权利要求1-10任一项所述的方法。
13.一种存储介质，其特征在于，所述存储介质包括存储的程序，其中，所述程序运行时执行上述权利要求1-10中任一项所述的方法。
CN202011634870.6A 2020-12-31 2020-12-31 一种应用管理方法、装置、电子设备及存储介质 Active CN112732425B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011634870.6A CN112732425B (zh) 2020-12-31 2020-12-31 一种应用管理方法、装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011634870.6A CN112732425B (zh) 2020-12-31 2020-12-31 一种应用管理方法、装置、电子设备及存储介质

Publications (2)

Publication Number Publication Date
CN112732425A CN112732425A (zh) 2021-04-30
CN112732425B true CN112732425B (zh) 2023-09-01

Family

ID=75608578

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011634870.6A Active CN112732425B (zh) 2020-12-31 2020-12-31 一种应用管理方法、装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN112732425B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114726612B (zh) * 2022-04-01 2024-03-26 北京指掌易科技有限公司 一种工作域管理方法、装置、介质及电子设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107341029A (zh) * 2017-05-27 2017-11-10 北京奇艺世纪科技有限公司 系统资源部署策略的获取方法、装置及电子设备
WO2018106968A1 (en) * 2016-12-09 2018-06-14 Vmware, Inc. Methods and apparatus to automate deployments of software defined data centers
CN109302483A (zh) * 2018-10-17 2019-02-01 网宿科技股份有限公司 一种应用程序的管理方法及系统
CN110187973A (zh) * 2019-05-31 2019-08-30 浙江大学 一种面向边缘计算的服务部署优化方法
CN110609732A (zh) * 2019-08-13 2019-12-24 平安普惠企业管理有限公司 应用程序部署方法、装置、计算机设备和存储介质
CN110737442A (zh) * 2019-09-24 2020-01-31 厦门网宿有限公司 一种边缘应用管理方法及系统

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9692818B2 (en) * 2014-04-11 2017-06-27 Bank Of America Corporation Automated application deployment based on server utilization
US10705835B2 (en) * 2015-12-03 2020-07-07 International Business Machines Corporation Transparent multi-architecture support in a container based cloud
US20180205616A1 (en) * 2017-01-18 2018-07-19 International Business Machines Corporation Intelligent orchestration and flexible scale using containers for application deployment and elastic service
US11469954B2 (en) * 2019-05-16 2022-10-11 Verizon Patent And Licensing Inc. System and methods for service policy optimization for multi-access edge computing services

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018106968A1 (en) * 2016-12-09 2018-06-14 Vmware, Inc. Methods and apparatus to automate deployments of software defined data centers
CN107341029A (zh) * 2017-05-27 2017-11-10 北京奇艺世纪科技有限公司 系统资源部署策略的获取方法、装置及电子设备
CN109302483A (zh) * 2018-10-17 2019-02-01 网宿科技股份有限公司 一种应用程序的管理方法及系统
CN110187973A (zh) * 2019-05-31 2019-08-30 浙江大学 一种面向边缘计算的服务部署优化方法
CN110609732A (zh) * 2019-08-13 2019-12-24 平安普惠企业管理有限公司 应用程序部署方法、装置、计算机设备和存储介质
CN110737442A (zh) * 2019-09-24 2020-01-31 厦门网宿有限公司 一种边缘应用管理方法及系统

Also Published As

Publication number Publication date
CN112732425A (zh) 2021-04-30

Similar Documents

Publication Publication Date Title
US10594798B2 (en) Systems and methods for managing containers in a network of moving things
Yao et al. Fog resource provisioning in reliability-aware IoT networks
EP4020204A1 (en) Adaptive power management for edge device
WO2020168761A1 (zh) 训练模型的方法和装置
US10771533B2 (en) Adaptive communication control device
US20180316764A1 (en) Captive portal-related control and management in a network of moving things
EP3278578B1 (en) Method and system for mtc event management
CN116547958A (zh) 用于网络功能选择的排名处理的方法、系统和计算机可读介质
US11128734B2 (en) Configuring a communication system using analytics of a restful API in a network of moving things
CN111224806A (zh) 一种资源分配方法及服务器
CN110602180B (zh) 一种基于边缘计算的大数据用户行为分析方法及电子设备
CN113645262A (zh) 云计算服务系统和方法
CN112732425B (zh) 一种应用管理方法、装置、电子设备及存储介质
CN113228574A (zh) 计算资源调度方法、调度器、物联网系统和计算机可读介质
CN113132456A (zh) 一种基于截止时间感知的边云协同任务调度方法及系统
US20130007281A1 (en) Dynamically tuning server placement
Lovén et al. A dark and stormy night: Reallocation storms in edge computing
US20210167978A1 (en) Methods and systems for billing of metadata in a network of moving things
Bellavista et al. GAMESH: a grid architecture for scalable monitoring and enhanced dependable job scheduling
WO2021014267A1 (en) Cognitively controlling data delivery
CN115658287A (zh) 一种用于调度运行单元的方法、设备、介质及程序产品
CN115774614A (zh) 资源调控方法、终端及存储介质
Zhao et al. Optimizing allocation and scheduling of connected vehicle service requests in cloud/edge computing
CN114125904A (zh) 基于5g电力的业务承载分配方法及系统
CN113630422B (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