基于无服务器边缘计算下的服务负载调度算法

高明 陈国扬

摘 要：随着边缘计算的不断发展，其在资源管理配置方面逐渐出现相关问题，无服务器计算作为一种新的方式可以有效解决边缘计算的相关问题。然而，无服务器计算不具备在分布式边缘场景中高效处理请求所需服务负载调度的能力，针对这一问题，提出了一种基于无服务器边缘计算的服务负载调度算法（service load scheduling algorithm，SLSA）。SLSA的核心是通过隐式建模充分考虑了动态变化的节点状态、负载调度器放置等影响因素来优化整体时延，然后通过改进的平滑加权轮询调度（smooth weighted round robin，SWRR）算法进行服务调度。经仿真实验分析，SLSA在资源消耗上有着明显下降，同时在单城市场景与多城市场景下均有良好的性能表现，其中在单城市场景中相对于集中式轮询调度（round robin centralized，RRC）算法提升了43.01%，在多城市场景中提升了53.81%。实验结果表明，SLSA可以有效降低资源消耗率并提升性能。

关键词：边缘计算； 无服务器计算； 负载调度； 性能对比

中图分类号：TP393   文献标志码：A

文章编号：1001-3695（2024）03-024-0811-07

doi：10.19734/j.issn.1001-3695.2023.07.0295

Service load scheduling algorithm based on serverless edge computing

Gao Ming， Chen Guoyang

（School of Information & Electronic Engineering， Zhejiang Gongshang University， Hangzhou 310018， China）

Abstract：With the continuous development of edge computing， there are gradually related problems in resource management and configuration. As a new way， serverless computing can effectively solve the related problems of edge computing. However， serverless computing does not have the ability to efficiently process requests in distributed edge scenarios. To solve this problem， this paper proposed a service load scheduling algorithm（SLSA） based on serverless edge computing. The core of SLSA was to fully consider the dynamic changes of node status， load scheduler placement and other influencing factors through implicit modeling to optimize the overall delay， and then used the improved smooth weighted round robin（SWRR） scheduling algorithm for service scheduling. The simulation results show that SLSA has a significant reduction in resource consumption， and has good performance in both single-city scenarios and multi-city scenarios. In the single-city scenario， SLSA is 43.01% higher than the RRC algorithm. It improves 53.81% in multi-city scenarios. Experimental results show that SLSA can effectively reduce the resource consumption rate and improve the performance.

Key words：edge computing; serverless computing; load scheduling; performance comparison

0 引言

隨着大量互联网应用（如虚拟现实、人工智能等）的不断发展，数据量日益增长，由于网络远距离传输的不确定性，云计算这种集中处理模式对于那些实时性和可靠性要求比较高的应用场景非常不适用［1］。边缘计算在此背景下应运而生，它在靠近用户侧的网络边缘部署云计算环境，就近处理数据和计算任务，可以有效处理大量任务需求，相比于传统的云计算更高效、更安全［2］。但也正是由于边缘计算靠近数据源头，其工作环境更为复杂，存在大量的分布式异构设备和资源，这为管理和维护这些设备以确保它们的正常运行和安全性带来了极大的困难。此时，无服务计算（serverless computing）［3］进入业界视线当中。无服务计算是指在构建和应用程序时不需要管理服务器的一种计算范式，它描述了细粒度部署模型，由一个或多个函数组成的应用可上传到平台，并执行、扩缩容和基于实际运行时的资源消耗及进行计费［4］。无服务器计算并不是没有服务器，Serverless架构的背后依然是虚拟机和容器，只不过服务器部署、runtime安装、编译等工作，都由Serverless平台负责完成，对开发人员来说，只需维护源代码和Serverless执行环境的相关配置即可。同时，相比于基础设施即服务（infrastructure as a service，IaaS）、平台即服务（platform as a service，PaaS）等计算架构，Serverless计算架构能提供更细粒度的资源管理和部署模型，通过计算资源的按需分配，实现计算资源的动态调整和高效利用［5］。

基于该思路，业界逐渐意识到边缘计算和无服务器计算融合的价值和必要性［6］。边缘设备上的计算和存储资源是相对有限的，且在传统的边缘计算框架下，用户仍然承担着繁重的资源配置和管理负担，因此迫切需要一种方法来有效利用边缘资源。无服务器计算提供了一种新的方式，基于轻量级抽象（含容器、Unikernel等），Serverless 会满足较小的占用空间，细粒度自动扩缩容，因此创建/终止副本的开销相对是非常小的［7］。同时，将无服务器计算集成到边缘计算场景中，可以让应用在使用边缘计算资源时不考虑运行环境、负载均衡和可扩展性，从而有效提高边缘资源的利用率，为用户提供更灵活的服务。

随着两者进一步的融合，无服务器边缘计算的概念也随之提出［6］。但是，无服务器计算设计的初衷是为云计算服务的，将其应用在边缘计算场景中仍存在挑战。边缘计算的基础设施资源是受限且异构的，每个边缘计算节点会对所部署的服务类型具有限制，無服务器计算不具备在分布式边缘场景中高效处理请求所需服务负载调度的能力［1］。因此，在无服务器边缘计算中，如何在分布式的网络环境中实现高效的服务调度成为了亟待解决的问题，为此，本文提出了一种基于无服务器边缘计算环境的服务负载调度算法。首先把工作过程中的服务负载调度响应时间看成黑盒，然后基于负载调度器来观察节点对应的平均历史响应时间，推导出其对应动态变化的节点权重，通过动态权重来进一步改进平滑加权轮询调度算法，同时判断放置负载调度器的有效性，最后进行优化调度来实现高效服务调度。

1 相关工作

随着无服务边缘计算的不断发展，业界对如何提升其性能展开了研究工作。在服务负载调度方面，Rausch等人［8］利用 Serverless 架构的优势将AI应用推向边缘，并通过对调度决策采用更细粒度的控制和约束以保障在资源受限的边缘计算中获得更优的性能表现。进一步地，面对边缘架构的异构性，以及计算和存储基础设施的地理分布，他们在文献［8］中使用启发式的方法，提出一种容器调度策略以优化在 Serverless 边缘计算中部署数据密集型应用的开销，通过自动微调调度约束权重以最小化任务执行时间以及上行链路使用成本，但是他们并不认为系统的负载平衡组件可以独立于其他功能进行扩展和调度。Cicconetti等人［9］提出了在无服务器系统中匹配客户端和功能副本的不同方法，他们评估了不同的分配策略，通过模拟显示，在静态全局匹配、周期性全局匹配和客户端到副本的动态分散匹配之间，分散版本表现最佳。然而，在他们的研究中，客户机通过一个集中的编排组件被分配给调度程序，这在大量数据来临时可能会造成资源浪费，因此在论文中改进成客户机连接到发送请求时距离最近的负载平衡器。

除了无服务器计算和边缘计算之间的融合，Zhao等人［10］提出了启发式算法，有效地将服务放置在移动边缘计算环境中。他们的目标是通过优化边缘计算系统中给定数量的副本的放置决策，最大限度地减少系统内的总体数据流量。他们首先制定了优化问题，其目标是在可用节点中放置k个服务副本，以便由客户机请求生成的网络内的总体流量最小。他们提出了一种启发式算法，对于给定的k个副本的目标部署，将所有可能节点的集合划分为k个集群。在每个集群中，一个副本被放置在集群中可用的最佳节点上。虽然不一定是最优的，但划分为多个集群大大降低了计算复杂性，同时执行的性能几乎与最佳放置的全空间搜索相同。但是，他们的方法没有考虑节点之间的任务划分，这会导致一定资源的浪费。

基于上述工作，本文作出了进一步改进，通过考虑边缘计算中不同的网络条件、动态变化的节点状态等因素，同时综合考虑服务负载调度器的扩展和调度来实现高效服务负载调度的目标。

2 无服务器边缘计算系统建模与问题描述

2.1 整体模型

如图1所示，一种典型的基于无服务器边缘计算系统的场景［11］设置在智慧城市中，系统由若干个Serverless边缘计算集群、服务调度器、云计算中心和用户设备组成，并通过图1中的链路进行连接。

由图1可知，用户设备指需要调用计算服务的终端设备，用户设备向Serverless 边缘计算集群提交服务请求，根据服务请求，将会分配对应的Serverless函数，这些函数根据服务放置策略将会在相应节点中实例化，然后由服务调度器将服务请求调度至相应的节点。当某种服务的请求量出现突发增长时，Serverless计算集群将会对函数实例进行扩容，即在其他节点增加函数的副本数来满足计算需求。基于该框架，开发人员只需关心服务所对应函数的功能实现，即“无服务”。云计算中心为客户端提供了无限的计算能力，云计算中心通常离客户端较远，将导致较高的传输成本和服务执行时延，因此云计算中心更适合执行延迟非敏感型应用。此外，当函数不适合在边缘执行时，云计算中心还可以进一步提供计算服务。

在了解上述场景的具体流程后，在实际场景中能够发现当前的Serverless计算架构不具备在边缘场景中高效处理请求所需的服务负载调度机制。现有的Serverless平台通常建立在容器编排平台Kubernetes之上来实现计算资源的池化和纳管，并基于Kubernetes平台实现Serverless服务管理平台［12］。这些Serverless服务管理平台依赖于Kubernetes底层原有的服务负载调度策略，而这些服务负载调度策略是基于云计算中计算能力和网络结构相对同质的前提实现的。因此，将在2.2节中定义一个问题描述来进一步了解问题所在。

2.2 问题描述

如图2所示，以最受欢迎的开源Serverless框架OpenFaaS为例［13］，其使用API Gateway组件作为请求的入口，该组件接收客户端的请求，再将请求转发至相应的函数。

在OpenFaaS中，API Gateway收到请求后依赖Kubernetes平台进行路由，Kube-Proxy作为Kubernetes中负责处理网络路由和容器实例负载均衡的组件，默认采用的是轮询的策略进行负载调度。也就是说，函数f1对应的请求将在已实例化的node1和node2中轮询执行。对于计算资源和网络都比较统一的云计算来说，采用轮询的调度策略从长期来看是公平的，而对于异构的边缘计算网络来说，简单的轮询策略无论从短期还是长期来说都是不公平的。如图2所示，上一轮请求中，函数f1在node1中被执行，而在本轮请求中，函数f1被调度至node2执行，node1与node2之间存在着50 ms的网络延迟，在节点性能相同的情况下，本轮请求继续在node1中执行会比在node2中执行具有更低的响应时延，但由于负载调度策略未考虑到异构性，从而造成了更长的客户端等待时间。此外，从图2可以发现，API gateway作为唯一请求的入口，部署于node1中，当另一个客户端在node2附近提交计算任务，那么请求需要借助Kubernetes底层网络转发至node1中的API gateway，采用集中式的服务负载入口会导致更长的客户端等待时间。这些问题都是采用云计算中的Serverless服务负载调度策略导致的。

对以上问题进行分析，主要是现有的服务负载调度策略没有考虑到边缘结构中不同节点性能会实时变化，除此之外，现有策略的集中式调度会导致更长的等待时间。所以，为了在边缘计算环境下更好地应用Serverless架构，对于服务负载调度策略，需要满足以下两点：

a）自适应负载调度：服务负载调度器在调度计算任务时应尽量选择网络距离较近的实例化节点，并且综合考虑动态变化的边缘节点、客户端网络位置对函数执行时间的影响。

b）有效放置：服务负载调度器应放置在离客户端和实例化节点网络距离较近的节点，并且考虑位置对性能的影响，来解决由于负载调度器放置问题引起的调度时延放大问题。

考虑到负载调度的各种潜在复杂因素，本文决定给负载调度方法采用一种相对简单的方法。服务负载调度决策完全基于负载调度器观察到的总响应时间，这意味着其不区分不同网络部分产生的时间，因此，本文将总响应时间视为整个系统的黑盒来进行度量。除此之外，加权轮循调度是实现负载均衡的重要策略之一，在实验了其他解决方案，并根据无服务器边缘计算环境带来的独特挑战分析了它们的性能概况和特征后，本文选择了Nginx［14］中的平滑加权轮询调度算法（smooth weighted round robin，SWRR），相比于经典的加权轮询调度在某些特殊的权重下会生成不均匀的实例序列，SWRR算法克服了这一问题，避免了实例负载突然加重的可能。但是，SWRR无法动态感知系统集群中实例的性能变化［15］，会导致系统稳定性的恶化。因此，针对SWRR无法动态感知性能变化这一缺点，同时针对服务调度器的有效放置问题，在第3章中设计了一种基于无服务器边缘计算下的服务负载调度算法（service load scheduling algorithm，SLSA），以高效地寻找响应时间最优解。

3 无服务器边缘计算下的服务负载调度算法

SLSA的核心思想主要是把整个工作过程中的服务负载调度响应时间看成黑盒，基于负载调度器来观察每个节点对应的平均历史响应时间，接着推导出对应动态变化的节点性能权重，基于上面得到的动态权重进行加权轮询调度，同时考虑在节点处放置负载调度器对响应时间的影响来判断是否放置该调度器，最后得到一个最优化调度。

在上述步骤中，推导出了动态变化的节点权重这一概念，这个概念是对比于SWRR调度算法的一个优化，来改进SWRR无法动态感知系统集群中实例的性能变化这一缺点。在Serverless边缘计算中，边缘节点、客户端网络位置是动态变化的，节点中部署的函数也会随时进行缩放。因此在SLSA中引入了动态节点权重，其好处是所有因素都将被包含在内，当某节点由于多函数共享计算资源出现性能降级时，负载调度器所观察到的该节点服务响应时间也将出现相应增加。SLSA虽然没有对这些因素进行显式建模，但这些因素会不断地通过服务响应时间的變化，隐式地通过动态变化的节点权重体现出来，同时负载调度器放置也是影响调度性能的重要因素。故本算法的关键在于确定对应动态变化的节点权重的映射方法，以及确定负载调度器放置的有效性。

算法 SLSA

输入：可用节点集合n；请求负载ω；负载调度器lc。

输出：节点动态权重；响应时间。

Function SLSA：

1 n←［］ //初始化节点集合

2 for n∈N do //遍历所有节点

3   avg_resp_time←calculate_ema（time，window_size）

4   weight←range_weight_mapping（avg_resp_time）

5   n←n.append（n，weight）

6   for n in lc do //在节点运行调度器

7    if effect（n，f）>0 //判断性能影响因子

8     lc.add（n） //保留调度器

9    else effect（n，f）<0

10    lc.remove（n）

11   end for

12  end for

13 return smooth_weight（n，ω）←response_time //返回响应时间

3.1 计算动态权重

算法首先输入了可用节点集合n，请求负载ω，负载调度器lc这三个指标。SLSA的第1行对输入的节点集合n进行初始化，第2～5行遍历所有对应的Serverless函数节点来计算节点的动态权重，并把节点动态权重放入初始节点集合n中。第3行计算了节点的平均历史响应时间，考虑到节点的性能会随时间变化，而作为性能指标，变化之后的值更为重要。为了解决这一问题，在第3行中采用了固定窗口大小的指数移动平均值（exponential moving average，EMA）这一指标。EMA在计算服务响应平均值时使用了固定窗口大小并且使用了指数衰减因子，它只需要记录上次更新的时间和当前的值，使其能确保最小的内存消耗，同时易于理解和实现，与简单的移动平均值相比，它能更快地反映响应时间的变化。给定某边缘节点先前服务响应时间平均值、最近的响应时间t、上次请求以来经过的时间Δt和窗口大小w，则更新之后的服务响应平均值′，即算法第3行的EMA具体实现可以表示为

′=e-Δtw×+（1-e-Δtw）×t（1）

根据式（1）得到平均历史响应时间。但是，单纯得到服务平均响应时间还不够，使用基于黑盒的响应时间观测方法也存在一定缺点，因为节点性能会受到潜在因素影响而显著变化。假设一个边缘服务节点n1在t1时刻由于网络原因导致在该时刻性能变差，服务响应时间比较长，但该节点n1在大部分时刻，性能都表现很好。此时，由于服务调度器总是基于平均历史响应时间决策，那将不会有任务被调度在节点n1上。这时，就出现了由于节点性能在提升后没有被及时记录而导致次优调度现象。基于此，本文在第3行得到平均历史响应时间之后，在第4行附加了边缘节点权重的动态分配策略配合动态加权轮询调度算法，使每个节点都能分配到固定的流量，让每个节点能够分配到一个权重初始值，从而对节点的性能变化及时采样，以避免次优调度问题的出现。算法第4行使用了固定范围的权重，确保每个节点都分配到初始值，每个节点的权重由最新的服务响应平均时间所决定。下面假设′∈R表示节点服务响应平均值的集合，Wmax表示最大权重，Wmin表示最小权重，则每个节点响应时间平均值的权重W（′）定义为

W（′）=maxWmin，Wmax（′min{′，′∈R}）s（2）

其中：s＞0是选定的比例因子，比例因子决定了服务平均响应时间和边缘节点权重之间的映射关系，当s=1时，表示服务平均响应时间和节点权重间存在线性关系。基于网格搜索实验，选择了Wmin=10，Wmax=30，以及s=2.0，具体网格搜索实验的选择过程将在4.2节中详细解释。

在得到上述动态变化的权重值后，可以对SWRR算法进行一个改进。SWRR算法的步骤分为两步：所有节点都有一个初始值，用它们的初始值加上设定的权重值得到当前节点集；在当前节点集中选择当前值最大的节点为命中节点，并把它的当前值减去所有节点的权重总和作为其新权重值，其他节点保持不变。因为其设定的权重值是不变的，所以在若干个周期之后，当前节点值会重新变为初始值，即一个周期，后面就会按照这个周期进行循环。通过式（2）得到的动态变化的节点权重W（′），替代了SWRR中设定的权重值，使其不再一直按照周期进行变化，可以使集群中动态变化的服务器在负载分布时更加均匀。最后，算法第5行把节点信息和对应动态权重加入到了初始创建的集合当中。

3.2 负载调度器放置

上一节描述了计算动态权重的过程，而在实际过程中，负载调度器的有效放置是影响服务响应时间的一大重要因素［16］，因此本文在算法6～11行加入了对服务调度器位置判断的一个过程，来决定调度器适合放在哪些对应节点。为了针对性地进行判断，本节提出一个问题：“在该节点运行服务调度器会对调度性能产生什么影响？”。而为了解决上述问题，提出了影响因子effect（n，f）这一概念进行判断。

当影响因子effect（n0，f）＞0时，代表预测性能比当前性能要好，调度器的放置提升了服务调度性能，则对应算法第7、8行所示，保留對应节点上的负载调度器，并把这一信息加入到集合当中；当影响因子effect（n0，f）＜0时，则正好相反，降低了性能，此时对应算法第9、10行，删除对应节点的负载调度器，并把该信息加入集合当中。最后，算法通过式（1）～（11）得到的信息，在算法第13行返回优化后的动态权重和响应时间。

4 算法仿真和分析

为了验证第3章中提出的算法，本文要对其进行全面的评估。考虑到使用小规模的边缘计算集群部署Serverless平台无法模拟边缘计算节点地理部分的特征，实验说服力不够强；另一方面，搭建实际的Serverless边缘计算网络以及大规模部署集群极其复杂且成本高。因此，本章使用仿真平台来模拟大规模的Serverless边缘计算环境。实验选取了维也纳工业大学分布式系统研究组开发的FaaS-Sim平台［17］来进行仿真，框架如图3所示。FaaS-Sim基于SimPy离散事件仿真框架，使用Ether作为网络仿真层，并创建集群配置和网络拓扑。

相对于其他仿真平台，FaaS-Sim能够模拟类似Serverless框架OpenFaaS提供的功能［18］，其包含容器、容器镜像、资源需求、缩放和调度的概念。FaaS-Sim还支持模拟大量不同类型的边缘计算设备和通过Ether更灵活地创建不同的边缘网络拓扑。默认情况下，FaaS-Sim通过Skippy调度器进行资源调度，用户可通过自定义方式替换负载调度和容器缩放策略来验证本文方案。

4.1 实验环境

在采用FaaS-Sim平台之后，使用该平台模拟了四种不同类型的边缘计算设备：

a）单片机节点：包含一些基于ARM架构的低功耗边缘接入点，如Raspberry Pi等，这些设备在IoT场景中充当边缘网关。

b）小型计算节点：包含了较低功耗的小型计算机，如Intel平台的下一代计算单元（next unit of computing，NUC）等。

c）嵌入式AI节点：包含一些具有嵌入式GPU的小型设备，如NVIDIA的Jetson系列设备。

d）边缘数据中心：包含一些通用的VM设备，可以理解为边缘网络的数据中心，称为Cloudlet。

本文所用的模拟设备的详细描述如表1所示。

4.2 网格搜索实验

在开始算法对比前，本文要对3.1节中计算的动态权重给定其中的缩放因子和权重范围的参数，因为这些参数会影响平均响应时间与调度权重之间的映射关系，最后又反作用于平均响应时间。下面通过网格搜索实验，尝试大量排列组合方法来确定其行为模式。在本次网格搜索实验中，使用Mobilenet-Inference函数作为请求的服务，针对缩放因子s和权重范围进行网格搜索。在参数设定上，本文把缩放因子s设置为［0.1，10］，权重设置为［1，100］，对于权重范围，设置最小权重为1，最大权重在［2，100］变化以全面分析权重的影响。

本次分别进行了三组网格实验，请求负载依次设置为：50 rps、250 rps、500 rps。对于每组实验，都按照不同的缩放因子与权重范围组合进行200次实验，每次实验持续600 s以收集尽可能多的服务响应时间样本。最终，通过统计服务平均响应时间（ART）作为结果来评估缩放因子和权重范围对服务响应时间性能的影响。最终结果如图4所示，从整体上看，随着请求负载的变大，图中深色区域占比不断增大，也就是说，整体服务平均响应时间随着请求负载的变大而逐渐变大。在缩放因子与权重范围过大或过小时，服务平均响应时间明显增大。而当缩放因子f在［1.0，4.0］内，权重在［10，30］内时，服务平均响应时间相对较小。在不同请求负载下，服务平均响应时间虽然存在较大差异，但在权重范围为 20 左右，缩放因子s在［1.0，3.0］内时，整体平均响应时间均达到了较优值。这表明在此范围内，服务平均响应时间能够合理地映射成相应的动态权重，从而使得调度器能够作出更准确的调度行为。

综合实验结果，本文选择Wmin=10，Wmax=30，以及缩放因子s=2.0作为最终的实验参数设置，这些参数能够使得在不同请求负载下的服务平均响应时间尽可能小。并且，这些结论在实际无服务器边缘计算应用中优化缩放因子和权重范围，从而对于提高服务性能提供了重要的参考。

4.3 算法对比测试

4.3.1 仿真场景和函数设定

为了更全面地对算法进行评估，本次实验考虑了两种地理分布范围不同的智慧城市场景，每个场景具体设定如下所示。

a）单个城市场景。边缘计算集群由3个边缘计算中心和9个共享链路带宽的分布式计算单元组成，总计150个边缘计算节点，假设所有节点位于城市A中，这意味着网络链路间延迟较小，平均延迟为5 ms。

b）多个城市场景。边缘计算集群跨越了三个城市A、B、C。每个城市之间的节点数量各不相同，计算能力有着差异。计算集群位于同一城市间的节点网络延迟较低，但跨城节点之间的网络延迟较高。客户端提交的数据会让本地节点优先处理，当本地节点性能不足或网络阻塞时，向其他城市节点提交请求任务，不同城市的具体设定如表2和3所示。

接下来是对本次实验部署的四种不同函数进行说明，在仿真集群中部署了四种函数：Resnet50-Inference［18］、Mobilenet-Inference［18］、Speech-Inference［18］、FFmpeg-Convert［19］。前三种函数函数对应典型的边缘AI推理服务，是实现边缘智能的基石，FFmpeg-Convert是实现音视频数据处理的前提，在边缘视觉中较常见，各个函数具体描述如表4所示。

4.3.2 对比算法和对比指标选择

本节对SLSA的性能进行了对比实验，用响应时间和资源消耗来进行表示，一共对比了五种调度算法，分别设置在不同的请求负载情况下进行实验。实验把请求负载设置为20 rps，30 rps，40 rps，50 rps，60 rps，并选择三种时间对比指标来进行分析。同时，实验测量了不同的负载调度策略在系统中运行时其产生的资源使用情况，来对比不同算法的资源消耗。由于实验在模拟功能时会具有随机采样特征，本文对比实验运行10次，取其平均值得出相对稳定的结果。

在调度算法的选择上，本文为了探究不同复杂度的负载平衡和负载调度器放置是否会带来总体性能的提高，选用了开源无服务器框架OpenFaas中采用的集中式轮询调度算法（round robin centralized，RRC）和较常见的集中式最小响应时间调度算法（least response time centralized，LRTC），以及对应的分布式轮询调度算法（round robin on all nodes，RRA）和分布式最小响应时间调度算法（least response time on all nodes，LRTA）。RRC和LRTC算法把所有客户端请求设置在单个集中式负载均衡器实例中，对性能要求比较高，区别是前者以循环的方式依次将请求调度不同的服务器，而后者是优先把任务调度给平均响应时间最短的服务器。RRA和LRTA算法则是相对应的分布式算法，在分布式场景中每个节点都托管了一个负载均衡器，对性能要求更低，区别是前者以循环的方式依次将节点上的任务调度给其对应的服务器，后者优先执行平均响应时间最短节点的负载均衡器。为了进一步验证SLSA的有效性，实验还需要和最新的调度算法进行性能对比。本文选择了双层动态规划（DLDP）算法［20］进行对比， DLDP算法采用多阶段渐进优化的方法，解决了考虑依赖包的函数卸载问题，且通过分阶段优化的方法将缓存策略嵌入到调度算法中，实现联合优化。

在结果对比指标上，实验选取了资源消耗（resource consumption，RC）指标对算法资源使用情况进行验证，选取了平均响应时间（average response time，ART）、平均调度时间（average scheduling time，AST）、平均函数执行时间（average function time，AFT）三个指标来对算法性能进行验证。RC是调度策略在系统运行时产生的内存消耗情况，用来反映整体的资源消耗情况。ART是服务负载请求的整体平均响应时间，其包含了网络开销、调度开销和节点函数执行时间。AST是请求调度花费的时间，其包含了请求从客户端到负载调度器以及负载调度器将请求调度至节点所花费的网络时间和调度决策时间。AFT是函数在节点上执行花费的平均时间，反映函数执行所产生的性能影响。

实验首先测试了不同算法的资源消耗情况，RC指标通过Telemd［21］進行测量。由于负载调度器是容器化的，所以Telemd依赖于Kubernetes提供的指标来测量资源消耗， Telemd每隔一段时间报告文件提供的内存消耗［21］。实验把请求速率设置为250 rps，测试时间设置为0～250 ms，把负载调度器定位在一个模拟的边缘应用程序上，客户端发送一张图像对其进行分类，有效负载是一个文件大小为250 KB的压缩图像，响应是一个大小可以忽略不计的简单JSON，通过读取Telemd返回指标，得到图5所示的五种调度算法的RC指标对比。从图5中可以明显看出，随着时间的推移，RRC、 RRA和LRTC算法对资源消耗的程度较高，LRTA、DLDP和SLSA算法相对较低。在对比算法中，SLSA调度算法对资源的使用情况最低，相比于其他调度算法，其在资源消耗上有着明显改善，特别是对于RRC和RRA，SLSA的资源消耗降低程度超过了15%。由此可以看出，SLSA相比于其他算法的资源消耗情况是有所改善的。

不同服務负载调度实验性能测试的结果如图6、7所示，分别展示了在两个不同场景下不同调度算法的性能对比。

根据图6（a）～（c）中不同指标的对比，可以得出以下结论。从ART和AFT指标来看，对图6（a）（c）进行分析，在单城市场景下，除了RRA调度算法相比于RRC算法的ART指标性能有所下降，其余调度算法均比RRC算法性能有所提升，在提升范围里，SLSA对ART和AFT两个指标的整体性能提升水平是最高的。此外，在请求负载为20 rps的情况下，LRTA调度算法的ART和AFT指标相较于SLSA性能更高，但差异并不明显；在请求负载为30 rps以及更高情况下，SLSA的ART和AFT指标性能更高，且随着请求负载的加大，性能提升更多。由此可以发现，在请求负载较低时，LRTA采用的分布式最小响应时间策略取得的性能指标会更高，但是随着请求负载的增大，因为其采用贪心的思想容易导致羊群效应，把大量的请求调度到同一个节点执行，使函数执行时间更长。所以，总体来说，SLSA在ART和AFT指标上具有更好的性能表现。

从AST指标来看，对图6（b）进行分析，在单个城市场景下， SLSA相比于RRC和RRA的AST指标性能具有明显提升。在低负载请求速率20 rps情况下，SLSA性能不如LRTC和LRTA性能；在负载请求速率30 rps及以上情况，SLSA性能超过LRTA，但是不如LRTC的性能。

对单城市场景做完分析后，实验还对多城市场景下的不同算法进行了对比，以验证SLSA在更大地理范围的环境下还存在其性能优势。图7（a）～（c）对比了在多城市场景下不同调度算法的性能对比。

如图7所示，多城市场景下，三个指标的变化规律和单城市场景类似。从ART和AFT指标来看，SLSA相比于其他算法的性能提升率比单城市场景下更大。从AST指标来看，当负载请求速率为20 rps，SLSA的性能不如LRTA和LRTC算法，但是差距很小；在负载请求速率为30 rps及以上时，SLSA在AST指标性能上优于LRTA和LRTC算法。通过以上分析，对于三种指标性能，随着地理分布和负载请求速率的增大，SLSA对比于其他算法的优势会更明显。

在比较完不同复杂度的负载平衡策略之后，本文对SLSA和最新的调度算法DLDP进行比较。SLSA和DLDP都适用于分布范围更大的场景，而AST的指标比较小，不足以体现两者算法的区别，因此本文在多城市场景下对两个算法的ART和AFT指标进行了对比，如图8所示。从ART和AFT指标来看，在20 rps和30 rps的情况下，SLSA性能不如DLDP算法，但随着请求速率的提升，SLSA的性能逐渐超过DLDP算法。由此可以发现，在低请求速率情况下，DLDP算法的性能相对更高，而随着请求速率的增大，SLSA的优势逐渐得到体现。从总体来看，SLSA的性能超过DLDP算法。

为了更直观地体现SLSA对比于其他算法的优势，表5和6对实验中得到的性能指标取平均值，把RRC算法作为基准，用百分比来表示其余算法相比于RRC算法在ART、AST、AFT三个指标性能上的提升情况。

从表5和6中可以得到，对于不同场景的ART指标，SLSA对比RRC算法提升的性能是最高的，在单个城市场景中相对于RRC算法提升了43.01%，在多城市场景中提升了53.81%。对于AST指标，在单个城市场景中，SLSA提升率为42.07%，性能提升率不如LRTA的45.78%，但随着地理分布范围的增大，可以发现SLSA性能提升率变为59.75%，超过了LRTA。从AFT指标来看，调度策略性能提升类似于ART指标，无论在单个城市场景还是多城市场景，SLSA性能提升百分比都是最大的。在单个城市场景中，SLSA性能提升率为43.25%，而在多城市场景中提升到了53.82%，SLSA性能对比其他算法有着明显提升。

综上所述，SLSA在ART和AFT指标性能的提升上均优于其他调度算法，在AST指标上，虽然在单个城市场景中不如LRTA和DLDP算法，但差异并不大，且随着地理范围的增加，AST指标性能提升也实现了反超，随着地理分布范围的增加，SLSA性能提升的优势会更加明显。

5 结束语

本文针对当前无服务器计算架构不具备在边缘场景中高效处理请求所需服务负载调度机制的问题，提出了SLSA来解决直接采用云计算中轮询调度策略而引起的函数执行时延放大问题，SLSA首先把工作过程中的服务负载调度响应时间看成黑盒，然后基于负载调度器来观察每个节点对应的平均历史响应时间，接着推导出对应动态变化的节点权重，基于得到的动态节点权重对SWRR调度算法进行改进，同时判断在节点处放置负载调度器的有效性，最后进行一个最优化调度。经仿真实验分析，在资源消耗方面，提出的SLSA相比于其他算法在资源消耗上有着明显降低；在性能对比方面，SLSA在两个不同场景下都有良好的性能表现，且随着地理位置分布和负载调度速率的增大，SLSA对比于其他调度算法的优势更明显。在后续的研究中，将会对本文算法作进一步优化，针对不同请求可能具有不同的服务质量（QoS）级别，来优化不同QoS级别的请求响应时间。

参考文献：

［1］Al-Doghman F， Moustafa N， Khalil I， et al. AI-enabled secure microservices in edge computing： opportunities and challenges［J］. IEEE Trans on Services Computing， 2022，16（2）：1485-1504.

［2］Tang Qinqin， Xie Renchao， Yu F R，et al. Decentralized computation offloading in IoT fog computing system with energy harvesting： a Dec-POMDP approach［J］. IEEE Internet of Things Journal， 2020，7（6）： 4898-4911.

［3］Jonas E， Schleier-Smith J， Sreekanti V， et al. Cloud programming simplified： a Berkeley view on Serverless computing［EB/OL］. （2019）. https：//arxiv.org/abs/1902. 03383.

［4］Li Yongkang， Lin Yanying， Wang Yang， et al. Serverless computing： state-of-the-art， challenges and opportunities［J］. IEEE Trans on Services Computing， 2022，16（2）： 1522-1539.

［5］馬泽华， 刘波， 林伟伟， 等. 无服务器平台资源调度综述［J］. 计算机科学， 2021，48（4）： 261-267. （Ma Zehua， Liu Bo， Lin Weiwei， et al. Survey of resource scheduling for Serverless platforms［J］. Computer Science， 2021，48（4）： 261-267.）

［6］Xie Renchao， Tang Qinqin， Qiao Shi， et al. When serverless computing meets edge computing： architecture， challenges， and open issues［J］. IEEE Wireless Communications， 2021，28（5）： 126-133.

［7］Cassel G A S， Rodrigues V F， Da Rosa Righi R， et al. Serverless computing for Internet of Things： a systematic literature review［J］. Future Generation Computer Systems， 2022，128： 299-316.

［8］Rausch T， Rashed A， Dustdar S. Optimized container scheduling for data-intensive Serverless edge computing［J］. Future Generation Computer Systems， 2021，114： 259-271.

［9］Cicconetti C， Conti M， Passarella A， et al. Toward distributed computing environments with Serverless solutions in edge systems［J］. IEEE Communications Magazine， 2020，58（3）： 40-46.

［10］Zhao Zichao， Zhao Rui， Xia Junjuan， et al. A novel framework of three-hierarchical offloading optimization for MEC in industrial IoT networks［J］. IEEE Trans on Industrial Informatics， 2019，16（8）： 5424-5434.

［11］Xie Renchao， Gu Dier， Tang Qinqin， et al. Workflow scheduling in Serverless edge computing for the industrial Internet of Things： a learning approach［J］. IEEE Trans on Industrial Informatics， 2023，19（7）：8242-8252.

［12］Suresh A， Somashekar G， Varadarajan A， et al. Ensure： efficient scheduling and autonomous resource management in Serverless environments［C］//Proc of IEEE International Conference on Autonomic Computing and Self-Organizing Systems. Piscataway，NJ：IEEE Press， 2020： 1-10.

［13］Ellis A. OpenFaaS-serverless functions made simple［EB/OL］. （2021）［2023-06-10］. https：//docs.openfaas.com/.

［14］Dounin M. Nginx［EB/OL］. （2023）［2023-08-07］. https：//github.com/nginx/nginx.

［15］Gao Chenhao， Wu Hengyang. An improved dynamic smooth weighted round-robin load-balancing algorithm［J］. Journal of Physics： Conference Series， 2022，2404（1）： 012047.

［16］Aumala G， Boza E， Ortiz-Avilés L， et al. Beyond load balancing： package-aware scheduling for Serverless platforms［C］//Proc of the 19th IEEE/ACM International Symposium on Cluster， Cloud and Grid Computing. Piscataway，NJ：IEEE Press， 2019： 282-291.

［17］Rausch T， Lachner C， Frangoudis P A， et al. Synthesizing plausible infrastructure configurations for evaluating edge computing systems［C］//Proc of the 3rd USENIX Workshop on Hot Topics in Edge Computing. 2020.

［18］Hannun A， Case C， Casper J， et al. Deep speech： scaling up end-to-end speech recognition［EB/OL］. （2014）.https：//arxiv.org/abs/1412.5567.

［19］Ellison R. Go-Ffmpeg［EB/OL］. （2021）［2023-06-10］. https：//github. com/rodellison/go-ffmpeg.

［20］Zheng Senjiong， Liu Bo， Lin Weiwei， et al. A package-aware sche-duling strategy for edge Serverless functions based on multi-stage optimization［J］. Future Generation Computer Systems， 2023，144： 105-116.

［21］Raith P. Telemd［EB/OL］. （2022）［2023-06-10］. https：//github. com/edgerun/telemd.