基于云边协同的物联网任务卸载策略建模与分析

韩义波，王 超，郭士加，刘盛加

(南阳理工学院 河南 南阳 473004)

1 引入

数字化时代相互联结的设备数量急剧增长，移动物联网带动全球联网设备数量在2020年突破240亿，未来在2025年对全球经济增长影响力将达到11.1万亿美元，占全球GDP的11%，这一颠覆性的时代被称为物联网(Internet of Things，IoT)时代，引起了学术界和行业界的广泛关注。目前，物联网应用面临的最大问题之一是物联网设备在硬件、网络和平台方面的异构性，且每个物联网设备通过唯一的地址与其他设备通信，需要传输、处理和存储这些设备产生的数据；再者，大多数物联网设备能量、计算能力(如CPU、内存)有限[1]，因此，支持设备数量日益增长的管理平台必不可少，以协调巨量的物联网设备并处理其产生的数据。

物联网设备具备可移动的特性，但计算能力受限。为了解决能源和性能问题，云计算和边缘计算助力物联网设备，通过任务卸载来保证物联网服务的提供。卸载将计算从资源有限的移动设备转移到资源丰富的边缘结点或云节点，以提高物联网应用的执行性能和整体能效。任务卸载已在许多领域得到应用，如运输、医疗保健、家庭和工厂等[2]。另外，任务卸载对于流处理、增强现实、在线游戏和视频会议等应用尤其有效[3]，此类应用对延迟非常敏感，需要高质量的服务和用户体验。这种场景下，将数据从终端设备传输到云中就伴随着卸载处理，并且因应用而异，如有些应用属计算资源密集性，通信量低；而有些应用通信量高，而计算资源需求低，加上终端设备的移动性特点，部分区域设备和用户数量可能猛增，这更加剧了任务卸载的复杂度[4]。

物联网工作负载牵涉大量需要实时处理与分析的跨区域数据流和控制流。目前应对此类问题的有效方法是利用网络边缘小规模访问点为云资源的补充，这些访问点位于邻近移动用户的可通信范围内，其提供PC或集群之类的小规模但资源丰富的中间设备，例如，包括Cloudlet[5]、CloudAP[6]和其他系统[7]在内的独立多层体系架构，旨在支持延迟敏感的应用程序，同时最小化总体服务时间。然而，Cloudlet与云中心缺乏集成和有效协调，服务质量无法充分保证。为此，采用编排器(Orchestrator)协助的物联网应用通过不同的编排算法改进边云环境中的智能任务卸载[8]。然而，不同的卸载架构和策略如何定量地影响物联网应用和服务的端到端性能，尤其当资源模式和任务特征的动态性表现出来时，仍然是一个未知数。

本文着重分析并实验证明两个问题：不同的边云架构如何影响任务卸载期间的整体IoT服务时间，以及不同的应用参数(如计算和通信需求)如何影响整体效率。为便于分析，将基本卸载方案分为两种不同的类型：松散耦合(Loosely-Coupled,LC)三层架构、编排器支持(Orchestrator-Enabled)三层架构；进而，考虑层间不同层间网络连接所产生的通信延迟和计算资源的分配状况，通过性能驱动建模，比较两种架构对物联网服务执行的影响；此外，考虑到不同的任务特性，提出了3种卸载策略(静态比率策略、最小加载策略和概率策略)以寻求最优编排方案。本文的主要内容总结如下：(1)统筹考虑计算、通信资源两种因素，提出一种性能驱动的端到端IoT服务有效性度量方法。(2)深入研究松散耦合和编排器支持的卸载方案的系统行为。(3)为满足不同IoT应用需求并实现最优卸载策略，提供了一套模型和算法。(4)提出不同约束条件下IoT任务卸载策略评价方法，可用于提高边云环境下任务卸载效率、实现资源均衡管理。

2 国内外研究现状

边云计算环境下的服务时间问题受到了研究界的广泛关注。关于服务时间的现有文献非常广泛，但主要集中在计算延迟、通信延迟或两者兼有，下述文献研究了服务时间与其他目标，如能耗和代价。Dinh等人[9]提出了一个框架，通过将任务卸载到多个边缘结点来最小化移动设备的计算延迟和能耗；Du等人[10]提出一种算法来保证雾或云计算系统中可接受的计算延迟；Liu等人[11]考虑排队和执行状态情况下，设计了任务调度算法用于减少整体延迟；Rodrigues等人[12]提出一种混合方法，通过加强计算和通信资源的处理来最小化端到端延迟，该方法聚焦于虚拟机的迁移和传输延迟。Wei等人[13]提出一种算法，旨在通过同时考虑传输功率和处理频率来减少延迟；Yang等人[14]提出一种通过保证最大化允许时间和降低执行代价支持延迟敏感应用的方法；Zeng等人[15]提出一种基于负载均衡和任务镜像分配的任务完成时间最小化算法。

从应用程序方面讲，边云支持的IoT应用在计算和通信需求及动态需求方面各不相同，且关于边云支持的IoT应用类型方面的文献较少。Fan和Ansari[16]特别考虑应用类型提出了一种应对计算和通信延迟的方法，该方法将卸载任务分配给边云系统中的合适资源。Roy等人[17]提出了一种基于应用具体要求选择目标边缘节点的策略，以最小化延迟和功耗。尽管上述研究是针对延迟敏感的IoT应用进行的，但在最小化整体服务时间背景下，不同边云部署策略的影响没有得到深入的研究。

虽然一些研究集中在服务时延和一些重要的应用规范上，但对于不同的边缘架构如何影响系统性能，特别是总体服务时间，仍然缺乏科学的理解。边缘计算系统的不同架构在文献中已有描述，这些架构都具备将计算资源推向近用户端的共同特点，不同主要表现在边缘结点和边缘网络中，包括部署、网络技术和边缘结点特征，如大小、位置及如何与云中心通信等，从服务提供者和应用开发者角度考虑，这些差异都是最小化整体延迟的重要因素。

3 研究场景和术语定义

为方便关键问题和目标的描述，本节简要介绍相关基本术语和概念。

3.1 IoT场景中资源与工作负载

3.1.1 边云环境中资源实体

边云环境基本实体包括终端设备(Things)、边缘结点(Edge Nodes)和云结点(Cloud Nodes)。终端设备包括传感器和带内置传感器的设备，可以监控并产生大量数据；云结点提供数据存储和并行计算能力；边缘结点定义为驻留在终端设备和云中心之间的特定设备，作为代理部署在更靠近终端设备的地方，提供计算、存储和网络资源，同时，边缘结点汇聚一系列传感器的数据并传输到本地缓存数据、执行负载均衡的中心计算系统中。从功能上看，与云数据中心的结点相比，边缘结点具有相对较小的计算能力和地理上分布的特点，其重要意义在于骨干网络访问暂时不可用情况下，也能为终端设备持续提供高准确率和低延迟网络服务。

3.1.2 IoT工作负载

完整的IoT工作负载通常由封装于独立容器内的一组IoT任务组成。所有容器运行在物理机或虚拟机之上，相互连接形成功能链以更好地满足应用需求。从形式上讲，IoT应用可用有向无环图(Direct Acyclic Graph，DAG)工作流描述，其中的每个顶点代表一个IoT任务，如图1所示的e-健康应用，该应用可分为多个独立但又联合工作的微服务[18]；具体来说，移动健康子系统具有远程监控、实时数据分析、紧急报警等功能，数据从监测病人关键体征的传感器上收集并持续发送给数据汇聚结点，一旦发现异常状态数据，医务人员可立即得到通知并采取合适的措施；更一般地说，这些独立物联网任务的合理组合可用于实现更高级的功能，从而降低成本和改善用户体验。

图1 物联网应用示例：e-健康系统工作流

3.1.3 IoT部署与任务卸载

IoT应用部署的主要目标是把每一个IoT任务放置在边云环境中合适的位置(如IoT设备、边缘结点、云结点)执行。为了比较准确地获取延迟并建模，假设每个任务具有两个主要属性：发送或接收边云系统的数据量和计算需求量(包括CPU、内存、GPU等)，也就是说，资源分配要保证所有的IoT任务有足够的资源执行其计算逻辑。同时，数据可以在不同的任务之间生成和传输。如前所述，边云组合允许在边云之间交付卸载任务和迁移数据[19]。

任务卸载主要负责将计算从资源受限的移动设备上转移到资源丰富的边缘结点或云结点上，以提高移动应用的执行性能和整体能效。用户设备均匀处于网络边缘，可通过WLAN或4G/5Gm网络将计算卸载到边缘或云结点。一般来说，若单个边缘结点资源不足于处理激增的工作负载，其他边缘结点或云结点随时可以提供协助。

3.2 研究问题和挑战

3.2.1 问题描述

采用移动设备能够更好地实现IoT服务，然而，移动设备在计算、存储、电源等方面严重受限，尤其在支持如增强现实(Augmented Reality，AR)和人工智能(Artificial Intelligence，AI)辅助的多媒体应用等资源密集型应用时。这种情况下，应用程序迫切需要低响应延迟和高带宽吞吐量，为实现这一目标，提出了不同的跨云、边云架构，以实现移动设备、边缘结点和云资源之间的协调机制。

网络边缘侧加入资源是解决协调问题的基本和普遍接受的方法，例如为了降低骨干网流量和最小化响应延迟，把计算、带宽和存储资源移近物联网终端设备。相比之下，计算密集型任务卸载到云数据中心，通过并行处理进行加速。然而，有许多因素会直接或间接影响任务卸载的有效性和效率，有必要根据相关因素对性能的影响进行量化分析和建模，并对不同的卸载策略进行比较。此外，IoT应用在计算、通信需求以及当前资源的供给上存在着固有的差异，有必要采用不同的任务卸载模式研究和评价不同IoT工作负载行为的差异，评估不同方案和不同IoT工作负载之间的关系有助于通过减少端到端服务时间，从而提高服务质量。

3.2.2 新挑战

随着IoT应用种类和数量的不断增加，出现了一些新的挑战，具体如下。

(1)规模与复杂性

随着IoT制造商开发的异构传感器和智能设备数量和种类的不断增加，再加上定制化硬件配置和个性化需求，混合云环境下选择最优资源承载IoT任务变得更加复杂。例如，一些任务只能在特定的硬件架构(ARM或Intel)或操作系统下运行，而有高安全要求的任务可能还需要特定的硬件和协议才能实现。

(2)动态性

动态性是IoT应用的主要特征之一，即其拓扑结构或多样性的资源可能会动态变化，这是因软件升级和网络对象频繁加入、离开带来的问题，会引起IoT应用内部属性和性能的变化，还存在着整体工作模式改变的可能。具体地说，通信链路可能受到带宽、连接和设备移动性波动的影响，导致云和边缘结点上不可预测的任务卸载和资源分配需求。

(3)可伸缩性

可伸缩性是挑战的另一方面，具体指处理IoT应用数量猛增和动态资源变化的能力。此外，IoT任务的属性会动态变化，因此每个任务的处理过程可能有不同的执行时间；再者，IoT设备是移动的，在某些区域IoT设备的数量可能会增加，那么连接的边缘结点工作负载将增加，因此，IoT工作负载会在边云系统上动态的变化，有可能导致服务性能的下降。

面对不断增加、动态变化的工作流，任务编排可以解决上述挑战。编排器是由云资源、边缘结点和终端用户设备等组成的集成系统，同时考虑地理分布和约束，具备正确、高效提供复杂服务的能力；更重要的是，编排器还能够自动预测、检测和解决因应用规模增大而可能出现的可伸缩性瓶颈。综上所述，边云系统基于中心资源管理器及一定的策略分配物理资源给所有IoT任务，并根据运行时系统状态卸载任务到最优目的地以明显提高应用程序性能。下文将重点考虑上述挑战，研究、分析不同的边云系统架构和环境参数如何影响任务卸载的整体有效性和效率。

4 研究方法

通常，边云系统支持的IoT应用包含3层：终端设备层、边缘层和云(数据中心)层。边缘层由大量地理上分布、通过核心网连接云层的边缘结点组成；相似的，终端用户设备直接连接边缘接点；值得注意的是，边缘节点和云节点之间的网络带宽和通信效率是导致物联网设备性能差异的主要因素之一。本研究的目标是衡量边云系统中任务卸载对IoT服务性能的影响，因此，本文分别在两种架构和3种策略中，使用端到端服务时间作为性能度量标准。

4.1 物联网边云系统主流架构

主流的物联网边云系统架构可归结为两类：松散模式和编排器支持模式(如图2所示)。

图2 两种代表性跨云IoT服务注：两图分别代表松散耦合三层模式(左)和编排支持三层模式(右)

4.1.1 松散耦合(LC)三层模式

这种架构下，IoT应用可以部署在连接的边云结点上，若移动设备没有足够的执行能力，则应用生成的任务可以调度到边缘结点执行，调度决策过程相当快，如同路由器的路由一样，因此，几乎所有情形下的卸载开销都可以忽略，这种模式被一些研究工作所采用[16-18]。显然，这种模式下，只能基于静态策略(如固定比例和时间间隔)将任务卸载到严格限制的结点中。由于用户的移动性，任务处理量的增加或减少是必然的，因此，只有在平衡的场景下，即每个节点配备性能相近的硬件、处理相似数量的终端设备等，该策略能够以更高的稳定性和可用性很好地运行。实际上，运行时移动设备的工作负载可以被卸载到仅一个目标结点顺序执行或多个服务结点并行执行。

该方案忽视了任务资源需求的多样性；缺少边云基础设施间的协作，由于采用静态分区和交付机制，一旦任务被卸载到一个结点上，便失去了根据任务的具体特点进行调整的机会。

4.1.2 编排支持(OE)三层模式

IoT应用可以部署到受边缘编排器控制的多个边云结点上，编排器是位于边缘和云中心之间的中央调度器。该方案提供灵活界面，用户可以根据上层需求或应用特点定制任务调度的优化策略。本文在编排器中引入两种实用策略：最小负载策略和概率策略，具体在4.2节中详述。

边缘编排器是一个关键组件，它管理与边云节点相关的资源，并通过将每个任务与特定资源绑定来分派IoT任务。一个高效的任务分配算法决定了任务卸载的目的地，对任务再分配的可靠性、可用性和成本效率起着决定性的作用。根据数学模型和优化方法，文献[20]将卸载算法分为5类：0-1整数线型规划、K维装箱、马尔科夫决策过程、凸优化问题和Lyapunov化问题，由于求解多维装箱问题算法具有指数级的时间复杂度，而上述算法几乎都是求解NP-hard问题。因此，需要通过考虑各种工作负载规模和类型来实现算法精度和时间复杂度之间的平衡，文献[21-23]等大量研究利用这种模式支持IoT应用。

4.1.3 比较

LC模式仅是将物联网设备与附近的边云节点连接起来，以实现任务卸载。一旦某个任务被卸载到某个特定的结点，任务不能进一步移动，即使该结点的任务队列较长。也就是说，任务没有机会利用其他理想边云结点的资源，即使该结点当前没有足够容量承载全部任务。LC机制允许任务等待执行，直至足够的有效资源被释放，或者基于静态策略将任务卸载至相应的云中心结点。显然，任务卸载是单向的，不能在不同边云基础设施间协作平衡。

相反，OE模式中的任务卸载过程更具策略性，其中优化目标可通过之前定义的规则和策略实现。这种情况下，首先生成IoT任务，然后通过移动设备发送以利用边云资源到边缘编排器，之后边缘编排器接收和路由任务，以便基于策略(如最小负载策略和概率策略)将它们分发到接近最优的边云结点上。边缘编排器处于AP(Access Points)、边缘和云之间，意味着编排器不仅能控制移动终端设备和边缘结点间的通信，而且能控制边缘结点与云中心结点间的流量；接下来，边缘编排器能够基于前述指定的卸载算法，考虑诸如资源有效性和预期延迟等不同约束，将接收到任务指定给拥有适量资源、接近最优的边缘接点。边缘编排器中的这些策略能够在运行时有效地处理动态任务卸载，并考虑实时利用率和作业特征；还提供任务划分功能，并通过多个边云结点并行运行以加速后续任务的执行；此外，各个边缘基础设施可通过编排器协同工作。

4.2 卸载策略

有效的卸载策略是可行的IoT架构的关键环节之一，它直接影响IoT系统的有效性、可靠性和稳定性等。因此，本文引入几个定制化卸载策略以满足延迟敏感IoT应用的各种需求，这些策略也可以兼容地部署到其他现有的IoT系统中。

4.2.1 静态比率策略

这种策略基于静态比率做任务卸载决策，如任务百分比和时间间隔。由于采用的卸载策略逻辑等同，OE与LC中运行的效果类似。

算法1描述了调度阈值的固定任务百分比。代码第1～3行说明了将新任务tasknew分派到特定边缘结点edgecur的条件，即边缘结点的可用资源edgecur.res能够满足任务请求tasknew.req，并且任务卸载到当前选中结点的百分比edgecur.ratio不能超过之前定义的阈值τratio；否则，任务需要卸载到云cloudentrance执行，即使边缘结点当前未被占用(第6行)。

算法1:静态比率策略要求:edgecur.ratio:已卸载到当前边缘结点任务的最新 比率条件:edgecur或cloudentrance

算法1:静态比率策略1: if edgecur.res≥tasknew.req and edgecur.ratio≤τratio2: edgecur.res←edgecur.res-tasknew.req3: tasknew.location←edgecur.address //分派任务tasknew到边缘结点edgecur4: return edgecur5: else6: tasknew.location←cloudentrance.address //卸载任务tasknew到云cloudentrance7: return cloudentrance8: end if

这种背景下，大量的IoT应用强调移动设备和边缘结点中的资源短缺问题，该策略在解决边云结点间的资源不平衡量问题发挥着有效作用，因为它保证每个资源单元处理近似相等的任务，边云节点间的任务数量和性能与硬件相当，实现资源占用的公平性。同时，该策略开销相当廉价，与原始系统相比可以忽略，因此被广泛地应用于底层基础设施。

4.2.2 最小负载策略

此策略根据运行时负载信息决定任务的分配，以便选择负载最小的结点卸载任务，同时，逻辑简单、实施可行，被大多数系统优先完全支持，非常适合于应用数量和任务执行时间都适中的中型场景。

该策略的主要过程可用算法2描述。首先，从当前边缘和云结点中全部可访问的虚拟或物理机选择最小负载的机器(第2行)，如果选中的最优机器mopt具有足够的资源满足任务需求，决策过程分派任务tasknew到机器mopt(第3～6行)；否则，从全集M(第8行)删除上述机器mopt并触发新一轮选择(第1～10行)。

算法2:最小负载策略要求:M:符合负载度量标准的所有边云结点(包括虚拟机)条件:mopt:承载最小负载的最优结点1: while tasknew.location is null do2: mopt←{m|loadm≤loadmi, mi∈M }3: if mopt.res≥tasknew.req then4: mopt.res←mopt.res-tasknew.req5: tasknew.location ←mopt .address //分派任务tasknew到机器mopt6: return mopt 7: else8: M← M-mopt9: end if10:end while

然而，该策略严重依赖高性能监视器，需要实时跟踪位于边云中整个虚拟机或物理机的负载，一旦监视器崩溃或执行能力弱，如监视数据准确性差，这种策略就不能令人满意地工作。除此之外，收集不同度量标准的运行时值时注入的过多开销也是不可接受的。因此，该策略有两个方面的严格要求：确保监控信息数据稳定传输的网络；通过调用专用硬件的硬件接口，保证以低廉的代价采集度量标准数据。

4.2.3 概率策略

该策略中，IoT任务行为可视为马尔可夫随机过程，其中一系列事件的概率仅依赖于前一事件的状态，数学公式可描述为

P(Xn+1=x|X1=x1,X2=x2,…,Xn=xn)=P(Xn+1=x|Xn=xn)

概率策略旨在根据每一对IoT任务间的条件概率优化其分配，然而，由于IoT任务的复杂性和不确定性，定义一个严格的等式来描述IoT任务的发生模型是不可行的。直观地说，基于大数定理进行P(Xn+1=x|Xn=xn)建模处理是方法之一，其中P(Xn+1=x|Xn=xn)值可通过观察值估计，如t1、t2、t3分别代表任务1、2、3，则建模过程可用任务t1后紧跟t2来近似P(t1|t2)，表示任务t2发生的条件下，任务t1的出现概率，同理，可用P(t1|t3)、P(t2|t1)、P(t2|t3)、P(t3|t1)、P(t3|t2)表示相应任务发生的条件概率。

算法3:概率策略要求:Mpt:条件概率矩阵条件:mopt:为新任务tasknew选择包括利用率、传输等成本最低的最佳结点1: Mpt←{P(ti|tj)=Countti|tjCounttj|ti,tj∈T } //根据ti|tj和tj的计数,输出由每对任务的条件概率组成的矩阵2: T′←φ 3: for all P∈Mpt do

算法3:概率策略4: T′←T′∪ {t|P(t|tasknew )≥τprobability}5: end for6: T″← T′∪ tasknew7: multilevel sorting(T″) //按照延迟敏感度、边缘结点利用、云结点利用情况及输入大小对任务排序8: for all t∈T″ do9: let mopt←null10: if t is delay-sensitive then11: mopt←edgeleast-cost //为延迟敏感性任务t分配代价最小的边缘结点12: else 13: mopt←cloudleast-cost //为非延迟敏感性任务t分配代价最小的云结点14: end if15: if t is tasknew then16: t.location←mopt.address //分派任务t到mopt结点 17: return mopt18: else19: Virtually delete allocated resources20: end if21: end for

4.3 性能评估

4.3.1 端到端服务时间

本研究将整体端到端服务时间分为独立的可测量部分。一般边云系统包括IoT设备、边缘结点和云结点(如图2)。计算(如CPU和GPU等)和通信网络带宽是两个可分配的资源类型。IoT设备相互连接，通过WAN(Wide Area Network)与边缘结点通信。通常每个地点都有一个Wi-Fi访问点覆盖，该访问点连接到相关的WLAN(Wireless Local Area Network)。移动设备一旦进入相应的Wi-Fi覆盖区域，便可持续向边缘结点发送任务请求。若某个请求被选中，通过Wi-Fi提供的访问点使用WAN和MAN(Metropolitan Area Network)将请求传输到边缘结点或云结点。由于工作负载的多样化且高度依赖于IoT任务，因此任务在功能和非功能需求方面牵涉的数据传输(上传或下载)或处理(输入或输出)可能大小不同且长度不可预测，如功能需求包括CPU核心数、功率供应、通信带宽等，非功能需求包括安全和访问控制等。

4.3.2 评测

本文假设单个任务端到端服务时间可按计算时间和通信时间的总和计算。计算时间可进一步分为任务排队时间Q和实际处理时间P。具体来说，任务排队时间由边缘节点排队、中间边缘结点排队和云节点排队组成，如Q← (Qedge，Qxedge，Qcloud)，实际处理时间用P←(Pedge，Pxedge，Pcloud)表示。同样的，通信时间由数据上传或下载的传输延迟和传播延迟组成，传输延迟是将数据推送到链路上需要的时间，传播时间是从发送者到接收者需要的时间。从上传和下载角度看，定义通信时间开销为上传时间U←(UWLAN,UMAN,UWAN)和下载时间D←(DWLAN,DMAN,DWAN)，用于描述边云3层架构中产生的总体延迟。

直观上看，边缘结点拥有相对受限的计算资源，但可以以最小的网络延迟提供网络连接。相比之下，云结点利用云资源池处理大数据，从而缩短处理时间。然而，通信时间高度依赖任务是否卸载到边缘结点、协作边缘结点或云结点进行处理，显然，卸载任务到最近的边缘结点的通信时间最小，到云计算须经历更长的通信时间。因此，若进行边云系统中的计算和通信时间建模，需要确定任务是在连接的边缘结点、邻近的协作边缘结点还是云结点中处理。以下是使用边云系统卸载任务的3种延迟模型。

(1)任务到本地边缘服务器延迟：边云系统中，卸载任务到边缘结点所需的总服务时间为发送任务数据到边缘结点、边缘结点中排队等候处理、任务处理和发送输出结果到IoT设备的时间总和。假设终端设备到本地边缘的连接在WLAN范围内，总延迟可以用公式(1)表示。

Ledge=∑UWLAN+Qedge+Pedge+DWLAN

(1)

(2)任务到协作边缘服务器延迟：在协作边缘结点中处理卸载任务的总服务时间可通过计算经WLAN上传任务数据到本地边缘服务器、经MAN上传数据到协作边缘服务器、排队、处理和经MAN、WLAN下载输出到IoT设备的时间总和得出，总延迟时间可用公式(2)表示。

Lxedge=∑UWLAN+UMAN+Qxedge+Pxedge+DMAN+DWLAN

(2)

(3)任务到云计算中心延迟：为了计算云环境中卸载任务的总服务时间，应该考虑经过WLAN、MAN、WAN的网络延迟以及排队和处理时间，总延迟时间可用公式(3)表示。

Lcloud=∑UWLAN+UMAN+UWAN+Qcloud+Pcloud+DWAN+DMAN+DWLAN

(3)

5 评测

5.1 仿真设置

实践中，由于框架的不同、移动终端设备和应用的多样性、计算服务的复杂性、通信协议的兼容性等原因，独立边云架构下做实验不是一个简单易行的过程，而EdgeCloudSim是一个灵活、实用的仿真实验平台，支持各种不同的IoT场景和边云架构，EdgeCloudSim也可通过CloudSim的适当调整而实现。EdgeCloudSim提供丰富的模型来表示某些具体的场景，如引入排队模型来描述WLAN、MAN和WAN间、移动设备间、虚拟机CPU间的不同类型延迟。因此，本论文的实验可以在仿真平台中实际完成，研究和评测LC和OE三层架构针对几种IoT工作负载和不同策略的性能。

边云环境中，有许多运行着不同应用的IoT或移动设备，这些应用由需要在边云资源中处理的不同任务组成。边缘结点分布于接近于终端设备的地方，本实验假设每个边缘结点覆盖一个特定的区域，IoT或移动设备通过WLAN连接到最近的边缘结点后，可以发送要卸载的任务，还假设有一个称为边缘编排器的结点管理着所有的边缘结点。

表1显示了仿真实验的关键参数，每种架构模式有一个云中心，连接3个分布式边缘结点，每个边缘结点处理位于其区域内一定数量的IoT终端设备。对于每一个实验，为了研究不同架构和策略下，边缘结点容量与应用端到端服务时间的关系，移动设备数量从100个增加到700个，每次增加200个。IoT设备以泊松分布方式产生许多任务(或称IoT工作负载)，因此，随着IoT设备的增多，IoT工作负载也将增加。

表1 仿真关键参数

5.2 实验方法

通常IoT工作负载对资源的依赖轻重程度是不同的，也就是说，依赖程度从低计算和通信需求(如医疗保健应用)到高计算和通信需求(在线视频游戏)变化。资源数量配置是重要的一步，下述实验步骤受文献[6]中讨论的工作负载预测的不确定性启发。

为了应对实践中可能遇到的应用程序，定义工作负载的通信带宽需求从0.25 MB到1 MB，增加步长为0.25 MB；计算需求从500 MIPS到4000 MIPS，增加步长为一倍，如表2所示。配置结果有16种不同的组合，标记为不同的应用或工作负载。符号App(x,y)表示应用需要大约xMB网络带宽、占用大约yMIPS的CPU执行。

表2 工作负载示例及中央处理单元(CPU)速度和带宽相应配置

5.3 服务时间与资源需求

本节验证了不同数量移动终端设备情形下，IoT任务所需资源(CPU和网络)如何影响整体服务时间。如图3所示，无论移动终端设备有多少，IoT应用平均服务时间随着CPU需求的增长而相应地增加，且终端设备越少，波动越明显。如当移动终端设备是100时，App(1,4k)的端到端服务时间大约是App(1,500)的4倍，而当移动设备终端等于700时，仅为App(1,500)的近2倍。直观上看，当对CPU的需求增加时，任务在CPU中的等待和处理时间也相应增加。此外，随着设备数量的增加，OE架构中服务时间的增加稍微比LC架构严重，因为当不同资源实体间有更多的IoT任务等待协调时，边缘编排器需要消耗更多的时间分配和调度。当整个CPU内核被承载的IoT任务固定和利用时，LC和OE架构间的差异将大幅扩大。

图3 不同CPU需求对服务时间的影响

相反，如图4所示，当任务的带宽需求不同时，服务时间仅稍微增加，因为本试验中网络带宽对IoT任务来说不是关键限制。换句话说，网络资源或性能明显足以处理几乎所有的IoT任务。值得注意的是，当终端设备数量接近700时，服务时间的增加比较明显，网络资源的有效分配将对服务时间和质量发挥重要作用。

图4 不同带宽需求对服务时间的影响

实际上，LC模式仅仅找到单个结点实现任务卸载，一旦任务被卸载到特定的结点上，不能进一步移动。此外，如果没有结点具备承载任务的能力，LC架构系统不得不等待更多可用资源释放，为挂起的任务腾出空间。与LC架构系统相比，此过程在OE架构系统需要较少的时间，因为OE模式能够在运行时轻松地处理动态任务卸载，并执行任务划分，进而并行卸载到多个目标结点。

综上所述，与通信需求相比，计算需求对IoT应用性能的影响更大；然而，当系统规模扩大以容纳更多的IoT设备时，通信带宽将转变成为主导性资源并成为直接影响整体性的基础因素；另一方面，对于小任务和小规模卸载场景，LC卸载方法可以顺利处理任务再分配需求；然而，当物联网任务在资源请求方面变得更大或卸载频繁发生时，编排成为不同条件约束下优化解决方案以实现最优卸载部署的必要过程。

5.4 可扩展性和可用性

本节验证两种架构和3种卸载策略下，服务时间如何随IoT设备数量变化。从图5中可以看出，当源于IoT任务的资源请求相对较小时(如App(0.25,500))，即使在不同架构和策略下，整体服务时间对终端设备数量的增加也不敏感。原因是在卸载过程对整体服务时间影响不大的情况下，无论卸载的最终目标结点在哪里，边云结点的当前资源都足以处理这些被卸载的轻量任务。

图5 不同卸载策略下不同应用特征的服务时间

边缘编排器通过考虑IoT任务具体特征，能够基于定义的策略有效地为到来的任务寻找卸载结点；相比之下，对于有最大资源请求的App(1,4k)，不管是LC还是OE，服务时间都会伴随终端设备数量的增加而急剧增加。显然，OE架构中的边缘编排器需要花费稍长的时间协调边云结点之间的资源，并随之做出任务部署决策，比较App(1,500) 和App(1,4k)时，可以观察到与图5类似的现象。上述分析表明，不同的应用对设备规模具有不同的敏感性，IoT服务提供者需要根据IoT应用的边云基础设施配置的变化协调和指定合适的资源。

卸载策略作为核心阶段，对任务卸载整体性能起着至关重要的影响。如图6所示，采用概率策略的服务时间波动明显，但大致徘徊在最小负载策略附近，有时介于静态策略和最小负载策略之间。这种趋势表明概率策略的稳定性比最小负载策略的稳定性要弱，在任务调度方面还需进一步改进。

图6 超参数调整

最小负载策略完全依赖于运行时的负载信息，因此执行稳定、有效。CPU负载是任务执行的最关键指标之一，因此，该策略为什么能在端到端的服务时间中表现出优势是可以理解的。相比之下，概率策略需要根据过去事件的发生率求解后续任务的发生概率，并为可能到来的工作负载引入资源预留方式。因此，这种方法导致任务调度时，当前任务的部署不是最优或接近最优的，更不幸的是，如果下一个任务的预测是错误的，那么资源预留就成为一种资源浪费。

总之，随着终端设备数量的增加和IoT任务资源需求的提高，OE架构变得越来越有效和高效，卸载策略开始为任务调度做出更多的贡献；LC架构(包括静态比率策略)更适合于简单的IoT场景，其中IoT设备数量相对较少；然而，当资源请求变得更大(如App(1,4k)或更大)，LC架构忽略边云结点当前状态和IoT任务的个体需求，会因任务卸载到单个结点的静态过程而增加时间消耗，只有考虑复杂约束的边缘编排，即OE架构，才有助于解决此问题。

6 研究局限性与展望

对于一个给定的IoT应用需求，研究如何自主决定最优部署机制是未来的一个研究方向。首先，本文仅研究了独立任务的卸载策略，然而，任务依赖性是影响任务卸载决策的重要因素，因此，需拓展考虑调度卸载任务过程中的任务依赖；其次，为了最小化服务时间，从任务的数量、用户移动性等方面预测延迟敏感性应用的行为，进而有利于资源管理器提前准备所需资源，避免任何方面的性能下降；最后，为处理基于CPU速度和带宽的IoT延迟敏感应用的不同需求，本文考虑了3种定制的卸载策略，由于大量AR/VR及视频游戏需要密集性计算，为了在边云环境中处理该类任务，需扩展考虑GPU和FPGA等计算资源。

7 结论

IoT时代，边缘计算非常适合优化和保障实时应用程序性能。本文旨在利用高效的协调机制和任务卸载算法，使得移动设备和边云能够协同工作。基于延迟模型和性能评测揭示IoT应用程序的内在本质和性能干扰的根源。分析了当IoT设备数量和请求资源变化时，不同架构方案和卸载策略对IoT应用性能的影响，并检验了它们的有效性。IoT应用程序的所有者可从本研究中理解应用程序如何在不同的IoT部署方案下执行，并根据给定的具体应用场景选择合适的架构方案和卸载策略以提高应用程序性能。