CN113726846A - 边缘云系统、资源调度方法、设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种边缘云系统、资源调度方法、设备及存储介质。在本申请实施例中，针对边缘云系统中的边缘节点进行资源调度时，综合考虑边缘节点的资源使用信息以及其所服务用户区域的网络服务质量，不仅将边缘节点之间的网络异构特性考虑进来，而且还可以从网络和资源两个维度对边缘节点进行资源调度，有利于提升边缘资源的服务质量和边缘资源的利用率，使得应用能够真正下沉到靠近用户的边缘侧，最大化地提升服务质量。进一步，还可以从应用角度出发，基于用户访问日志获取应用的资源消耗，完善资源的扩缩容方案，实现更加精细化的调度，减少由于边缘节点资源规模小导致的碎片化资源较多的问题，降低资源浪费，提升资源利用率。

Description

边缘云系统、资源调度方法、设备及存储介质

技术领域

本申请涉及云计算技术领域，尤其涉及一种边缘云系统、资源调度方法、设备及存储介质。

背景技术

目前，视频处理、图像处理以及游戏处理等计算服务，对计算资源和存储资源具有较大的需求，于是出现了计算上云的概念。即将这些计算服务部署在云数据中心，由云数据中心为这些计算服务提供所需的计算资源和存储资源，并将得到的结果数据提供给终端用户。云数据中心将结果数据提供给终端用户时，需要消耗大量的带宽资源，并且网络的不稳定性可能导致传输延迟，无法满足低时延、节省带宽的需求。

边缘计算是一种将云计算服务从传统的云数据中心下沉到更加靠近用户侧的边缘节点上，从而实现更低的传输时延，节省网络流量的技术方案。但是，边缘节点之间的资源具有异构性，和云数据中心有很大的差异，以中心为理念的资源调度策略无法适应边缘计算场景，因此亟需一种新的结合边缘特性的资源调度方案，提升边缘异构资源的服务质量。

发明内容

本申请的多个方面提供一种边缘云系统、资源调度方法、设备及存储介质，用以对边缘节点进行资源调度，提升边缘异构资源的服务质量。

本申请实施例提供一种边缘云系统，包括：管控节点、数据处理节点以及多个边缘节点；数据处理节点，用于采集多个边缘节点的资源使用信息，并探测多个边缘节点对其所服务用户区域的网络服务质量；将多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量上报给管控节点；管控节点，用于在需要对多个边缘节点进行资源调度的情况下，根据多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，对多个边缘节点进行资源调度。

本申请实施例还提供一种资源调度方法，适用于边缘云系统，包括：采集边缘云系统中多个边缘节点的资源使用信息，并探测多个边缘节点对其所服务用户区域的网络服务质量；在需要对多个边缘节点进行资源调度的情况下，根据多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，对多个边缘节点进行资源调度。

本申请实施例还提供一种管控节点，应用于边缘云系统，包括：存储器和处理器；存储器用于存储计算机程序，处理器与存储器耦合，用于执行计算机程序，以用于：接收边缘云系统中数据处理节点发送的边缘云系统中多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量；在需要对多个边缘节点进行资源调度的情况下，根据多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，对多个边缘节点进行资源调度。

本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，当计算机程序被处理器执行时，致使处理器可以实现本申请实施例提供的资源调度方法中的各步骤。

本申请实施例还提供一种计算机程序/指令，当计算机程序/指令被处理器执行时，致使处理器可以实现本申请实施例提供的资源调度方法中的各步骤。

在本申请实施例中，针对边缘云系统中的边缘节点进行资源调度时，综合考虑边缘节点的资源使用信息以及其所服务用户区域的网络服务质量，不仅将边缘节点之间的网络异构特性考虑进来，而且还可以从网络和资源两个维度对边缘节点进行资源调度，有利于提升边缘资源的服务质量和边缘资源的利用率，使得应用能够真正下沉到靠近用户的边缘侧，最大化地提升服务质量。

进一步，还可以从应用角度出发，基于用户访问日志获取应用的资源消耗，完善资源的扩缩容方案，实现更加精细化的调度，减少由于边缘节点资源规模小导致的碎片化资源较多的问题，降低资源浪费，提升资源利用率。

附图说明

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

图1为本申请示例性实施例提供的一种边缘云系统的结构示意图；

图2为本申请示例性实施例提供的另一种边缘云系统的结构示意图；

图3为本申请示例性实施例提供的又一种边缘云系统的结构示意图；

图4为本申请示例性实施例提供的一种资源调度方法的流程示意图；

图5为本申请示例性实施例提供的一种管控节点的结构示意图。

具体实施方式

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

针对以中心为理念的资源调度策略无法适应边缘计算场景的问题，在本申请实施例中，针对边缘云系统中的边缘节点进行资源调度时，综合考虑边缘节点的资源使用信息以及其所服务用户区域的网络服务质量，不仅将边缘节点之间的网络异构特性考虑进来，而且还可以从网络和资源两个维度对边缘节点进行资源调度，有利于提升边缘资源的服务质量和边缘资源的利用率，使得应用能够真正下沉到靠近用户的边缘侧，最大化地提升服务质量。进一步，还可以从应用角度出发，基于用户访问日志获取应用的资源消耗，完善资源的扩缩容方案，实现更加精细化的调度，减少由于边缘节点资源规模小导致的碎片化资源较多的问题，降低资源浪费，提升资源利用率。

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

图1为本申请示例性实施例提供的一种边缘云系统的结构示意图。如图1所示，该边缘云系统100包括：管控节点10、数据处理节点20以及多个边缘节点30。

本实施例的边缘云系统100是基于云计算技术和边缘计算的能力，构筑在边缘基础设施之上的云计算平台，是一种靠近边缘位置的具备计算、网络、存储以及安全等能力的网络系统。边缘云是个相对概念，边缘云是指相对靠近终端的云计算平台，这里的终端是指云计算服务的需求端，例如可以是互联网中的终端或者用户端，或者物联网中的终端或用户端。或者说，本实施例的边缘云系统100与中心云或者传统的云计算平台相区别，中心云或者传统的云计算平台可以包括资源规模化且位置集中的数据中心，而本实施例的边缘云系统100包括边缘节点30，这些边缘节点30分散在不同区域位置，覆盖的网络范围更广泛，也因此具备距离终端更近的特性，单个边缘节点30的资源规模较小，但是边缘节点30的数量相对较多。另外，本实施例的边缘节点30可以全部由同一互联网服务提供商(InternetService Provider，ISP)部署，也可以由不同ISP部署实现，对此不做限定。

在本实施例中，每个边缘节点30包括一系列的边缘基础设施，这些边缘基础设施包括但不限于：分布式数据中心(DC)、无线机房或集群，运营商的通信网络、核心网设备、基站、边缘网关、家庭网关、计算设备和/或存储设备等边缘设备及对应的网络环境等等。在一些可选实施例中，边缘节点30可实现为位于边缘的互联网数据中心(Internet DataCenter，IDC)，即一个边缘IDC即为本申请实施例中的一个边缘节点30；或者，边缘节点30可实现为位于边缘的机房，即一个机房即为本申请实施例中的一个边缘节点30。在此说明，不同边缘节点30的位置、能力以及包含的基础设施可以相同，也可以不相同。基于这些边缘基础设施，边缘节点30可以对外提供各种资源，例如CPU、GPU、服务器、计算设备等具有一定计算能力的资源，内存、硬盘等具有存储能力的资源，以及带宽等网络资源等。可选地，边缘节点30中包括多台物理机301，如图3所示，每台物理机上可以有计算资源、存储资源或者网络资源。

本实施例的边缘云系统100可应用于内容分发网络(Content Delivery Network，CDN)、电商、游戏、音视频、物联网、物流、工业大脑、城市大脑等各种应用场景中，面向各种场景中的终端用户提供云计算服务。具体地，针对各应用场景，可以在边缘云系统100中的边缘节点30中部署该应用场景中可提供云计算服务的应用(后续简称为应用)。例如，在电商场景中，可以在边缘节点30上部署可提供在线购物功能的应用，例如可以是在线购物应用的服务端，该服务端与购物终端进行交互可为购物用户提供在线购物功能；在游戏场景中，可以在边缘节点30上部署可提供在线游戏功能的应用，例如可以是在线游戏应用的服务端，该服务端与游戏终端进行交互可为游戏用户提供在线游戏服务；在音视频领域中，可以在边缘节点30上部署可提供音视频功能的应用，例如可以是直播服务端、点播服务端或视频监测服务端等，这些服务端与播放终端进行交互可为观看用户提供直播、点播或监测等服务。

在本实施例中，为了适应边缘场景的资源特性，保证应用的服务质量，需要对多个边缘节点30进行资源调度。其中，对边缘节点30进行资源调度包括以下至少一种：在边缘节点30上进行应用的创建、弹性伸缩、滚动更新、重建、迁移或关停等操作。

其中，应用的创建是指根据边缘服务需求方提交的应用部署请求，在边缘节点30上创建符合要求的应用的过程，这会涉及边缘节点30的选择问题，属于资源调度的一种情况。应用的滚动更新是指在镜像版本有更新时，为了保证服务的可用性，逐渐分批次对应用进行更新，最终实现全部应用的更新的过程，这会涉及边缘节点30之间更新顺序的问题，属于资源调度的一种情况。应用的重建是指在应用出现异常时，重新创建新的应用并删除原有应用的过程，这会涉及在哪个或哪些边缘节点30上新建应用的问题，属于资源调度的一种情况。应用出现异常包括应用自身异常，也包括因应用所在边缘节点30故障而引起的异常。应用的关停是指关闭应用的过程，在应用部署在多个边缘节点30上的情况下，这会涉及边缘节点30之间关停顺序的问题，或者选择关停哪个边缘节点30上的应用的问题，这属于资源调度的一种情况。应用的迁移是指因需求将运行于一个边缘节点30上的应用迁移到另一个边缘节点30上的过程，这涉及应用在另一边缘节点30上的重建和原有应用的删除操作，这会涉及在哪个或哪些边缘节点30上重建应用的问题，属于资源调度的一种情况。

其中，应用的弹性伸缩包括横向弹性伸缩或者纵向弹性伸缩，其中，横向弹性伸缩是指根据应用部署需求和策略，在应用需求增长时增加应用的数量(简称为横向扩容)，以保证云计算能力，在应用需求下降时减少应用的数量(简称为横向缩容)，以节约成本；相应地，纵向弹性伸缩是指根据应用的资源使用情况，在资源使用率较高的情况下为应用进行资源扩容(简称为纵向扩容)，在资源使用率较低的情况下为应用进行资源缩容(简称为纵向缩容)。可选地，可以通过设定使用率上限值和使用率下限值来判断应用的资源使用率是否较高或较低；若应用的资源使用率高于设定的使用率上限值，则认为应用的资源使用率较高；若应用的资源使用率低于设定的使用率下限值，则认为应用的资源使用率较低。对于应用的横向扩容具体是创建新的应用的过程，对于应用的横向缩容具体是删除已有应用的过程；对于应用的纵向扩容或纵向缩容涉及新应用的重建和原有应用的删除这两个操作。上述应用的弹性伸缩也会涉及边缘节点30的选择问题，属于资源调度的一种情况。

在本实施例中，由管控节点10和数据处理节点20相互配合，对多个边缘节点30进行资源调度。其中，管控节点10和数据处理节点20在逻辑上属于独立节点。在部署实施上，管控节点10可以部署在一个或多个云计算数据中心中，或者，可以部署在一个或多个传统数据中心中；当然，管控节点10也可以部署在边缘云系统100中，例如管控节点10可独立于多个边缘节点30单独部署，或者也可以部署在一个、两个或两个以上的边缘节点30中，本实施例对此不做限定。无论是部署在云计算数据中心、传统数据中心或边缘云系统100中，管控节点10可以部署某个或者几台物理机、虚拟机或容器中实现，例如可以单独部署在云数据中心的一台物理机或虚拟机上，或者单独部署在边缘节点30中的一台物理机或虚拟机上。同理，数据处理节点20可以部署在一个或多个云计算数据中心中，或者，可以部署在一个或多个传统数据中心中；当然，数据处理节点20也可以部署在边缘云系统100中，例如数据处理节点20可独立于多个边缘节点30单独部署，或者也可以部署在一个、两个或两个以上的边缘节点30中，本实施例对此不做限定。无论是部署在云计算数据中心、传统数据中心或边缘云系统100中，数据处理节点20可以部署某个或者几台物理机、虚拟机或容器中实现，例如可以单独部署在云数据中心的一台物理机或虚拟机上，或者单独部署在边缘节点30中的一台物理机或虚拟机上，或者，数据处理节点20的一部分功能部署在云数据中心实现，另一部分功能部署在边缘云系统100的边缘节点30中实现。需要说明的是，管控节点10和数据处理节点20可以部署在同一物理机或虚拟机上，也可以部署在不同物理机或虚拟机上。在图1中以管控节点10和数据处理节点20分别部署在不同物理机上为例进行图示，但并不限于此。

在本实施例中，在对边缘节点30进行资源调度时，一方面会考虑边缘节点30的资源使用情况，另一方面考虑到边缘节点30之间较明显的差异性，即网络差异：不同边缘节点的网络覆盖效果、中心的通信链路、网络安全、出口带宽等会有较大差异，因此同时将边缘节点30的网络特殊性纳入对边缘节点30的资源调度中，以便于对边缘节点30进行更加合理的调度。

基于上述，本实施例的数据处理节点20一方面负责采集多个边缘节点30的资源使用信息。其中，每个边缘节点30的资源使用信息至少包括：该边缘节点30中硬件资源的使用信息；进一步可选地，还可以包括该边缘节点中软件资源的使用信息。其中，软件资源主要指边缘节点30上承载的各种数据或程序，硬件资源主要指边缘节点30中的计算资源、存储资源或网络资源等。计算资源包括但不限于：边缘节点30中的CPU、GPU等；存储资源包括但不限于：边缘节点30中的内存、磁盘等；网络资源可以是边缘节点30上网卡的带宽资源等。其中，硬件资源的使用信息可以用资源使用率来体现，例如，CPU使用率、内存使用率以及硬盘使用率等。在采集到每个边缘节点30的资源使用信息之后，数据处理节点20还会将每个边缘节点30的资源使用信息上报给管控节点10。

另一方面，本实施例的数据采集节点20还负责探测多个边缘节点对其所服务用户区域的网络服务质量。其中，用户区域是根据用户属性信息划分的，用户属性信息包括：用户位置属性或用户等级信息等。其中，用户位置属性可以通过用户的网际协议(InternetProtocol，IP)地址来表征，也即用户区域可以根据用户的IP地址划分的，例如可以将IP地址段是A0-A2的用户划分到同一用户区域B1中，将IP地址段是A2-A3的用户划分到另一用户区域B2中。其中，IP地址段可以是根据地理位区域划定，例如为不同地理区域划分不同IP地址段，则该地理区域内的用户都使用该IP地址段内的IP地址；或者，也可以根据应用需求自行划定，对此不做限定。当然，除了根据IP地址段划分用户区域之外，也可以根据具体的IP地址，例如将IP地址是C1、C2……D1……Dn的用户划分到同一用户区域中。本申请实施例中被划分出的用户区域可以有多个，每个用户区域包括边缘云系统100的一个或多个用户，这里的用户是指使用或访问边缘云系统100中部署的一种或多种应用的用户，这些用户在地理位置上具有一定流动性，但IP地址相对固定。在本实施例中，边缘节点30可以为进入其覆盖范围内的用户提供服务，这些用户可能隶属于一个或多个用户区域，也就是说，边缘节点30可以为用户区域内的用户提供服务，且其所服务的用户区域可能是一个或多个。在本实施例中，以用户区域为粒度，探测各边缘节点30对其所服务用户区域的网络服务质量，并通过边缘节点30对其所服务用户区域的网络服务质量表征边缘节点30的网络特性。在本实施例中，并不限定探测边缘节点30对其所服务用户区域的网络服务质量的探测方式，一些示例性探测方式可参见后续实施例，在此暂不赘述。在探测到每个边缘节点30对其所服务用户区域的网络服务质量之后，数据处理节点20还会将每个边缘节点30对其所服务用户区域的网络服务质量上报给管控节点10。

在本实施例中，管控节点10可接收数据处理节点20上报的多个边缘节点30的资源使用信息和对其所服务用户区域的网络服务质量。进而，在需要对多个边缘节点30进行资源调度的情况下，管控节点10根据数据处理节点20上报的多个边缘节点30的资源使用信息和其所服务用户区域的网络服务质量，对多个边缘节点30进行资源调度。在本实施例中，并不限定需要对多个边缘节点30进行资源调度的情况，根据情况不同，对结合多个边缘节点30的资源使用信息和其所服务用户区域的网络服务质量，对多个边缘节点30进行资源调度的过程也会有所差异，在后续实施例中将举例说明。在整个资源调度过程中，综合考虑边缘节点的资源使用信息以及其所服务用户区域的网络服务质量，不仅将边缘节点之间的网络异构特性考虑进来，而且还可以从网络和资源两个维度对边缘节点进行资源调度，可提升边缘资源的服务质量和边缘资源的利用率，使得应用能够真正下沉到靠近用户的边缘侧，最大化地提升服务质量。

在本实施例中，并不对数据处理节点20的内部实现结构进行限定。如图2所示，一种数据处理节点20的内部实现结构包括：日志采集模块201、指标采集模块202、探测模块203以及分析处理模块204。其中，指标采集模块202用于采集各边缘节点30的资源使用信息，尤其是硬件资源使用信息，例如CPU使用率、内存使用率、硬盘使用率等；日志采集模块201用于采集各边缘节点30中的用户访问日志；探测模块203用于基于日志采集模块201采集到的各边缘节点30的用户访问日志中的用户属性信息(如IP地址信息)确定各边缘节点所服务的用户区域，并探测各边缘节点30与其所服务用户区域中选定用户之间的网络参数，其中，网络参数可以包括以下至少一种：丢包率、吞吐量、网络抖动以及时延等；分析处理模块204用于对日志采集模块201、指标采集模块202以及探测模块203采集到的数据进行综合分析，得到多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，并将得到的资源使用信息和网络服务质量提供给管控节点10，以供管控节点10据此在需要的情况下对多个边缘节点30进行资源调度。

可选地，为了更好地采集边缘节点30中的各种数据，可以将日志采集模块201和指标采集模块202部署到边缘节点30中，例如日志采集模块201和指标采集模块202可以是部署在边缘节点30中的程序、插件或应用中的埋点等。相应地，探测模块203可以包括部分部署在边缘节点30中的采集子模块和部署在云数据中心、传统数据中心或独立于各边缘节点30部署在边缘云系统100中的选定子模块；选定子模块负责基于用户访问日志中的用户属性信息(如IP地址信息)确定各边缘节点所服务的用户区域，并从各边缘节点所服务用户区域中选定探测所需的部分用户，记为选定用户；采集子模块负责根据选定子模块下发的通知，采集其所在边缘节点与该边缘节点中选定用户之间的网络参数。相应地，可以将分析处理模块204部署在云数据中心、传统数据中心或独立于各边缘节点30部署在边缘云系统100中。在图2中，以日志采集模块201、指标采集模块202以及探测模块203部署在每个边缘节点30上，分析处理模块204和管控节点10部署在云数据中心上为例进行图示，但并不限于此，在图2中数据处理节点20的各模块用虚线表示。

在本实施例中，日志采集模块201采集到的用户访问日志中可以包括但不限于以下信息：用户的IP地址信息、区域信息、用户的访问时间、用户访问的应用、用户的访问类型等。探测模块203可基于用户访问日志中的IP地址信息确定各边缘节点30所服务的用户区域。例如，可以获取用户访问日志中的IP地址信息，根据获取到的IP地址信息，确定边缘节点30所服务的IP地址段，将该IP地址段对应的用户区域作为边缘节点30所服务的用户区域。探测模块203在确定边缘节点30所服务的用户区域之后，可探测各边缘节点30与其所服务用户区域中选定用户之间的网络参数。其中，选定用户可以是边缘节点30所服务用户区域中访问状态较为稳定的部分用户。例如，可以根据边缘节点30的用户访问日志，获取一段时间内各用户的访问时间、访问频次、访问产生的流量等信息，基于这些信息判断哪些用户的访问状态较为稳定，例如可以将访问时间较长、访问频次较高以及访问流量较大的用户作为访问状态较为稳定的用户并将这些用户作为选定用户，这些选定用户具有一定代表性，可以代表整个用户区域的网络访问质量。接着，可根据边缘节点30与其所服务用户区域中选定用户之间的网络参数，确定各边缘节点30对其所服务用户区域的网络服务质量。例如，对于边缘节点30所服务的用户区域X，可以对用户区域X中的选定用户的网络参数进行各种数值计算，例如加权求和，得到该边缘节点30对用户区域X的网络服务质量。

在本实施例中，管控节点10在需要对多个边缘节点30进行资源调度的情况下，可结合多个边缘节点30的资源使用信息和对其所服务用户区域的网络服务质量，对多个边缘节点进行资源调度。在本实施例中，并不限定需要对多个边缘节点30进行资源调度的情况，下面举例说明：

在一可选实施例A1中，管控节点10支持与应用部署方的交互，应用部署方可以是个人或企业。例如，管控节点10可以面向应用部署方提供交互接口，在实现上该交互接口可以是web页面或命令窗口，应用部署方可以通过该交互接口向管控节点10提交应用部署请求，该应用部署请求会触发管控节点10对边缘节点进行资源调度的过程。在一可选实施例中，该应用部署请求用于请求管控节点10在合适的边缘节点30上部署目标应用。目标应用可以是视频应用、邮箱应用等。管控节点10可接收应用部署方发送的应用部署请求，根据应用部署请求，确定需要部署目标应用的目标地理区域，其中，多个边缘节点30分布在不同的地理区域，目标地理区域中也分布有边缘节点30，管控节点10可根据目标地理区域内边缘节点30的资源使用信息和对其所服务用户区域的网络服务质量，从目标地理区域中选择至少一个目标边缘节点，在至少一个目标边缘节点中部署目标应用，从而完成对边缘节点的资源调度过程。

其中，并不限定管控节点10根据应用部署请求，确定需要部署目标应用的目标地理区域的实施方式。根据应用部署请求中携带信息的不同，管控节点10确定需要部署目标应用的目标地理区域的实施方式也有所不同。下面举例说明。

在一可选实施例中，应用部署请求中携带有目标地理区域的标识信息，即应用部署方直接指定要求部署目标应用的地理区域，则管控节点10可直接根据目标地理区域的标识信息，确定需要部署目标应用的目标地理区域。

在另一可选实施例中，可以将应用部署方进行优先级划分，并且管控节点10预先维护有多个不同优先级的资源调度模板，每个资源调度模板至少包括需要部署应用的地理区域的标识信息。当然，资源调度模板中还可以包括其它一些与资源调度相关的信息。其中，优先级较高的资源调度模板中包含的地理区域的粒度分布相对较细，优先级较低的资源调度模板中包含的地理区域的粒度分布相对较粗。也就是说，如果使用优先级较高的资源调度模板，可以细粒度的选择需要部署应用的地理区域，如果使用优先级较低的资源调度模板，可以粗粒度的选择需要部署应用的地理区域。其中，不同优先级的应用部署方可以使用与其优先级适配的资源调度模板。鉴于此，若应用部署请求中携带有应用部署方的标识信息，则管控节点10可根据应用部署请求中包含的应用部署方的标识信息，确定应用部署方的优先级；从多个资源调度模板中，选择与应用部署方的优先级适配的目标资源调度模板，该目标资源调度模板中至少包括目标地理区域的标识信息，管控节点10可根据目标资源调度模板中目标地理区域的标识信息，确定需要部署目标应用的目标地理区域。

无论通过上述哪种方式确定需要部署目标应用的目标地理区域，在确定需要部署目标应用的目标地理区域之后，管控节点10可以根据目标地理区域内边缘节点30的资源使用信息和对其所服务用户区域的网络服务质量，选择至少一个目标边缘节点。考虑到边缘节点30的整体规模比较小，主要体现在计算资源或存储资源比较小，同时，边缘节点30的网络状况较为复杂。鉴于此，在一可选实施例中，可根据目标地理区域内边缘节点30的资源使用信息，优先从中选择可用资源信息满足资源需求的候选边缘节点，可保证目标应用在边缘节点上的正常运行；然后，根据候选边缘节点对其所服务用户区域的网络服质量，从候选边缘节点中选择网络服务质量满足设定网络要求的至少一个目标边缘节点。其中，基于边缘节点对其所服务用户区域的网络服务质量进行资源调度，可真正地将应用下沉到边缘侧，提升服务质量。进一步可选地，应用部署方提交的应用部署请求中可携带有部署目标应用所需的资源要求，管控节点10可从应用部署请求中确定部署目标应用所需的资源需求，例如需要5个CPU，20G内存等。或者，管控节点10也可以根据目标应用的类型，确定部署目标应用所需的资源需求。之后，可根据目标地理区域内边缘节点30的资源使用信息，确定边缘节点30上剩余的可用资源量，判断该可用资源量是否满足部署目标应用的资源需求，若满足则将该边缘节点30作为候选边缘节点。可选地，网络要求可以是网络服务质量超过设定的网络质量阈值，则可以将候选边缘节点中网络服务质量超过网络质量阈值的边缘节点直接作为目标边缘节点。或者，也可以根据候选边缘节点的网络服务质量，从中选择较优的一个或多个边缘节点作为目标边缘节点。其中，目标边缘节点的数量可根据应用部署需求而定，例如可以选择4个目标边缘节点，并在每个目标边缘节点上部署目标应用。

除上述可选实施例之外，也可以优先考虑网络质量，根据目标地理区域内边缘节点30对其所服务用户区域的网络服质量，优先从中选择网络服务质量满足设定网络要求的候选边缘节点；再考虑资源情况，根据候选边缘节点的资源使用信息，从候选边缘节点中选择可用资源信息满足资源需求的至少一个目标边缘节点。或者，也可以根据目标地理区域内边缘节点30的资源使用信息和对其所服务用户区域的网络服质量，计算出目标地理区域内各边缘节点30的整体质量分，从中选择整体质量分大于设定分值阈值或分值最高的至少一个目标边缘节点。

在一可选实施例A2中，在部署目标应用的情况下，应用部署方还可以根据用户流量请求针对目标应用进行资源扩/缩容，于是可以通过管控节点10提供的人机交互接口，向管控能节点10发送资源扩/缩容请求，该资源扩/缩容请求会触发管控节点10对边缘节点进行资源调度的过程。管控节点10接收资源扩/缩容请求，资源扩/缩容请求中包括：目标用户区域预计对目标应用的访问量，若该访问量低于设定的访问下限值，表示需要对目标应用进行缩容，若该访问量高于设定的访问上限值，表示需要对目标应用进行扩容。其中，目标用户区域是指该目标应用所服务的某个或某几个用户区域，目标用户区域被目标应用所在的某个或某几个边缘节点覆盖。例如，可能预计某个用户区域内的用户将会在短时间内大量访问目标应用，这需要针对目标应用进行资源扩容，即需要在新的边缘节点上部署目标应用；或者由于可替代应用的出现，预计某个用户区域内的用户将在短时间内大量退出目标应用的使用，这需要针对目标应用进行资源缩容，即需要将部分边缘节点上的目标应用删除，以节约资源和成本。基于此，管控节点10可根据资源扩/缩容请求，确定目标边缘节点上的目标用户区域预计对目标应用的访问量，其中，该访问量可根据历史时期目标边缘节点上的用户访问日志来预测；根据访问量，结合目标地理区域内可服务该目标用户区域的边缘节点的资源使用信息和对该目标用户区域的网络服务质量，针对目标用户区域进行资源扩/缩容。

具体地，可以根据目标用户区域对目标应用的访问量，确定需要扩/缩容的边缘节点的数量，然后再根据目标地理区域内可服务目标用户区域的边缘节点的资源使用信息和对目标用户区域的网络服务质量，结合需要扩/缩容的边缘节点的数量，确定针对目标用户区域进行资源调度。在需要扩容的情况下，根据目标地理区域内可服务目标用户区域的边缘节点的资源使用信息和对目标用户区域的网络服务质量，结合需要扩容的边缘节点的数量，选择至少一个资源和网络均较优的边缘节点，并在所选择的边缘节点中部署目标应用，以达到扩容目的。在需要缩容的情况下，根据目标地理区域内正在服务目标用户区域的边缘节点的资源使用信息和对目标用户区域的网络服务质量，结合需要缩容的边缘节点的数量，选择至少一个资源和网络均较差的边缘节点，并将所选择的边缘节点中的目标应用删除，以达到缩容目的。

在一可选实施例A3中，管控节点10除了可以根据应用部署方提交的扩/缩容请求对边缘节点进行资源调度之外，还可以从应用维度对各边缘节点的资源消耗信息进行监测，并根据监测到的各边缘节点30在应用维度上的资源消耗信息，自主判断是否需要针对应用启动资源扩/缩容方案。当然，还可以从用户区域、边缘节点等其它维度进行资源消耗信息的监测，例如，以用户区域为监测粒度，通过用户访问日志确定用户区域内的访问用户，进而通过每个访问用户的资源消耗情况获取整个用户区域的整体资源消耗情况，例如区域维度的CPU利用率、内存利用率、硬盘利用率等；或者以边缘节点为监测粒度，可以监测整个边缘节点的资源消耗情况，例如节点维度的CPU利用率、内存利用率、硬盘利用率等。

以上述目标应用为例，数据处理节点20还可以从应用维度采集针对目标应用的用户访问日志，基于目标应用的用户访问日志中的用户属性信息(如IP地址信息)，获取目标应用对应的用户区域及用户区域对应的资源消耗信息，并将目标应用对应的用户区域及其资源消耗信息上报给管控节点10。其中，目标应用对应的用户区域是使用或访问该目标应用的用户区域，这些用户区域的资源消耗信息是指边缘节点在为这些用户区域提供与目标应用对应的服务时消耗的资源信息，可简称为目标应用在这些用户区域内的资源消耗信息。管控节点10根据目标应用对应的用户区域的资源消耗信息，确定待扩/缩容的目标用户区域；根据目标地理区域内可服务目标用户区域的边缘节点的资源使用信息和对目标用户区域的网络服务质量，针对目标用户区域进行资源扩/缩容。在本实施例中，可以从应用和用户区域的维度出发，拟合应用在不同用户区域内的资源消耗，针对应用在不同用户区域内的资源消耗，对目标应用进行扩/缩容，实现更加精细化的调度，减少由于边缘资源规模较小导致的碎片化资源较多的问题，降低资源浪费，提升资源利用率。

例如，目标应用对应的用户区域为用户区域E1和用户区域E2，用户区域E1的资源消耗低于设定的资源下限值，用户区域E2的资源消耗超过设定的资源上限值，则确定需要对用户区域E1进行缩容，对用户区域E2进行扩容。针对用户区域E1，确定目标地理区域内正在服务用户区域E1的边缘节点，选择资源利用率较高，且对用户区域E1的网络服务质量较差的边缘节点F1，将边缘节点F1上的目标应用删除，以达到缩容目的。针对用户区域E2，确定目标地理区域内可服务用户区域E2的边缘节点，选择资源利用率较低，且对用户区域E2的网络服务质量较好的边缘节点F2，在边缘节点F2上创建目标应用，以达到扩容目的。

在一可选实施例A4中，应用部署方配置了自动迁移服务，管控节点10就可以监测各应用及应用所在边缘节点30的状态，如果边缘节点30发生故障，管控节点10可查询边缘节点30上部署的应用，自动对部署在故障边缘节点30上的应用进行迁移。下面以发生故障边缘节点上的目标应用的迁移为例进行说明。数据处理节点20基于目标应用的用户访问日志中的IP地址信息，获取目标应用对应的用户区域及其资源消耗信息，并将目标应用对应的用户区域的资源消耗信息上报给管控节点10。在发现部署有目标应用的某个边缘节点30故障后，管控节点10首先确定目标应用对应的用户区域中由发生故障的边缘节点30服务的用户区域作为待迁移用户区域；接着，根据目标地理区域内可服务目标用户区域的边缘节点30的资源使用情况和对目标用户区域的网络服务质量，结合待迁移用户区域的资源消耗信息，确定可为待迁移用户区域提供服务且可用资源满足待迁移用户区域的资源需求的目标边缘节点30，将发生故障的边缘节点30上的目标应用迁移至目标边缘节点上。

在一可选实施例中A5中，由于可替代应用的出现或者出去其它原因，预计某个用户区域内的用户将在短时间内大量退出目标应用的使用，在目标应用被部署在多个边缘节点上的情况下，这就需要关停一部分边缘节点上的目标应用，以节约资源。这涉及将哪个或哪些边缘节点上的目标应用被关停的问题。管控节点10可以根据目标地理区域内部署有目标应用的各边缘节点30的资源使用情况和对目标应用对应的用户区域的网络服务质量，选择资源消耗较大且网络服务质量较差的边缘节点30作为可关停目标应用的目标边缘节点，将目标边缘节点上的目标应用关停。

在一可选实施例中A6中，目标应用部署在多个边缘节点30上，为了保证目标应用的可用性，需要逐渐分批次对多个边缘节点30上的目标应用进行更新，最终实现全部目标应用的更新，这会涉及多个边缘节点30之间更新顺序的问题。基于此，管控节点10可根据多个边缘节点30的资源使用信息和对其所服务用户区域的网络服务质量，确定对目标应用进行更新的顺序。例如，先对资源利用率高的边缘节点进行目标应用的更新，或者先对网络服务质量较高的边缘节点进行目标应用的更新，或者综合考虑多个边缘节点30的资源使用情况和对其所服务用户区域的网络服务质量，确定对多个边缘节点30上的目标应用进行更新的顺序。

在本实施例中，管控节点10和数据处理节点20可相互配合实现对多个边缘节点的资源调度，提升边缘资源的服务质量和边缘资源的利用率，减少了边缘资源的碎片化，降低资源浪费，提升资源利用率。但是，并不限制管控节点10的具体实现，凡是可以实现上述实施例中描述的功能逻辑的方式均适用于本申请实施例。例如，在一可选实施例中，管控节点10可基于Kubernetes(K8s)技术进行实现，即在管控节点10可实现为基于K8s的主节点(master)，从而实现为一种如图3所示的边缘云系统的架构，其中，各边缘节点30中可部署K8s的节点(node)。如图3所示，以K8s技术实现的管控节点10包括：管控模块(Kube-Manager)101、交互模块(Kube-API)102、存储模块(Etcd)103以及调度模块(Kube-Scheduler)104。

其中，管控模块101主要用于维护边缘云系统100的状态，例如，故障检测、自动扩展、滚动更新等。交互模块102是一种管控节点对外暴露的API接口，是外界与管控节点10进行交互的接口，边缘服务需求方可通过交互模块102向管控节点10提交边缘服务需求信息。除此之外，交互模块102还可以提供认证、授权、访问控制、API注册以及发现等功能。存储模块103主要用户存储边缘云系统中各节点的状态信息。调度模块104用于资源的调度，在本实施例中，调度模块104是一种增加版的调度器，在原本单纯考虑CPU和内存资源对边缘节点进行调度的基础上，增加了对边缘节点之间异构特性的考虑，即可以根据多个边缘节点的资源使用信息和其所服务用户区域的网络服务质量，对多个边缘节点进行资源调度。

另外，边缘节点30可实现为IDC，每个IDC中包含多个物理机301，物理机301上可实现K8s集群中的节点(Node)，这些Node上可以部署容器组件(pod)，pod是对容器实例进行组织和管理时可被调度的最小原子单位，一个应用可以对应一个pod，也可以对应多个pod。调度模块104可以对部署在边缘节点中的pod进行创建、删除、查询以及更新等操作，在这些操作中会涉及对边缘节点的资源调度。另外，如图3所示，边缘节点30对应的用户可以通过终端设备302访问其上部署的pod，其中，终端设备302可以是智能手机、笔记本电脑、台式电脑或摄像头等。除此之外，每个Node上还设有代理(agent)，用于跟主节点(master)进行通信。例如，可以通过主节点上的交互模块(Kube-API)102进行通信。

在本实施例中，关于数据处理节点20内部实现结构可参见图2所示的实施例，在图3中以日志采集模块201、指标采集模块202以及探测模块203与分析处理模块204部署在边缘云系统中独立于边缘节点30的物理机上为例进行图示，但并不限于此。

其中，指标采集模块202用于采集边缘节点维度和物理机维度的各项指标信息，并将采集到的指标信息提供给分析处理模块204。其中，指标信息可以是边缘节点与用户区域之间的网络服务质量，或者，边缘节点上物理机的CPU使用率、硬盘使用率以及内存使用率等。日志采集模块201用于采集各边缘节点30中的用户访问日志以及与用户相关的信息，例如用户的IP地址信息或区域信息等。日志采集模块201可以将采集到的用户访问日志提供给探测模块203，探测模块203基于用户访问日志中的IP地址信息确定各边缘节点所服务的用户区域，通过周期性的探测可以获取各个边缘节点30到用户之间的网络参数，并给到分析处理模块204。分析处理模块204对日志采集模块201、指标采集模块202以及探测模块203采集到的数据进行综合分析，得到以下三种数据，并将得到三种数据提供给管控节点10，以供管控节点10据此在需要的情况下对多个边缘节点30进行资源调度。分析处理模块204综合分析得到的两种数据为：

(1)资源使用信息：各边缘节点中物理机的硬件资源使用情况。

(2)资源消耗信息：通过全局性的分析，结合每个物理机的硬件资源使用情况以及使用该硬件资源期间内的访问请求，从应用的维度，拟合出不同应用的资源消耗情况(主要指硬件资源消耗)。

(3)网络质量分析：基于边缘节点到用户之间的网络参数，确定各边缘节点30对其所服务用户区域的网络服务质量。

管控节点10接收数据处理节点20的资源使用信息、资源消耗信息以及对其所服务用户区域的网络服务质量。根据多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，对多个边缘节点进行资源调度。例如，在边缘节点30上进行应用的创建、弹性伸缩、滚动更新、重建、迁移或关停等操作。详细内容可参见前述实施例，在此不再赘述。

图4为本申请示例性实施例提供的一种资源调度方法的流程示意图，该方法适用于边缘云系统，具体可由管控节点和数据处理节点配合实施，但不限于此。如图4所示，该方法包括：

401、采集边缘云系统中多个边缘节点的资源使用信息，并探测多个边缘节点对其所服务用户区域的网络服务质量；

402、在需要对多个边缘节点进行资源调度的情况下，根据多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，对多个边缘节点进行资源调度。

在一可选实施例中，用户区域是根据用户属性信息划分的；该方法还包括：采集各边缘节点中的用户访问日志；基于用户访问日志中的用户属性信息(如IP地址信息)确定各边缘节点所服务的用户区域，并探测各边缘节点与其所服务用户区域中选定用户之间的网络参数；根据网络参数确定各边缘节点对其所服务用户区域的网络服务质量。

在一可选实施例中，在需要对多个边缘节点进行资源调度的情况下，根据多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，对多个边缘节点进行资源调度，包括：在接收到应用部署请求的情况下，根据应用部署请求，确定需要部署目标应用的目标地理区域；根据目标地理区域内边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，选择至少一个目标边缘节点，在至少一个目标边缘节点中部署目标应用。

在一可选实施例中，根据目标地理区域内边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，选择至少一个目标边缘节点，包括：根据目标地理区域内边缘节点的资源使用信息，从中选择可用资源信息满足资源需求的候选边缘节点；根据候选边缘节点对其所服务用户区域的网络服质量，从中选择网络服务质量满足设定网络要求的至少一个目标边缘节点。

在一可选实施例中，根据应用部署请求，确定需要部署目标应用的目标地理区域，包括：根据应用部署请求中包含的应用部署方的标识信息，确定应用部署方的优先级；从多个资源调度模板中，选择与应用部署方的优先级适配的目标资源调度模板，目标资源调度模板中至少包括目标地理区域的标识信息。

在一可选实施例中，在需要对多个边缘节点进行资源调度的情况下，根据多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，对多个边缘节点进行资源调度，还包括：

基于目标应用的用户访问日志中的用户属性信息(如IP地址信息)，获取目标应用对应的用户区域的资源消耗信息；根据目标应用对应的用户区域的资源消耗信息，确定待扩/缩容的目标用户区域；根据目标地理区域内可服务目标用户区域的边缘节点的资源使用信息和对目标用户区域的网络服务质量，针对目标用户区域进行资源扩/缩容；

或者

在接收到资源扩/缩容请求的情况下，根据资源扩/缩容请求，确定目标用户区域预计对目标应用的访问量；根据访问量，结合目标地理区域内可服务目标用户区域的边缘节点的资源使用信息和对目标用户区域的网络服务质量，针对目标用户区域进行资源扩/缩容。

本申请实施例提供的资源调度方法，针对边缘云系统中的边缘节点进行资源调度时，综合考虑边缘节点的资源使用信息以及其所服务用户区域的网络服务质量，不仅将边缘节点之间的网络异构特性考虑进来，而且还可以从网络和资源两个维度对边缘节点进行资源调度，有利于提升边缘资源的服务质量和边缘资源的利用率，使得应用能够真正下沉到靠近用户的边缘侧，最大化地提升服务质量。

进一步，还可以从应用角度出发，基于用户访问日志获取应用的资源消耗，完善资源的扩缩容方案，实现更加精细化的调度，减少由于边缘节点资源规模小导致的碎片化资源较多的问题，降低资源浪费，提升资源利用率。

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

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如401、402等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

图5为本申请示例性实施例提供的一种管控节点的结构示意图，该管控节点应用于边缘云系统。如图5所示，该管控节点包括：存储器54和处理器55。

存储器54，用于存储计算机程序，并可被配置为存储其它各种数据以支持在管控节点上的操作。这些数据的示例包括用于在管控节点上操作的任何应用程序或方法的指令。

存储器54可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器55，与存储器54耦合，用于执行存储器54中的计算机程序，以用于：接收边缘云系统中数据处理节点发送的边缘云系统中多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量；在需要对多个边缘节点进行资源调度的情况下，根据多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，对多个边缘节点进行资源调度。

在一可选实施例中，用户区域是根据用户属性信息划分的，用户属性信息包括：用户位置属性或用户等级信息等。其中，用户位置属性可以通过用户的IP地址来表征，也即用户区域可以根据用户的IP地址划分的。

在一可选实施例中，处理器55在根据多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，对多个边缘节点进行资源调度时，具体用于：在接收到应用部署请求的情况下，根据应用部署请求，确定需要部署目标应用的目标地理区域；根据目标地理区域内边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，选择至少一个目标边缘节点，在至少一个目标边缘节点中部署目标应用。

在一可选实施例中，处理器55在根据目标地理区域内边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，选择至少一个目标边缘节点时，具体用于：根据目标地理区域内边缘节点的资源使用信息，从中选择可用资源信息满足资源需求的候选边缘节点；根据候选边缘节点对其所服务用户区域的网络服质量，从中选择网络服务质量满足设定网络要求的至少一个目标边缘节点。

在一可选实施例中，处理器55在接收到应用部署请求的情况下，根据应用部署请求，确定需要部署目标应用的目标地理区域时，具体用于：根据应用部署请求中包含的应用部署方的标识信息，确定应用部署方的优先级；从多个资源调度模板中，选择与应用部署方的优先级适配的目标资源调度模板，目标资源调度模板中至少包括目标地理区域的标识信息。

在一可选实施例中，处理器55还用于：接收目标应用对应的用户区域的资源消耗信息；根据目标应用对应的用户区域的资源消耗信息，确定待扩/缩容的目标用户区域；根据目标地理区域内可服务目标用户区域的边缘节点的资源使用信息和对目标用户区域的网络服务质量，针对目标用户区域进行资源扩/缩容。

在一可选实施例中，处理器55还用于：在接收到资源扩/缩容请求的情况下，根据资源扩/缩容请求，确定目标用户区域预计对目标应用的访问量；根据访问量，结合目标地理区域内可服务目标用户区域的边缘节点的资源使用信息和对目标用户区域的网络服务质量，针对目标用户区域进行资源扩/缩容。

本申请实施例提供的管控节点，针对边缘云系统中的边缘节点进行资源调度时，综合考虑边缘节点的资源使用信息以及其所服务用户区域的网络服务质量，不仅将边缘节点之间的网络异构特性考虑进来，而且还可以从网络和资源两个维度对边缘节点进行资源调度，有利于提升边缘资源的服务质量和边缘资源的利用率，使得应用能够真正下沉到靠近用户的边缘侧，最大化地提升服务质量。

进一步，还可以从应用角度出发，基于用户访问日志获取应用的资源消耗，完善资源的扩缩容方案，实现更加精细化的调度，减少由于边缘节点资源规模小导致的碎片化资源较多的问题，降低资源浪费，提升资源利用率。

进一步，如图5所示，该管控节点还包括：通信组件56、显示器57、电源组件58、音频组件59等其它组件。图5中仅示意性给出部分组件，并不意味着管控节点只包括图5所示组件。需要说明的是，图5中虚线框内的组件为可选组件，而非必选组件，具体可视管控节点的产品形态而定。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，当计算机程序被处理器执行时，致使处理器能够实现本申请实施例提供的资源调度方法中可由管控节点执行的各步骤。

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

上述图5中的显示器包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

上述图5中的电源组件，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

上述图5中的音频组件，可被配置为输出和/或输入音频信号。例如，音频组件包括一个麦克风(MIC)，当音频组件所在设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器或经由通信组件发送。在一些实施例中，音频组件还包括一个扬声器，用于输出音频信号。

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

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

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

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

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

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

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

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

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

Claims (12)

1.一种边缘云系统，其特征在于，包括：管控节点、数据处理节点以及多个边缘节点；

所述数据处理节点，用于采集所述多个边缘节点的资源使用信息，并探测所述多个边缘节点对其所服务用户区域的网络服务质量；将所述多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量上报给所述管控节点；

所述管控节点，用于在需要对所述多个边缘节点进行资源调度的情况下，根据所述多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，对所述多个边缘节点进行资源调度。

2.根据权利要求1所述的系统，其特征在于，所述用户区域是根据用户属性信息划分的；所述数据处理节点还包括：部署在各边缘节点中的日志采集模块和指标采集模块；

所述数据处理节点具体用于：利用所述指标采集模块采集各边缘节点的资源使用信息，利用所述日志采集模块采集各边缘节点中的用户访问日志；基于所述用户访问日志中的用户属性信息确定各边缘节点所服务的用户区域，并探测各边缘节点与其所服务用户区域中选定用户之间的网络参数；根据所述网络参数确定各边缘节点对其所服务用户区域的网络服务质量。

3.根据权利要求1所述的系统，其特征在于，所述管控节点在进行资源调度时，具体用于：在接收到应用部署请求的情况下，根据所述应用部署请求，确定需要部署目标应用的目标地理区域；根据所述目标地理区域内边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，选择至少一个目标边缘节点，在所述至少一个目标边缘节点中部署所述目标应用。

4.根据权利要求3所述的系统，其特征在于，所述管控节点在选择至少一个目标边缘节点时，具体用于：

根据所述目标地理区域内边缘节点的资源使用信息，从中选择可用资源信息满足资源需求的候选边缘节点；根据所述候选边缘节点对其所服务用户区域的网络服质量，从中选择网络服务质量满足设定网络要求的至少一个目标边缘节点。

5.根据权利要求3所述的系统，其特征在于，所述管控节点在确定目标地理区域时，具体用于：

根据所述应用部署请求中包含的应用部署方的标识信息，确定所述应用部署方的优先级；从多个资源调度模板中，选择与所述应用部署方的优先级适配的目标资源调度模板，所述目标资源调度模板中至少包括目标地理区域的标识信息。

6.根据权利要求3所述的系统，其特征在于，所述数据处理节点还用于：基于所述目标应用的用户访问日志中的用户属性信息，获取所述目标应用对应的用户区域及其资源消耗信息，并将所述目标应用对应的用户区域的资源消耗信息上报给所述管控节点；

所述管控节点还用于：根据所述目标应用对应的用户区域的资源消耗信息，确定待扩/缩容的目标用户区域；根据所述目标地理区域内可服务所述目标用户区域的边缘节点的资源使用信息和对所述目标用户区域的网络服务质量，针对所述目标用户区域进行资源扩/缩容。

7.根据权利要求3所述的系统，其特征在于，所述管控节点还用于：在接收到资源扩/缩容请求的情况下，根据所述资源扩/缩容请求，确定目标用户区域预计对所述目标应用的访问量；根据所述访问量，结合所述目标地理区域内可服务所述目标用户区域的边缘节点的资源使用信息和对所述目标用户区域的网络服务质量，针对所述目标用户区域进行资源扩/缩容。

8.一种资源调度方法，适用于边缘云系统，其特征在于，包括：

采集所述边缘云系统中多个边缘节点的资源使用信息，并探测所述多个边缘节点对其所服务用户区域的网络服务质量；

在需要对所述多个边缘节点进行资源调度的情况下，根据所述多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，对所述多个边缘节点进行资源调度。

9.根据权利要求8所述的方法，其特征在于，在需要对所述多个边缘节点进行资源调度的情况下，根据所述多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，对所述多个边缘节点进行资源调度，包括：

在接收到应用部署请求的情况下，根据所述应用部署请求，确定需要部署目标应用的目标地理区域；

根据所述目标地理区域内边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，选择至少一个目标边缘节点，在所述至少一个目标边缘节点中部署所述目标应用。

10.根据权利要求9所述的方法，其特征在于，所述用户区域是根据用户属性信息划分的；在需要对所述多个边缘节点进行资源调度的情况下，根据所述多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，对所述多个边缘节点进行资源调度，还包括：

基于所述目标应用的用户访问日志中的用户属性信息，获取所述目标应用对应的用户区域的资源消耗信息；根据所述目标应用对应的用户区域的资源消耗信息，确定待扩/缩容的目标用户区域；根据所述目标地理区域内可服务所述目标用户区域的边缘节点的资源使用信息和对所述目标用户区域的网络服务质量，针对所述目标用户区域进行资源扩/缩容；

或者

在接收到资源扩/缩容请求的情况下，根据所述资源扩/缩容请求，确定目标用户区域预计对所述目标应用的访问量；根据所述访问量，结合所述目标地理区域内可服务所述目标用户区域的边缘节点的资源使用信息和对所述目标用户区域的网络服务质量，针对所述目标用户区域进行资源扩/缩容。

11.一种管控节点，应用于边缘云系统，其特征在于，包括：存储器和处理器；所述存储器用于存储计算机程序，所述处理器与所述存储器耦合，用于执行所述计算机程序，以用于：接收所述边缘云系统中数据处理节点发送的所述边缘云系统中多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量；

在需要对所述多个边缘节点进行资源调度的情况下，根据所述多个边缘节点的资源使用信息和对其所服务用户区域的网络服务质量，对所述多个边缘节点进行资源调度。

12.一种存储有计算机程序的计算机可读存储介质，其特征在于，当所述计算机程序被处理器执行时，致使处理器实现权利要求8-10任一项所述方法中的步骤。

Images