CN115883486A - 边缘云混部场景下的服务动态纵向扩缩与保障方法及系统 - Google Patents

Abstract

本发明公开了一种边缘云混部场景下的服务动态纵向扩缩与保障方法及系统，包括：当请求到达边缘节点时，计算边缘节点可用的可压缩性资源和不可压缩性资源，根据计算出的资源量和请求所需资源量判断节点能否直接处理请求，如果不可以则确认不满足的资源类型，若请求的类型为LC服务且不满足资源为可压缩性资源，则利用基于Linux Cgroup技术构建的纵向动态扩缩组件更新资源，若请求的类型为LC服务且不满足资源为不可压缩性资源，则结束对应数量的BE请求释放不可压缩性资源，若请求的类型为BE请求，则等待直到所需资源均满足。本发明有效提升了系统的服务请求的吞吐量与集群的资源利用率，从而最大化分布式边缘云系统。

Description

边缘云混部场景下的服务动态纵向扩缩与保障方法及系统

技术领域

本发明属于计算机网络技术领域，具体涉及一种边缘云混部场景下的服务动态纵向扩缩与保障方法及系统。

背景技术

如今，越来越多的算力被边缘计算重新组织，并以分布式的方式被部署到各个不同的地域上。这在成功为用户提供更为迅捷的服务的同时也大大分担了主干网的流量压力，保障了数据隐私的安全。另一方面，各类服务依据服务质量要求可被划分延迟敏感型服务和离线批处理服务。延迟敏感型(latency-critical,LC)服务的服务质量要求较高，对请求处理延迟有着严格的要求，如直播视频、云游戏等业务；离线批处理(best-effort,BE)服务一般对延迟没有较高的要求，如数据分析与深度学习模型训练业务。业界通常将这两类服务混合部署到同一服务器上来提升成本效益。

现阶段，越来越多的服务以混合形式被共同部署在分布式边缘云集群上。但是传统的固定且超额分配资源的方式将导致集群资源利用率、请求吞吐量较低，且无法有效保障LC服务的服务质量。随着5G时代的到来，LC服务的QoS(Quality of Service，服务质量)要求变得越来越苛刻。分布式边缘云上无序的资源使用秩序将无法满足这些LC服务的服务质量需求从而导致严重的经济损失。另一方面，传统的横向服务扩缩方案因为启动成本较大将无法适配于有着严格要求QoS的LC服务。而现有的K8s上的纵向扩缩功能(VerticalPod Autoscaler,VPA)无法在服务实例运行过程中修改资源配置，这种非动态特征无法满足混合服务保障上的弹性需求。一次性的资源分配方案无法应对系统集群负载的复杂变化，导致系统资源难以被充分利用的同时LC服务的QoS也无法得到很好保障。同时，由于缺乏有效的服务扩缩与保障机制，当前分布式边缘云系统一般会为延迟敏感型服务额外预留许多资源以应对其负载变化，这导致集群的资源率普遍较低且大大抑制了系统的吞吐量。

因此，如何在分布式边缘云的混部系统上设计一种面向混合服务的有效动态纵向扩缩与保障方法来提升集群资源利用率、请求吞吐量以及保障LC服务的QoS，并考虑服务之间的不同特征来应对分布式边缘云混部场景下的各类请求已经成为一项重要挑战。

发明内容

针对以上问题，本发明提出了一种边缘云混部场景下的服务动态纵向扩缩与保障方法及系统，通过为分布式边缘云混部场景下的服务提供动态纵向扩缩与各类保障机制，有效提升了系统的服务请求的吞吐量与集群的资源利用率，并实现对请求服务质量的良好保障。为解决以上技术问题，本发明所采用的技术方案如下：

一种边缘云混部场景下的服务动态纵向扩缩与保障方法，包括如下步骤：

S1，构建包括若干个边缘云集群的分布式边缘云系统，每个边缘云集群均包括一个用于接收并分发请求的主节点和若干个用于处理请求的边缘节点；

S2，每个边缘云集群的主节点基于边缘节点的使用资源和请求所需资源量生成调度决策，并根据调度决策将接收到的请求发送到对应的边缘节点上；

S3，当请求到达对应的边缘节点时，计算边缘节点可用的可压缩性资源和可用的不可压缩性资源，根据计算出的资源量和请求所需要的资源量判断边缘节点能否直接处理该请求，如果可以则直接处理，如果不可以则执行步骤S4；

S4，确认请求的类型和不满足的资源类型，若请求的类型为LC服务且不满足的资源为可压缩性资源，则利用基于Linux Cgroup技术构建的纵向动态扩缩组件更新资源，若请求的类型为LC服务且不满足的资源为不可压缩性资源，则结束对应数量的BE请求释放不可压缩性资源，若请求的类型为BE请求，则继续等待直到所需的资源均满足，超时的请求将被丢弃；

S5，利用QoS监测器对每个边缘节点的服务质量进行实时监测，使边缘节点的服务质量处于预设稳定区间。

在步骤S2中，所述边缘节点的使用资源包括正在被使用的CPU资源和正在被使用的内存资源，正在被使用的CPU资源的计算公式为：

式中，

表示t时刻边缘节点n上正在被服务类型为k的LC服务所使用的CPU资源，/>

表示t时刻边缘节点n上正在被服务类型为k'的BE服务所使用的CPU资源，c_n,t表示t时刻边缘节点n上正在被使用的CPU资源，/>

表示服务类型的集合；

正在被使用时的内存资源的计算公式为：

式中，

表示t时刻边缘节点n上正在被服务类型为k的LC服务所使用的内存资源，/>

表示t时刻边缘节点n上正在被服务类型为k'的BE服务所使用的内存资源，z_n,t表示t时刻边缘节点n上正在被使用的内存资源。

在步骤S3中，所述可压缩性资源包括CPU资源和带宽资源，不可压缩性资源包括内存资源和硬盘资源。

LC服务请求的可用CPU资源的计算公式为：

式中，

表示t时刻边缘节点n上的LC服务请求的可用CPU资源，/>

表示t时刻边缘节点n上正在被服务类型为k'的BE服务请求所使用的CPU资源，/>

表示服务类型的集合，/>

表示t时刻边缘节点n上的空闲CPU资源；

LC服务请求的可用内存资源的计算公式为：

/>

式中，

表示t时刻边缘节点n上的LC服务请求的可用内存资源，/>

表示t时刻边缘节点n上的空闲内存资源，/>

表示t时刻边缘节点n上正在被服务类型为k'的BE服务请求所使用的内存资源；

BE服务请求的可用CPU资源采用

表示，其计算公式为：

BE服务请求的可用内存资源采用

表示，其计算公式为：

所述步骤S5包括如下步骤：

S5.1，设定服务质量优异值η和服务质量合格值μ；

S5.2，利用松弛函数计算松弛得分；

S5.3，根据步骤S5.2得到的松弛得分对边缘节点的可压缩性资源进行调整以使边缘节点的服务质量处于预设稳定区间内。

所述松弛得分的计算公式为：

式中，

表示t时刻边缘节点n上部署服务类型为k的服务请求时的松弛得分，

表示边缘节点n上的服务类型为k的服务请求的平均处理延迟，γ^k表示服务类型为k的服务请求的Qos目标延迟。

所述根据松弛得分对边缘节点的可压缩性资源进行调整的方法为：

当

时，对可压缩性资源进行回收，资源回收份额的计算公式为：

式中，ρ^k表示边缘节点回收服务类型为k的LC服务所使用资源份额的基准，ω表示回收因子，τ表示资源回收份额；

当

时，资源增加额的计算公式为：

式中，ρ′^k表示边缘节点增加服务类型为k的LC服务的资源份额的基准，ω′表示增加因子，τ′表示资源增加额。

一种边缘云混部场景下的服务动态纵向扩缩与保障系统，包括若干个边缘云集群，且每个边缘云集群均包括一个主节点和若干个边缘节点；

每个主节点上均部署有调度决策器，其用于接收所在边缘云集群的边缘节点的使用资源，并基于使用资源和接收请求的所需资源量生成调度决策，并依据调度决策将请求发送到对应的边缘节点上；

每个边缘节点上均部署了LC请求调度器与BE请求调度器，具体地：

LC请求调度器：用于接收LC服务请求，计算LC服务请求的可用的可压缩性资源和可用的不可压缩性资源，根据LC服务请求的所需资源量确认边缘节点是否可以直接处理该请求，如果不可以，则确认不满足的资源类型，若为可压缩性资源，则利用基于LinuxCgroup技术构建的纵向动态扩缩组件更新资源，若不满足的资源类型为不可压缩性资源，则结束对应数量的BE请求的资源，以对LC服务请求进行处理；

BE请求调度器：用于接收BE服务请求，计算BE服务请求的可用的可压缩性资源和可用的不可压缩性资源，根据BE服务请求的所需资源量确认边缘节点是否可以直接处理该请求，如果不可以则继续等待，超时的请求将被丢弃。

本发明的有益效果：

本申请通过在支持边缘计算的分布式边缘云混部系统中为分布式边缘云混部场景下的服务提供动态纵向扩缩与各类保障机制，有效应对了分布式边缘云场景下服务的不同特性与需求，实现了在分布式边缘云系统上对混合服务调度与处理的高效协调，在减少LC服务的服务水平目标(SLO)违反的同时，保障服务质量，有效提升了系统的服务请求的吞吐量与集群的资源利用率，从而最大化分布式边缘云系统的利用，高效应对动态变化的用户请求与服务需求，带来了更进一步的经济效益与质量保障。

附图说明

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

图1为本发明的资源调整示意图。

图2为服务纵向动态扩缩D-VPA组件流程图。

图3为服务再保障机制示意图。

具体实施方式

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

边缘计算(Edge Computing)：边缘计算以分布式方式被部署到不同的地理区域，凭借其更加邻近用户端的优势，将许多原本不得不提交给云中心的请求任务进行本地处理。由于可以在边缘节点上本地存储和处理数据，数据无需再全部上传到云数据中心，这在大大减轻主干网的流量负载压力和增加网络带宽管理利用效率的同时，可以以更快的响应速度有效地加速了请求任务的处理，减少了通信时延。凭借着多方位的边缘智能化服务的提供，边缘计算已成为数字世界与物理世界的有效纽带。

混合部署(Colocation)：延迟敏感型服务(LC服务)如网页搜索、云游戏、智能车载导航对实时性和稳定性有着较高的要求，企业一般会提供服务等级协议(service levelagreement,SLA)来约定服务质量，违反SLA时将带来经济上的损失。离线批处理服务(BE服务)对延迟与性能没有苛刻的要求，即便被重新运行依旧能带来较高经济价值。将这两类服务混合部署到集群上(简称“混部”)已成为有效提高集群资源利用率、提升效益的主流方案。

Kubernetes集群容器管理平台(K8s)：Kubernetes是一个被业界高度认可的容器工程编排管理平台，前身是Google Borg。Kubernetes基于linux开发且完全开源，具备容器部署、扩缩及自动化管理的功能。Docker、Rocket等各种容器技术作为Kubernetes的底层技术支持，Kubernetes可以实现集群间容器的负载均衡，并提供了应用迭代更新等功能。Kubernetes集群一般包含主要节点和若干工作节点。这些节点可以在虚拟机或物理机中操作。在Kubernetes中，作为最小执行部件的Pod由一组一个或者几个容器构成。Pods彼此之间紧密耦合，共享存储并享用唯一的集群IP地址。

实施例1：一种边缘云混部场景下的服务动态纵向扩缩与保障方法，包括如下步骤：

S1，构建包括若干个边缘云集群的分布式边缘云系统，且每个边缘云集群均包括一个用于接收并分发请求的主节点和若干个用于处理请求的边缘节点；

多个边缘云集群一起组成了分布式边缘云系统，单个边缘云集群由多个边缘节点和一个主节点构成，边缘云集群之间通过广域网互联，边缘云集群内部的边缘节点之间、主节点和边缘节点之间通过局域网互联。分布式边缘云集群的集合为

其中/>

代表一个具体的边缘云集群。边缘节点的集合为/>

其中/>

代表一个具体的边缘节点，主节点采用/>

表示，/>

和/>

组成一个边缘云集群。每个边缘云集群的主节点用于接收请求，并将请求分发到边缘节点上，边缘节点基于当前资源观测值对资源进行分配，将请求转发至对应服务容器处理。

S2，如图1所示，每个边缘云集群的主节点基于边缘节点的使用资源和请求所需资源量生成调度决策，并根据调度决策将接收到的请求发送到对应的边缘节点上，包括如下步骤：

S2.1，计算每个边缘节点的使用资源，并将使用资源和每个边缘节点的总资源发送到所在边缘云集群的主节点上；

所述总资源包括正在被使用的资源和未被使用的资源，所述使用资源包括正在被使用的CPU资源和正在被使用的内存资源，对应的计算公式如下：

式中，

表示t时刻边缘节点n上正在被服务类型为k的LC服务所使用的CPU资源，/>

表示t时刻边缘节点n上正在被服务类型为k'的BE服务所使用的CPU资源，且

c_n,t表示t时刻边缘节点n上正在被使用的CPU资源。

式中，

表示t时刻边缘节点n上正在被服务类型为k的LC服务所使用的内存资源，/>

表示t时刻边缘节点n上正在被服务类型为k'的BE服务所使用的内存资源，z_n,t表示t时刻边缘节点n上正在被使用的内存资源。

对于t时刻，主节点接收到请求后，根据请求的类型将请求存储在LC待决策队列

和BE待决策队列/>

中，然后依据各边缘节点正在被使用的总CPU资源c_n,t和内存资源z_n,t来确定具体的请求转发数量，且同类型的请求依据FIFO原则进行决策处理，不同类型的请求拥有相同的优先级。当待决策队列已满时，将丢弃新接收到的超额请求。

S2.2，主节点根据接收到的边缘节点的使用资源、总资源和接收请求所需的资源量生成调度决策，并根据调度决策将接收到的请求发送到对应的边缘节点上；

对于请求任务，第m个边缘云集群的调度决策表示如下：

第i个请求调度至边缘节点n。

具体地，主节点首先利用每个边缘节点的使用资源和总资源计算出未被使用的资源，依次将每个边缘节点的未被使用的资源与每个接收请求的所需的资源量进行比较，如果满足所需的资源量，则将请求调度到该边缘节点，如果不满足，则判断下一个边缘节点，若所有节点资源都不足时，请求将在对应的待决策队列中继续等待，超时的请求将被丢弃。

调度决策确定的被调度转发的请求将加入对应边缘节点的待处理队列，定义边缘节点n在t时刻的LC待处理队列和BE待处理队列分别为

和/>

待处理队列将依据时刻t的正在被使用的总CPU资源c_n,t和内存资源z_n,t的资源情况将请求路由至边缘节点上部署的对应服务容器进行处理，并且更新分配资源后的资源信息。当待处理队列已满时，队列将丢弃新接收到的超额请求。

S3，当请求到达对应的边缘节点时，计算边缘节点可用的可压缩性资源和可用的不可压缩性资源，根据计算出的资源量和请求所需要的资源量判断边缘节点能否直接处理该请求，如果可以则直接处理，如果不可以则执行步骤S4；

所述可压缩性资源包括CPU资源和带宽资源，不可压缩性资源包括内存资源和硬盘资源，请求的类型包括LC服务请求和BE服务请求。

LC服务请求的可用CPU资源的计算公式为：

式中，

表示t时刻边缘节点n上的LC服务请求的可用CPU资源，/>

表示t时刻边缘节点n上正在被服务类型为k'的BE服务请求所使用的CPU资源，且/>

表示t时刻边缘节点n上的空闲CPU资源。

LC服务请求的可用内存资源的计算公式为：

式中，

表示t时刻边缘节点n上的LC服务请求的可用内存资源，/>

表示t时刻边缘节点n上的空闲内存资源，/>

表示t时刻边缘节点n上正在被服务类型为k'的BE服务请求所使用的内存资源。

BE服务请求的可用CPU资源采用

表示，其计算公式为：

BE服务请求的可用内存资源采用

表示，其计算公式为：

同理地，LC服务请求的可用带宽资源的计算是通过当前时刻BE服务请求所使用的带宽资源和边缘节点的空闲带宽资源求和得到，LC服务请求的可用硬盘资源是通过当前时刻BE服务请求所使用的带宽资源和边缘节点的空闲带宽资源求和得到，BE服务请求的可用带宽资源等于当前时刻边缘节点的空闲带宽资源，BE服务请求的可用硬盘资源等于当前时刻边缘节点的空闲带宽资源。

S4，确认请求的类型和不满足的资源类型，若请求的类型为LC服务且不满足的资源为可压缩性资源，则利用基于Linux Cgroup技术构建的纵向动态扩缩组件更新资源，若请求的类型为LC服务且不满足的资源为不可压缩性资源，则结束对应数量的正在处理的BE请求释放不可压缩性资源，以对LC服务请求进行处理，若请求的类型为BE请求，则在待处理队列中继续等待直到所需的资源均满足也即该BE请求所需的可压缩性资源与不可压缩性资源均满足，超时的请求将被丢弃；

在K8s中，Pod是最小的资源调度管理单位。LC、BE服务的容器在被创建时都被一个对应的Pod包裹，受Pod管理。因此，要做到k8s中的纵向动态扩缩，需要使用Linux CGroup对服务的Pod与容器资源文件进行有序的数据更改。如图2所示，借助Linux Cgroup技术构建服务纵向动态扩缩D-VPA组件，实现了细粒度的请求资源分配与回收。具体的，对于CPU资源与内存资源的更新控制主要涉及两个路径下的文件：(a)/sys/fs/cgroup/cpu,cpuacct/kubepods，(b)/sys/fs/cgroup/memory/kubepods。通过动态修正两个路径下的cpu.shares、cpu.cfs_quota_us、memory.limit_in_bytes来实现对请求资源的细粒度调控。另外，以上仅以CPU、内存资源的控制作为例子，对于例如磁盘、带宽等资源的控制同样可以利用相似方式实现。

对于服务类型为

的请求，/>

表示服务类型的集合，其资源需求被建模为(α,β)，其中α代表请求所需要的最小CPU资源量，β代表请求所需要的最小内存资源量。服务实例以容器的形式被部署在各个边缘节点上。

所述利用基于Linux CGroup技术构建的纵向动态扩缩组件更新资源，更新后的CPU资源为

更新后的内存资源为/>

其中，x表示请求的数量，若这x个请求在t+1时刻处理完成，对应的资源通过纵向动态扩缩组件及时回收到资源池，此时该容器拥有的分配资源如下：

/>

式中，

表示t+1时刻边缘节点n上正在被服务类型为k的LC服务所使用的CPU资源，/>

表示t+2时刻边缘节点n上正在被服务类型为k的LC服务所使用的CPU资源，

表示t+1时刻边缘节点n上正在被服务类型为k的LC服务所使用的内存资源，/>

表示t+2时刻边缘节点n上正在被服务类型为k的LC服务所使用的内存资源。

所述结束对应数量的BE请求的资源即为向BE服务容器发送处理信号，杀死一定数量的正在处理的BE请求来释放对应数量的资源。由于分布式边缘云系统存在着数据同步等无法避免的通讯延迟，请求调度后，由边缘节点再次对可用资源进行重新确认，提高了请求处理的成功率。

S5，如图3所示，利用QoS监测器对每个边缘节点的服务质量进行实时监测，使边缘节点的服务质量处于预设稳定区间，包括如下步骤：

S5.1，设定服务质量优异值η和服务质量合格值μ；

服务质量稳定区间通过预设η和μ确定，当边缘节点处于服务质量稳定区间时，无需调整资源份额。

S5.2，利用松弛函数计算松弛得分；

所述松弛得分的计算公式为：

式中，

表示t时刻边缘节点n上部署服务类型为k的服务请求时的松弛得分，

表示边缘节点n上的服务类型为k的服务请求的平均处理延迟，γ^k表示服务类型为k的服务请求的Qos目标延迟。

S5.3，根据步骤S5.2得到的松弛得分对边缘节点的可压缩性资源进行调整以使边缘节点的服务质量处于预设稳定区间内；

所述根据松弛得分对边缘节点的资源进行调整的方法为：

当

时，对可压缩性资源进行回收，资源回收份额τ的计算公式为：

式中，ρ^k表示边缘节点回收服务类型为k的LC服务所使用资源份额的基准，其通过提前对该类服务进行压测确定，具体地，可以通过对一正常的运行的k类型服务逐步增加回收可压缩性资源的数量，直至其服务质量出现明显的下降，ω表示回收因子。

当

时，对正在处理的LC服务的可压缩性资源进行增加，资源增加额τ′的计算公式为：

式中，ρ′^k表示边缘节点增加服务类型为k的LC服务的资源份额的基准，其通过提前对该类服务进行压测确定，具体压测方法同上，ω′表示增加因子。

QoS监测器实时收集LC服务请求的延迟，监测的时间窗口为100ms。当松弛得分为负时，表明该LC服务的请求时延已不满足目标QoS，且松弛得分越低，表明违反程度越严重。当

时，也即边缘节点处于服务质量不合格区间时，通过增加资源可以加快LC服务请求的处理；当/>

时，边缘节点即处于服务质量稳定区间；当/>

时，也即边缘节点处于服务质量优异区间时，通过回收少量资源可以加快BE服务请求的处理。

通过本申请实现了最大化BE请求处理总数和LC服务请求的QoS保障率的目标，所述目标的表达式为：

式中，s′_m,t表示t时刻边缘云集群m上完成处理的BE请求的总数量，s_m,t表示t时刻边缘云集群m上被成功完成(即满足QoS要求)的LC请求数量，V_m,t表示t时刻边缘云集群m上到达的LC请求的总数量，其中，

表示BE服务请求的指标，

表示LC服务请求的指标也即QoS保障率。

实施例2：一种边缘云混部场景下的服务动态纵向扩缩与保障系统，包括若干个边缘云集群，且每个边缘云集群均包括一个主节点和若干个边缘节点；边缘云集群之间通过广域网互联，边缘云集群内部的边缘节点之间、主节点和边缘节点之间通过局域网互联。

每个主节点上均部署有调度决策器，其用于接收所在边缘云集群的边缘节点的使用资源，并基于使用资源和接收请求的所需资源量生成调度决策，并依据调度决策将请求发送到对应的边缘节点上；

每个边缘节点上均部署了LC请求调度器与BE请求调度器，两个调度器并行执行，具体地：

LC请求调度器：用于接收LC服务请求，计算LC服务请求的可用的可压缩性资源和可用的不可压缩性资源，根据LC服务请求的所需资源量确认边缘节点是否可以直接处理该请求，如果不可以，则确认不满足的资源类型，若为可压缩性资源，则利用基于LinuxCgroup技术构建的纵向动态扩缩组件更新资源，若不满足的资源类型为不可压缩性资源，则结束对应数量的BE请求的资源，以对LC服务请求进行处理；

BE请求调度器：用于接收BE服务请求，计算BE服务请求的可用的可压缩性资源和可用的不可压缩性资源，根据BE服务请求的所需资源量确认边缘节点是否可以直接处理该请求，如果不可以则继续等待，超时的请求将被丢弃。

优选地，每个边缘节点上还设有用于对边缘节点的服务质量进行实时监测的QoS监测器，使边缘节点的服务质量处于预设稳定区间。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种边缘云混部场景下的服务动态纵向扩缩与保障方法，其特征在于，包括如下步骤：

S1，构建包括若干个边缘云集群的分布式边缘云系统，每个边缘云集群均包括一个用于接收并分发请求的主节点和若干个用于处理请求的边缘节点；

S2，每个边缘云集群的主节点基于边缘节点的使用资源和请求所需资源量生成调度决策，并根据调度决策将接收到的请求发送到对应的边缘节点上；

S3，当请求到达对应的边缘节点时，计算边缘节点可用的可压缩性资源和可用的不可压缩性资源，根据计算出的资源量和请求所需要的资源量判断边缘节点能否直接处理该请求，如果可以则直接处理，如果不可以则执行步骤S4；

S4，确认请求的类型和不满足的资源类型，若请求的类型为LC服务且不满足的资源为可压缩性资源，则利用基于Linux Cgroup技术构建的纵向动态扩缩组件更新资源，若请求的类型为LC服务且不满足的资源为不可压缩性资源，则结束对应数量的BE请求释放不可压缩性资源，若请求的类型为BE请求，则继续等待直到所需的资源均满足，超时的请求将被丢弃；

S5，利用QoS监测器对每个边缘节点的服务质量进行实时监测，使边缘节点的服务质量处于预设稳定区间。

2.根据权利要求1所述的边缘云混部场景下的服务动态纵向扩缩与保障方法，其特征在于，在步骤S2中，所述边缘节点的使用资源包括正在被使用的CPU资源和正在被使用的内存资源，正在被使用的CPU资源的计算公式为：

式中，

表示t时刻边缘节点n上正在被服务类型为k的LC服务所使用的CPU资源，

表示t时刻边缘节点n上正在被服务类型为k'的BE服务所使用的CPU资源，c_n,t表示t时刻边缘节点n上正在被使用的CPU资源，/>

表示服务类型的集合；

正在被使用时的内存资源的计算公式为：

式中，

表示t时刻边缘节点n上正在被服务类型为k的LC服务所使用的内存资源，

表示t时刻边缘节点n上正在被服务类型为k'的BE服务所使用的内存资源，z_n,t表示t时刻边缘节点n上正在被使用的内存资源。

3.根据权利要求1所述的边缘云混部场景下的服务动态纵向扩缩与保障方法，其特征在于，在步骤S3中，所述可压缩性资源包括CPU资源和带宽资源，不可压缩性资源包括内存资源和硬盘资源。

4.根据权利要求3所述的边缘云混部场景下的服务动态纵向扩缩与保障方法，其特征在于，LC服务请求的可用CPU资源的计算公式为：

式中，

表示t时刻边缘节点n上的LC服务请求的可用CPU资源，/>

表示t时刻边缘节点n上正在被服务类型为k'的BE服务请求所使用的CPU资源，/>

表示服务类型的集合，

表示t时刻边缘节点n上的空闲CPU资源；

LC服务请求的可用内存资源的计算公式为：

式中，

表示t时刻边缘节点n上的LC服务请求的可用内存资源，/>

表示t时刻边缘节点n上的空闲内存资源，/>

表示t时刻边缘节点n上正在被服务类型为k'的BE服务请求所使用的内存资源；

BE服务请求的可用CPU资源采用

表示，其计算公式为：

BE服务请求的可用内存资源采用

表示，其计算公式为：

5.根据权利要求1所述的边缘云混部场景下的服务动态纵向扩缩与保障方法，其特征在于，所述步骤S5包括如下步骤：

S5.1，设定服务质量优异值η和服务质量合格值μ；

S5.2，利用松弛函数计算松弛得分；

S5.3，根据步骤S5.2得到的松弛得分对边缘节点的可压缩性资源进行调整以使边缘节点的服务质量处于预设稳定区间内。

6.根据权利要求5所述的边缘云混部场景下的服务动态纵向扩缩与保障方法，其特征在于，所述松弛得分的计算公式为：

式中，

表示t时刻边缘节点n上部署服务类型为k的服务请求时的松弛得分，/>

表示边缘节点n上的服务类型为k的服务请求的平均处理延迟，γ^k表示服务类型为k的服务请求的Qos目标延迟。

7.根据权利要求5所述的边缘云混部场景下的服务动态纵向扩缩与保障方法，其特征在于，所述根据松弛得分对边缘节点的可压缩性资源进行调整的方法为：

当

时，对边缘节点的可压缩性资源进行回收，资源回收份额的计算公式为：

式中，ρ^k表示边缘节点回收服务类型为k的LC服务所使用资源份额的基准，ω表示回收因子，τ表示资源回收份额；

当

时，对边缘节点的处理LC服务的可压缩性资源进行增加，资源增加额的计算公式为：

式中，ρ′^k表示边缘节点增加服务类型为k的LC服务的资源份额的基准，ω′表示增加因子，τ′表示资源增加额。

8.一种边缘云混部场景下的服务动态纵向扩缩与保障系统，其特征在于，包括若干个边缘云集群，且每个边缘云集群均包括一个主节点和若干个边缘节点；

每个主节点上均部署有调度决策器，其用于接收所在边缘云集群的边缘节点的使用资源，并基于使用资源和接收请求的所需资源量生成调度决策，并依据调度决策将请求发送到对应的边缘节点上；

每个边缘节点上均部署了LC请求调度器与BE请求调度器，具体地：

LC请求调度器：用于接收LC服务请求，计算LC服务请求的可用的可压缩性资源和可用的不可压缩性资源，根据LC服务请求的所需资源量确认边缘节点是否可以直接处理该请求，如果不可以，则确认不满足的资源类型，若为可压缩性资源，则利用基于Linux Cgroup技术构建的纵向动态扩缩组件更新资源，若不满足的资源类型为不可压缩性资源，则结束对应数量的BE请求的资源，以对LC服务请求进行处理；

BE请求调度器：用于接收BE服务请求，计算BE服务请求的可用的可压缩性资源和可用的不可压缩性资源，根据BE服务请求的所需资源量确认边缘节点是否可以直接处理该请求，如果不可以则继续等待，超时的请求将被丢弃。

Images