雾计算中服务放置问题综述

雾计算和边缘计算中服务放置问题综述

1 引言

近年来，物联网 (IoT) 通过将可穿戴设备、交通、增强现实等日常生活中的物品转变为通信设备，已深入融入我们的社会，从而带来了新的挑战和机遇。思科指出，到2020年，联网设备将超过500亿台，显然当前的基础设施将无法支持所有产生的数据。事实上，当前的云基础设施本身无法支持大量现有的物联网应用，主要原因有三个：第一，所产生的海量数据由于带宽限制、处理开销和传输成本，使其从生成地（终端设备）传输到处理地 （云服务器）变得不切实际。第二，显著的端到端

从终端设备到云服务器的延迟通常由于云服务器距离终端用户过远，可能会削弱需要实时分析的应用程序（如线上游戏、视频应用程序等）的性能。最后，某些数据在隐秘性和安全性方面可能存在影响，此类数据穿越整个互联网可能是不被建议甚至被禁止的[2]。

为了应对这些问题，已确定了一种有前景的范式，能够避免网络瓶颈、克服通信开销，并减少数据传输延迟[3]。这种结合了云的优势和在边缘设备上进行服务去中心化处理的新概念方法被称为雾计算或边缘计算[3]。目前学术界尚未对这些术语形成明确的定义[4–7]。

下文中，为简便起见，我们使用术语雾计算。

雾计算 [8]将云计算和服务扩展到网络边缘，使处理、分析和存储更接近请求的生成和使用位置。其目标是减少发送到云的数据量，并降低延迟和计算成本。作为一种新兴范式，雾计算带来了新旧挑战，其中主要的开放问题之一是服务管理，更确切地说是服务放置问题。事实上，“如何在可用的雾节点上高效部署服务”是阻碍雾计算采用的主要障碍之一。与云数据中心不同，雾设备具有地理上分布、资源受限以及高度动态的特点，这使得该问题极具挑战性。因此，为物联网应用定义一种高效、有效且公平的资源供给机制，对于向终端用户提供端到端保障服务至关重要。此外，根据具体场景和关注点的不同，可能需要重点关注不同的方面：资源利用率 [9],服务质量（QoS）[10–12],体验质量（ QoE）[13],等。近年来，已有大量研究工作致力于解决这一问题。研究人员提出了不同的假设、特征和策略，以实现高效的服务放置。本文综述了在雾环境中针对该问题开展的广泛研究工作，并探讨了文献中提出的方法论和策略。需要强调的是，本综述不仅限于描述文献中的主要方法。首先，我们基于用户期望、问题描述和部署目标，识别出五种主要场景。其次，我们提出了一种新的 分类体系，对服务放置问题（SPP）的各种变体以及研究社区提出的各类解决方案进行归类。所考虑的方面包括：问题陈述、放置特性、技术建模、问题目标、优化策略以及实验工具。

本文组织如下：第二节总结了关于雾计算及该相关领域资源管理的现有综述和教程，并突出了本文的贡献。第三节概述了雾计算系统：定义、架构、主要特性和优势。第四节介绍了服务放置问题，并总结了文献中提出的常见建模方法、优化策略、主要设计目标和评估工具，以解决此问题。SPP方法的分类在第五节中给出。第六节概述了开放性挑战，并强调了新兴出现的研究方向。最后，第七节对本综述进行总结。

2 现有综述

有几项综述探讨了雾计算及其相关挑战的不同方面[4, 7, 8, 14–25]。事实上，已有不同的研究工作提出了对雾计算概念及其作用的讨论[4, 14, 16, 17, 26–29]。例如，Bonomi 等人[14]研究了雾计算在物联网领域的角色、其特性以及应用程序。Saharan 和 Vaquero 等人 [26]从使能技术和新兴趋势的角度概述了该概念。张和蒋[4]在物联网背景下讨论了对新架构的需求

计算和存储。在参考文献[16],中，作者给出了雾计算及相关概念的定义，并提出了三个推动性应用程序：增强现实、内容分发和移动数据分析。许多其他论文讨论了雾计算的特性、应用领域以及相关研究挑战，例如参考文献[27–29],然而，它们并未研究和讨论在这种地理分布广泛且规模庞大的环境中的服务放置问题。事实上，这些研究并未提供关于物联网应用程序如何在网络中部署的见解（例如应用需求、基础设施特性、领域约束、映射策略、优化指标等）。

最近的综述试图填补资源管理和服务放置问题方面的空白。其中，我们引用了尤塞福普尔等人[24],的工作，该工作提供了关于雾计算的教程，比较了雾与其他相关计算范式，并讨论了雾环境中的资源管理以及服务部署（编排与迁移）。在参考文献[19],中，作者提出了雾计算的分类法、相关挑战和特征，并简要讨论了服务管理问题。Nath 等人[30]还提出应对现有服务放置问题提案进行综述。他们追求三个主目标：详细阐述当前算法、可用原型和实验；根据应用程序和雾基础设施特性对相关研究进行分类；识别并讨论一些开放性挑战。

尽管这些综述探讨了雾/边缘计算中的资源管理和服务放置问题，但我们注意到这些工作至少在以下一个方面存在局限性：（1）对雾/边缘计算中服务放置问题（SPP）的回顾和讨论有限；（2）缺乏对问题的全面描述，以及关于问题分类、解决方法、评估环境和具体研究方向的最新研究成果；（3）未对现有工作提供深入的比较、分类或一些有用见解 （例如，如何评估或比较不同方案）。

我们的文章在内容和研究问题上有所不同。本文主要致力于实现对雾环境中服务放置问题的全面且非常清晰的概述，该综述旨在简化用户对参考文献的获取，并识别出一系列挑战。本文的特点体现在以下贡献中。

2.1 我们的贡献

我们文章的主要贡献可以总结如下： （1）全面且清晰地描述和概述雾环境中的服务放置问题（SPP）。（2）针对大规模、地理分布式和异构系统领域的问题，提出其分类法。（3）基于已识别的场景、所提出的分类法以及优化策略，对调研工作进行分类。（4）最后，强调开放性挑战，并讨论未来的研究方向。

3 雾计算概述

在本节中，我们将简要介绍雾计算：定义、架构、主要特征和优势。

3.1 定义

雾计算（FC）是一种高度虚拟化的平台，可在终端用户和云服务器之间提供计算资源、存储和控制。该技术由思科在 2012[14],提出的雾计算（FC）是一种新范式，其中集中式云与分布式边缘节点共存，局部和全局分析在边缘设备上执行或转发至云。

3.2 架构

已为雾计算（FC）提出了多种架构。这些架构大多源自基本的三层结构（如图1所示），雾基础设施由IoT设备（终端层）、一层或多层雾节点以及至少一个云数据中心（云层）组成。

• 终端层 ：最底层且最接近终端用户的层次。它由各种物联网设备（例如，摄像头、手机、智能汽车、烟雾探测器）组成。这些设备地理上分布广泛，能够感知事件并将 其转发至层级结构中的上一层进行分析和存储。
• 雾层 ：中间层，由一组能够处理和存储接收请求的设备组成。这些设备被称为雾节点 （FNs），包括接入点、路由器、网关、交换机、基站、笔记本电脑、特定雾服务器等，连接到云服务器并能够向数据中心发送请求。这些资源分布在终端用户和数据中心之间，可以是某个位置的固定设备（静态）或移动的（如智能手机、车辆、智能交通系统、无人机）。
• 云层 ：此架构中的最上层。它由多个服务器和数据中心（DCs）组成，能够执行复杂分析并存储大量数据。

3.3 架构特征和优势

作为云系统和物联网的未来，雾计算具有许多特性和优势；主要特性与优势如下所述：

(1) 位置感知和低延迟 。大多数对延迟敏感的应用程序，如增强现实、游戏或视频流，需要亚秒级处理时间，并不一定需要通过长距离路由发送到数据中心或云服务进行处理。借助雾计算（FC），通过在不同位置部署的雾节点的地理分布及其与终端用户的接近度，能够有效支持这些需求。Sarkar 和 Misra [33]通过理论建模证明，雾计算中的服务延迟明显低于云计算。

(2) 节省带宽 。雾计算（FC）通过在本地执行部分计算任务，并仅将部分有用数据或需要深度分析的数据发送到云，有助于缓解网络拥堵并加快某些任务的处理速度。

(3) 可扩展性 。连接设备的数量快速增长，由这些万亿级设备生成的物联网数据和应用程序也呈指数级增长。面对如此大量的数据，在云中处理整个物联网应用程序既不高效也不可行，因此雾作为能够支持所有这些请求并帮助此类系统实现可扩展性的补充范式介入。[34]

(4) 支持移动性 。由于雾计算拥有广泛分布的雾设备，可通过网络提供计算和存储能力，因此相较于传统的集中式云服务器，更适合支持终端用户移动性，从而能够在不中断的情况下为移动终端用户提供服务保障。

4 雾计算中的服务放置

服务放置问题在文献中已被广泛讨论，并出现了多种方案。基于不同的应用场景描述、网络假设和预期结果，这些解决方案通常难以相互比较。在本节中，我们提出描述解决服务放置问题通常采用的方法论，并概述以下方面：问题描述、放置分类、优化策略和评估工具（如图二所示）。这些要素将使我们能够清晰地描述该问题，并定义调研工作的比较与分类所依据的不同方面。

4.1 问题描述

服务放置问题（SPP）的描述包含以下三个部分：基础设施模型、应用程序模型，以及与其相关约束的部署模式。

4.1.1 基础设施模型

物理雾基础设施（见图1）分别由一组无计算能力的设备（传感器和执行器）以及一组具备计算能力 和/或存储容量的资源（雾节点和云数据中心）组成。

由于其物理结构，[35],雾节点在资源上受限且彼此异构。任何配备有计算资源（以中央处理器、内存、存储、带宽衡量）的设备都可以被视为潜在的雾节点，例如路由器、小型服务器、接入点、笔记本电脑、网关等。

基础设施网络通常被抽象为一个连通图，其中顶点表示物联网设备、雾节点和云服务器的集合，边表示节点之间的链路。下文将提及文献中描述雾基础设施时最常见的资源类型和特征。

• 资源类型 。计算：服务器、个人计算机、云簇 [36, 37],等等。 网络：网关、路由器、交换机、基站，等等。 存储：任何能够提供存储的节点。移动：车辆、智能手机，等等。 终端抽象：传感器、执行器（例如 GPS 设备、无线传感器、摄像头、语音采集器、雷达）。
• 特性 。计算：CPU性能、核心数、内存、电池寿命等。网络：类型：无线、有线； 能力：延迟、带宽、误码率等。存储：磁盘等。 虚拟化：虚拟机、容器、单内核等。硬件：GPU、 NUMA、 FPGA等。

4.1.2 应用程序模型

在文献中，使用了多种抽象和模型定义来描述由 IoT设备生成并在雾计算资源和云服务器上处理的应用程序。根据所调研的论文，我们识别出以下主要描述：(a)单体式服务， (b)一组相互依赖的组件，以及 (c)连通图。

(a) 单体式服务 。由终端用户或IoT设备发送的应用程序以单个组件（单体式服务）的形式表示。例如，可以提到一个图像处理应用程序或数据实例，需要在单个物理节点上进行处理或存储。在这种情况下，该应用程序可被定义为单体式服务。

(b) 相互依赖的服务集 。这种情况假设应用程序已被预先划分为一组组件（服务），每个组件在 应用程序中执行某些特定操作（功能）。在这种情况下，不考虑应用程序组件之间的依赖关系。

(c) 一个连通图 。在这种情况下，应用程序由一组表示为连通图的相互依赖组件组成。顶点表示应用程序的处理/计算组件，边表示节点之间的相互依赖关系和通信需求[38]。图的不同拓扑结构可以被识别，其中包括：线图、树形应用图和有向无环图（DAG）。其中最常使用的是DAG应用拓扑，因为它能够建模大量实际的物联网应用，例如视频处理 [39–41],游戏 [42],和医疗保健 [43]应用程序。图3（a）展示了一个DAG应用（认知辅助应用）的示例。

关于应用需求，我们可以将其总结如下：计算：CPU性能、核心数、内存等。网络相关：带宽、延迟、误码率、抖动（每条链路、端到端）。任务相关：截止时间。位置相关：应用程序

必须在特定的地理位置运行（例如，巴黎）；该应用程序只能在某些雾节点上运行，等等。

4.1.3 部署模式

应用程序放置问题定义了一种映射模式，通过该模式将应用程序的组件和链路映射到基础设施图（即计算设备和物理边）上。图3展示了一个以有向无环图建模的应用程序（图3（a））映射到可用的雾节点（图3（b））的示例。

通常，应用程序放置涉及在网络（节点和链路）中找到满足应用程序需求、满足约束条件并优化目标（如果有）的可用资源。例如，满足应用程序（服务）的需求，不超过资源容量，满足局部性约束，最小化消耗的能量等。服务提供商必须考虑这些约束，以首先限制搜索空间，其次提供最优或近似最优放置。我们接下来将描述文献中最常考虑的一些约束。

• 资源约束（CR） 。基础设施节点在中央处理器、内存、存储、带宽等方面的能力是有限的。因此，在部署应用程序（服务组件）时，必须满足资源需求，即确保部署在基础设施节点上的组件资源不超过其能力。
• 网络约束（CN） 。网络链路也可能受到延迟、带宽等约束的限制，这些约束在部署应用程序时需要得到满足。
• 应用程序约束 ：我们在此强调两类应用程序约束：
  • 局部性需求（CL） 。局部性需求通常将某些服务的执行限制在特定位置。由于特定硬件、隐私要求或给定策略，某些组件可能被限制只能部署在特定区域（区域）或设备上。局部性约束可以基于：一组雾节点[45, 46]；使用全球定位系统等特定地理空间位置[33],要求组件共址[47],等等。
  • 延迟敏感性（CD） 。某些应用程序可为处理操作或在整个网络中部署整个应用程序指定截止时间。该约束通常通过定义一个不可超过的阈值来表示。

4.2 服务放置分类法

解决服务放置问题在设计部署策略时需要考虑一些特定性和标准。本文将其称为服务放置分类法，建议关注以下四个方面，如图4所示：

因此，第一个特性考虑映射协调是采用集中式还是分布式方式进行。第二个特性基于问题是作为离线部署还是在线部署来解决。第三个特性建议观察系统的动态性是否被处理 （即是否应对系统中的变化）。最后，第四个特性描述所提供的解决方案是否支持终端用户的移动性和/或雾设备的移动性。

以下描述的这八个特征将在第5.1节中用于对来自文献的服务放置问题提案进行分类。

4.2.1 控制平面设计：集中式与分布式

放置策略和服务管理的开发首先需要选择采用的协调策略。本文介绍了两种常见的控制平面模型：集中式和分布式协调。这些方法适用于多层和地理分布系统，彼此差异较大，各自具有优势和不足，如下所述：

(a) 集中式 。集中式控制平面需要有关应用程序需求和基础设施资源的全局信息，以制定并分发全局部署决策。集中式放置算法的优势在于有可能找到全局最优解；然而，它们在可扩展性和计算复杂性方面存在脆弱性。

在调研论文时，我们注意到大量研究在解决服务放置问题时考虑了集中式控制平面。在这些研究中，我们提到了洪等人的工作。[48],该研究考虑通过一个中央协调器来对物联网应用程序在雾基础设施上的部署决策进行管理。

(b) 分布式 。与集中式解决方案不同，分布式方法采用多个授权与编排节点来控制服务映射。这些管理单元通常分布在网络中（如图 5 所示），基于本地资源和信息进行部署决策的计算。该控制平面更加灵活，能够更高效地应对雾计算等基础设施的动态变化，而无需进行全网计算。分布式方法有助于解决可扩展性和位置感知问题，并支持提供最符合本地上下文的服务；然而，无法保证所生成解决方案的全局最优性。

在考虑分布式控制平面的研究中，我们引用了Wang等人[49]的工作，该工作考虑了一种基于雾的架构，由雾节点和雾节点协调组成。雾节点子层负责需要实时处理的任务。那些需要更强计算能力的复杂任务则被传输到雾节点协调子层或转发至云。

4.2.2 离线与在线放置

服务放置问题可以通过离线或在线方式解决。更准确地说，如果在编译时做出部署决策，并且所有所需信息都已知，则称该放置为离线放置。它需要关于系统活动的完整信息，并提供满足给定需求的解决方案。对于在线放置，部署决策是在系统的运行时做出的，决策依据包括处理特性以及系统的当前状态。在大多数实际用例中，服务放置问题必须作为在线问题来处理。也就是说，相关算法必须在服务到达时进行处理，而不是在执行前预先计算放置方案。我们注意到，在线放置能够适应系统的动态行为（变化），但无法充分利用系统资源（无法提供最优的部署决策）。

作为文献中提供的离线放置算法的一个示例，我们提及参考文献[12, 50],其假设对雾网络具有完整的知识信息。对于在线放置，例如李等人的工作[51],提出了一种在线放置策略，在可用雾节点不确定的情况下最小化雾系统的计算延迟。该提供的在线优化框架建议顺序地观测网络中的信息。

4.2.3 静态与动态放置

该准则涉及方案是否处理系统的动态性。我们可以分别识别出两个方面：雾基础设施的动态性和应用程序的动态性。雾网络具有高度动态性，其中实体可能由于网络链路不稳定或故障而加入或离开网络。资源能力也可能随时间变化。从应用程序的角度来看，应用图结构可能随着时间推移而演变，以响应现实条件的变化。新的数据源或设备可能出现，或者已有设备可能消失（例如增加新的摄像头、某些组件发生故障、用户可随时决定开始或停止为某项服务发送数据等）。此外，还可以观察到应用程序信息的变化（例如数据量、组件需求等）。

为了应对雾基础设施和/或应用程序的动态特性，需要定义能够确定何时需要进行适应、提供透明机制并满足服务质量要求的响应式策略。因此，如果所提供的放置策略能够部署新服务，并替换或释放已部署的服务以满足服务质量约束并优化特定目标（如果存在），则称该方法为动态的。

通过查阅文献，我们发现了一些致力于管理雾环境动态特性的研究工作。其中包括 Yousefpour等人[52],的研究。

提出了一种在雾基础设施中动态提供服务的方法，该方法满足服务质量要求和服务等级协议（SLA），并最小化资源成本。为了应对物联网应用的动态性，马哈茂德等人[35]提出了一项策略，能够动态确定已部署组件的主机节点，并处理接收服务频率的突发变化。

4.2.4 移动性支持

管理移动性是雾计算中的一个主要挑战。提供一种支持终端用户和/或雾设备移动性，并确保用户始终不间断地获得相关服务和期望性能的解决方案，在雾计算中是一个复杂的问题。终端节点（或雾节点，例如智能手机、智能汽车）位置的频繁变化可能导致过度的延迟或丢包。在这种情况下，系统管理员（协调器）应能够将服务从先前的设备透明地迁移到新设备，以确保服务的连续性。

在参考文献 [49, 53–60],中，例如，作者试图通过提供动态放置方法来解决终端用户移动性问题。在参考文献 [59],中，索雷兹等人提出通过以下策略来处理终端用户移动性： “何时迁移”，基于延迟参数；以及“迁移到何处”，基于雾节点与移动设备的接近度以及当前处理节点。

4.3 优化策略

在雾基础设施中优化服务放置问题已从多个不同目标出发，采用不同的问题建模方法和多样的算法方案进行研究。本节讨论此类系统中可能追求的目标、用于评估部署效果的指标、现有方案所采用的问题建模方法、求解策略以及用于解决服务放置问题的算法。

4.3.1 优化目标和指标

我们首先对文献中提出的优化策略进行全局分类。一方面，我们区分了以下两类：单目标和多目标优化。另一方面，我们介绍了优化过程中最常考虑的指标。

(a) 单目标与多目标优化 。单目标优化旨在优化单一目标函数，而多目标优化则旨在同时优化一组目标函数[61]。关于这两种优化方法的SPP解决方案分类见表二。对两个方面（单目标和多目标）均进行研究的工作用星号（*）标记。

(b) 优化指标 。我们在此列出文献中通常考虑的优化指标，这些指标与前述研究工作相关（见表2）。优化的目标可以是最大化或最小化以下指标的值：

• 延迟 。延迟敏感型应用的低延迟需求。在多篇被调研的论文中，实现更低的延迟已引起关注。事实上，许多研究工作旨在最小化服务延迟

在满足一系列需求和约束的前提下，在可用资源上部署服务。例如，在参考文献[102, 103],中，作者提出通过在物联网‐雾‐云框架上部署物联网应用来最小化服务延迟。

• 资源利用率 。在雾计算中，一个重要的问题是，在适当的雾节点上部署尽可能多的服务的同时，如何优化资源利用率。在文献中研究这一目标的工作中，我们可以引用洪等人的工作 [48],，该工作在最大化满足的物联网分析请求数量的同时提供部署决策。斯卡尔拉特等人在参考文献 [94]中也提出通过优先处理最近截止时间的应用程序来最大化满足的应用请求数量。

• Cost 。从服务提供商或用户的视角来看，与成本相关的因素在雾服务管理中变得非常重要。我们可以确定两种主要的成本类型：用于数据传输费用及相关支出的网络成本；以及与雾节点计算开销相关的执行成本。此外，还可以识别其他费用：与存储、部署、安全防护、迁移等相关的成本。

在参考文献 [52],中，作者提出最小化总成本，该成本包括云和雾中的处理与存储成本、雾与云之间以及雾节点之间的通信成本，以及从雾服务控制器到雾节点的服务部署通信成本。

• 能耗 。能效是物联网系统中的主要关注点之一，也是许多研究在雾环境中试图探讨的重要性能指标。能耗主要包括两个方面：待处理的服务类型，以及服务级别的能耗，后者包含三个主要方面：服务由终端用户发送到雾设备时的能耗；服务由雾节点处理时的能耗；以及雾需要云时的能耗。例如，萨卡尔等人[21, 33]和西尾等人[50]通过考虑网络和设备侧的能耗，研究了雾环境中的能耗问题。

• 其他指标 。在解决服务放置问题时，可以考虑其他一些指标。这些指标包括用户体验质量、拥塞率、阻塞概率、失败请求等。QoE 被视为以用户为中心的度量，涵盖了在部署服务时用户的需求、感知和意图[122]。作为一个示例研究，我们提到马哈茂德等人所做的工作[13]，该工作提出了一种基于用户体验质量的应用程序放置策略，该策略优先考虑用户期望。关于拥塞

比率，Yu 等人 [46]提出考虑链路流量与容量之间的最小比率，以解决物联网中实时处理应用程序的服务放置和数据路由问题。

4.3.2 技术配方

服务放置问题通常通过以下两个主要类别之一进行形式化：整数规划或约束优化。表3根据下面简要描述的已识别问题建模，对调研工作进行了分类。

(a) 整数规划 。一类包含数学优化问题的类别，其中部分或全部变量为整数。我们有不同的整数规划方法，以下列出主要的几种。

• 整数线性规划（ILP） 。这类问题表示在整数变量上对一组线性约束下的线性函数进行优化。一些研究，如参考文献 [10, 76, 90, 94, 117],使用整数线性规划来表述放置问题。
• 整数非线性规划（INLP） 。整数非线性规划是一种包含非线性约束的整数线性规划。例如，在参考文献[52],中，尤塞福普尔等人将动态雾服务供给问题建模为一个整数非线性规划（INLP）。
• 混合整数线性规划（MILP）/混合整数非线性规划（MINLP） 。一类被称为混合整数规划问题的问题假设某些决策变量不是离散的。在参考文献 [64],中，为了研究边缘云中的延迟敏感服务管理，作者将该问题建模为一个最小化失败请求数量的混合整数线性规划（MILP）。混合整数非线性规划（MINLP）考虑了连续和离散变量以及非线性目标函数和/或约束。由于求解此类问题具有较高的计算复杂度，大多数研究提出将其线性化为混合整数线性规划（MILP）。例如，在研究雾架构中的成本高效的服务部署问题时， Arkian 等人 [40]首先将成本最小化问题建模为一个混合整数非线性规划（MINLP），然后将其线性化为混合整数线性规划（MILP），以便更易于求解。
• 混合整数二次规划（MIQP） 。该问题指具有关于整数和连续变量的二次目标函数，以及关于两类变量的线性约束的优化问题。例如，在参考文献 [46],中，作者将物联网中实时处理应用程序资源供给问题建模为一个混合整数二次规划（MIQP）。为了克服求解此类问题的高复杂度，作者提出放松部分约束，并提出一种近似方案。

(b) 约束优化 。约束优化是一组方法，旨在存在某些限制（约束）的情况下，找出特定变量的最佳可能值（即优化过程）。它使用一组约束，这些约束可以很容易地进一步扩展以涉及更多方面。

例如，在参考文献 [125], Ait‐Salaht 等人提出通过提供一种通用且易于升级的约束编程模型来解决服务放置问题（SPP）。Brogi 等人 [11, 126]提出了一种约束模型，以确定应用程序在雾基础设施中可行的部署方案（如果存在的话）。

(c) 其他技术建模方法 。正如文献中发现的其他建模方法，我们引用：匹配博弈 [131],马尔可夫决策过程（MDP） [132],随机优化 [133], Petri网[134],势博弈 [135],二次分配问题 [136],和广义凸优化[137]。

例如，在参考文献[71],中，采用匹配博弈来构建移动边缘计算系统中的任务放置问题，同时最小化计算延迟。在参考文献[57],中，Urgaonkar 等人将迁移问题建模为 MDP（也称为强化学习）。在参考文献[120],中，作者使用带价定时Petri网（PTPNs）研究雾计算中的服务放置，同时优化完成任务的价格和时间成本。

4.3.3 求解策略

在雾基础设施中计算最优应用调度是一个NP难问题[138–140]。实际上，多个因素使得在此类环境中有效进行服务放置的计算变得复杂：首先，大多数雾节点的异构性和有限容量（资源受限）；其次，环境的动态性，资源可能会出现或消失，其他资源可能在移动，基础设施和应用程序信息可能随时间变化（例如工作负载的变化）；第三，雾设备在大规模基础设施中的地理分布。多种特性和约束使得雾环境中的服务放置问题（SPP）成为一个具有挑战性的任务。在文献中，我们识别出用于解决此类问题的四种主要方法：精确求解、近似策略以及启发式或元启发式方法。我们将在下文简要描述这些方法：

(a) 精确解 。精确解的定义通常是通过使用ILP求解器或执行穷尽搜索（枚举所有解）来计算的。在尝试以精确方式解决服务放置问题的研究中，我们提到参考文献 [58, 60, 87, 94, 97],采用了ILP建模和精确优化求解器来确定最优解，以及参考文献[105],采用了穷尽放置搜索。

然而，需要注意的是，进行精确求解在获得最优解之前需要较长的处理时间，并且仅适用于小规模问题实例。实际上，寻找精确解可能极其耗时，不适合大规模问题，例如雾环境。因此，研究社区的主要工作重点在于提供有效的近似、启发式方法或元启发式方法，以在较短时间内计算出次优解。

（b） 近似 。近似技术用于计算具有可证明的与最优解距离保证的解。近似是高效的算法，可用于计算NP难优化问题的次优解。例如，在参考文献 [46],中，作者提出使用全部多项式时间近似算法来解决IoT应用部署问题。该方法能够在相对较短的时间内计算出服务放置问题的次优解及其边界。

(c) 启发式方法 。由于雾计算基础设施的规模及其动态性和移动性特点，使得精确分析几乎无法适用，因此通常会研究启发式方法。启发式方法旨在在合理的时间范围内获得解决方案，它是一组规则和方法，旨在为给定问题找到可行解。然而，基于启发式方法的解决方案不提供性能保证。例如，Brogi 等人 在参考文献[11, 126]中使用了“先失败/后失败”启发式方法。这些研究中的作者提出采用这两种策略，以在相对较短的时间内确定应用程序在雾计算（FC）中的可行部署方案。“先失败”启发式用于选择兼容节点较少的未部署组件。“后失败”策略则根据软件组件所需的终端设备数量及其硬件能力，按降序对候选节点进行排序。为了确保所有请求都能被满足，这些启发式方法会基于空间接近性和支持请求的最强大设备来计算最佳资源。

(d) 元启发式方法 。通常受自然启发，元启发式方法旨在通过迭代改进结果质量，并在合理时间内帮助搜索过程逃离局部最优解（而启发式方法可能陷入局部最优）。文献中提出了多种元启发式算法，例如遗传算法 [141],蚁群优化 [142],粒子群优化 [143],和禁忌搜索 [144]。这些算法基于种群演化，在每一次演化中，当前找到的最佳种群（解）被保留至下一轮演化，最终根据给定的目标（指标）确定最优解。例如，斯卡尔拉特等人[94],的研究采用遗传算法（GA）来解决雾计算（FC）中的服务放置问题（SPP）。GA [145]是一种进化算法，模拟染色体的自然演化过程。在他们的研究中，作者假设染色体中的每个基因表示一个服务部署决策，放置方案根据基于激励原则的适应度函数进行迭代优化。

4.4 评估环境

为了评估其方案的性能，研究社区使用不同的编程工具进行大量实验，并在相关环境中 （最好是在真实环境中）测试其解决方案。下面我们描述了被调查论文中最常用的工具。表 4 总结了文献中采用的编程环境。

4.4.1 分析工具

分析工具 是用于计算和评估所提出策略性能的常用方法之一。最常提到的工具有：Java [11, 52], C++[46, 59]和Matlab [79]。例如，Brogi 等人 [11]开发了一个概念验证性的Java工具，名为FogTorch1，用于实现并求解服务放置问题。这些工具有时会与其他工具或API结合使用，例如ILP求解器。在文献中经常提到的求解器包括 IBM CPLEX2 [90, 94],商业求解器Gurobi3[74],以及Choco求解器4 [125]。

4.4.2 模拟器

另一种常用的方法是进行模拟。在文献中提到的模拟器中，我们发现有用于常规云环境的模拟器 CloudSim [152],，通常与某些扩展一起使用；还有用于大规模分布式系统的 SimGrid5框架；以及专为雾计算设计的模拟器 iFogSim [38],，该模拟器扩展了 CloudSim。iFogSim 是由 Gupta 等人 [38]提出的一种仿真工具包，用于评估雾计算系统中的应用程序设计和资源管理技术。该模拟器执行离散事件模拟，允许用户在雾基础设施上运行应用程序，并测量延迟、能耗和网络使用等指标。其他被引用的模拟器还包括通用网络模拟器 OMNeT++6（例如在参考文献 [63]中使用）；FogTorchΠ，由参考文献[126],提供，采用蒙特卡洛方法 [153]来估计输出部署的服务质量保障；基于 SimPy 的事件驱动模拟器，7由 Borylo 等人 [111],实现，等等。

4.4.3 实验测试平台

最后，我们有物理测试平台。作为真实环境，我们可以列举 FIT/IoT‐LAB[154]和Grid5000[155]大规模实验环境。FIT/IoT‐LAB测试平台是法国的一个大型开放式平台，专为测试未来物联网而设计，提供对多种固定和移动技术与服务的访问（在六个不同站点分布着超过2,700个异构传感器）。Grid’5000则更专注于并行和分布式计算，是一种用于研究未来大型基础设施（如云、数据中心、高性能计算E级系统、大数据基础设施、网络等）的科学实验工具。它包含大量强大的资源、网络连接性和存储访问能力，并分布在法国的10个站点中的同构集群中。我们有软件栈“OpenStack”[156],，这是一套用于部署云计算基础设施的开源软件工具（包括资源预留、磁盘镜像部署、监控工具、数据采集和存储）。我们还可以识别Cumulus[157]平台，用于边缘计算的计算卸载，以及诸如FED4Fire之类的平台[158],，这是欧洲最大的下一代互联网测试平台联合体，以及PlanetLab[159],，一个用于计算机网络和分布式系统研究的测试平台，等等。

4.5 总结

本节描述了服务放置问题，并总结了文献中用于解决该问题的常见建模方法、求解策略和评估工具。接下来，我们提出基于一种新的分类方案对调研工作进行分类，以简化获取感兴趣类别参考文献的途径，并更方便地识别挑战和新兴出现的研究方向。

5 服务放置方法的分类

在本节中，我们使用第4.2节中提出的分类法，为研究社区提供的关于服务放置问题的研究工作建立

雾计算和边缘计算中服务放置问题综述

5 服务放置方法的分类

在本节中，我们使用第4.2节中提出的分类法，为研究社区提供的关于服务放置问题的研究工作建立一种新的分类方案并进行分类。首先，我们建议根据问题描述将该问题分为两个主要场景（见表5）。然后，我们给出所进行的分类。其目的是将解决相同问题的研究工作进行归类，以更好地理解每个问题的需求，并方便用户查阅参考文献。

5.1 已识别的场景

在查阅文献时，我们发现根据问题的特征，可以确定两种主要场景：场景1，旨在满足服务质量要求的同时将服务部署到雾计算环境中；以及场景2，与第一种场景略有不同，为了确保最低延迟和满意的服务质量，必须在雾基础设施上分发和部署服务（复制部分服务并进行放置）。以下将对这些场景进行描述。

(i) 场景1：在满足需求的同时分配服务并优化给定目标（如果存在） 。大多数调研工作属于这一第一场景，试图提供答案并解决以下问题：“服务应部署和执行在何处才能最符合目标？”

在此场景中，我们注意到，根据我们对服务的特征描述方式，可以确定以下子场景：单体式应用程序集的分配、从物联网节点发送到雾/云层的连续请求的分配、每个由一组相互依赖的组件组成的应用程序集的分配、每个具有有向无环图拓扑的应用程序集的分配。

• 场景1.1：部署一组单体式应用程序 。该场景解决了为一组被视为单体式的服务确定最佳存储/处理位置的问题。
• 场景1.2：部署从数据源接收连续请求的应用程序 。此场景涉及在服务生产者（即传感器）和服务消费者（即雾资源）之间分配服务流。此处的应用程序放置涉及确定满足需求并优化目标（如果有的话）的主机设备和路由路径。
• 场景1.3：部署每个被抽象为一组相互依赖的服务的应用程序 。该场景假设每个应用程序由一组独立组件组成，即不考虑网络依赖（不考虑服务之间的延迟、带宽等需求）。
• 场景1.4：部署每个被抽象为有向无环图（DAG）的应用程序 。此处的应用程序通过有向无环图拓扑定义，其中每个节点表示应用程序的一个操作服务，链路描述组件之间的网络需求（详见第4.1.2（b）节）。

（ii） 场景2：在部署服务时确保最小延迟和满意的QoS 。雾计算能够将计算能力带到网络边缘，从而降低延迟和开销。然而，当应用程序需要访问集中存储的数据时（如视频流、视频点播、游戏等许多服务的情况），雾计算的优势可能会迅速受到影响（延迟恶化、出现瓶颈）。为了避免这些情况，一种解决方案是在雾环境中进行数据分发。将数据卸载到边缘涉及使用数据复制，并将副本放置在关键网络节点上，以提供更具成本效益的解决方案。

该场景与场景1相比，在略有不同的背景下处理服务放置问题。实际上，服务副本的放置位置需要满足额外且特定的要求和约束，例如：不要将相同服务放置在同一位置或区域、选择哪个服务副本等。此外，此处的服务放置问题（SPP）还与其他问题相关联，例如： “哪些应用程序组件需要复制？”、“每个服务应创建多少个副本？”、“何时创建和销毁副本？”等等。众多因素使得这一问题和场景成为一项极具挑战性的任务。

5.2 根据服务放置分类法对服务放置问题的分类

根据第4.2节中确定的场景和服务放置分类法，我们建议对文献中详细阐述的一些方法进行分类。表6展示了所提供的分类。

更详细的分类7、8、9、10和11中展示。在这些表格中，我们提出了所考虑的放置要求 （基于第4.1.3节中提到的要求），并描述了各研究的贡献。表7（分别对应表8、表9、表10和表11）专门针对处理场景1.1（分别对应场景1.2、场景1.3、场景1.4和场景2）的方法。

引入以下语法以将每项研究与相关分类法关联：

[C|二]/ [Off|On]/[S|Dy]/ [nM|M].

第一个参数表示所考虑的控制方案是Centralized（集中式）还是Distributed（分布式）。第二个参数表示调度是以Offline（离线）还是Online（在线）方式进行。第三个参数表示放置是Static（静态，即考虑不变的基础设施、应用程序拓扑结构和信息）还是 Dynamic（动态，即处理系统的动态性）。最后，第四个参数表示所提供的策略是否支持终端用户和/或雾设备的移动性（M）或不支持（nM）。因此，标记为 C/On/Dy/nM 的方法是集中式、在线、动态且不支持移动性的。该描述可快速对任何给定方案进行分类，并与类似方法进行恰当比较。我们注意到，这些类别中的每一项都是相互独立的。

√ √
√标记表示满足该标准；否则，该标准未满足或未被考虑。

5.3 根据解决方法对服务放置问题的分类

我们现在提议根据所使用的解决方法对类似的研究进行分组。部分解决方案及其目标在表 12、13、14、15和16中进行了详细说明。每个表格对应前述的场景（见第5.1节）。

根据提供的表格，我们将在下一节中讨论雾计算中服务放置问题的开放性研究方向及相关挑战。

6 新兴研究方向

本节讨论了当前的局限性，并强调了雾计算中服务放置问题的相关挑战。确定了近期需要关注的三个主要方向：与问题描述相关的挑战、优化策略以及评估环境。

6.1 与问题描述相关的挑战

尽管最近关于服务放置问题的研究工作已经取得了一些进展，但仍存在许多未解决的挑战，其中之一就是“问题描述”，即我们试图解决的问题是什么（适用于哪个场景），需要考虑哪些重要信息（基础设施信息、应用程序描述、映射需求），以及从哪些方面来解决该问题（分类法）。在此，我们列出了一些已识别的开放性问题。

6.1.1 考虑数据级依赖性的场景

根据所调研的论文，我们识别出研究社区考虑的两个主要场景（参见第5.1节），然而我们注意到，对于大多数属于上述场景的研究工作而言，服务放置问题（SPP）中并未真正（或仅在边缘程度上）考虑一个重要的用例。该用例对应于“具有数据依赖性的计算放置”，这正是推动雾计算发展的难题之一，因为雾计算的目标是将服务保持在生成和处理数据的设备附近。因此，在部署服务时，映射必须考虑数据级别的依赖性，无论是在局部性方面（例如，若某服务部署在特定区域，则相关组件也必须出于安全性等原因部署在同一区域内），还是在最小化交换数据流量等方面。据我们所知，文献中对此问题仅进行了边缘性的探讨，而具有数据依赖性的应用放置代表着需要更多关注和深入研究的真实挑战。

6.1.2 分布式服务部署

如文章前面所述，将决策分布到多个底层节点而不是依赖单个中心节点进行映射，有助于分担负载并可能提高可扩展性。对于雾计算等基础设施而言，人们倾向于认为大多数研究都基于这一过程。然而，根据表6、7、8、9、10和11可知，文献中提出的以分布式方式解决服务放置问题的解决方案仍然不足。这主要是因为分布式算法构建困难，并且由于进程间通信和同步的复杂性，其在真实环境中的实现往往难以实现。此外，缺乏对全局状态的了解使得计算最优解甚至达到近似最优放置都变得困难。我们还注意到，只有少数方法以分布式和动态的方式执行服务放置问题[49, 55, 115, 130]，而能够处理系统动态性并支持终端用户/雾节点移动性的分布式解决方案则更少（场景1.2的参考文献[49, 55]）。因此，这些方向的研究仍然开放。

6.2 与优化策略相关的挑战

下文将详细阐述从优化策略角度值得进一步研究的一些挑战和机遇。

6.2.1 优化目标

根据所研究的问题和考虑的用例，可以观察到不同的指标：终端用户之间的延迟/带宽、故障情况下的鲁棒性、传感器的能耗/电池寿命周期、成本、特定应用指标（帧/丢包率、处理某些数据的端到端延迟）等。根据表1，我们可以很容易地观察到，性能指标通常被作为独立目标来考虑

（最小化延迟、最大化满足的应用程序数量、最小化能耗等）。然而，为了提高服务质量 （QoS）和用户体验质量（QoE），这些指标应在目标函数中同时考虑，而不是作为约束函数集成到模型中。迄今为止，同时考虑多目标的研究尚未受到足够重视。由于此类问题的复杂性，仅有少数工作尝试解决这类问题[60, 69,104，106–109]。实际上，进行多目标优化并推导出有效解决方案需要巨大的计算开销[165]。可以探索多目标元启发式算法来解决此类问题，例如MOPSO[166]和NSGA‐II[167],，或像参考文献[168]所示的调度方法。

6.2.2 支持移动性的解决方案

由于部分终端用户和雾设备具有高移动性，所设计的解决方案必须确保服务连续性，并使用户始终能够接收到期望的请求。为此，服务必须跟随这种移动性，并在不同的雾实例之间进行迁移。在回顾文献时，我们发现仅有少数研究提出了支持终端用户/雾节点移动性的解决方案（见表 6）。此外，大多数已提出的动态应用程序迁移方法仅考虑受限的应用拓扑结构（如单体式、线形或树形图），仅支持终端用户的移动性（而非雾节点的移动性），并且基于复杂的技术和算法开发了动态解决方案。鉴于此，显然社区迫切需要定义适用于在实际雾系统中实现的标准算法技术。此外，我们观察到，目前大多数支持移动性的放置技术是反应式的。因此，在雾环境中，从主动式角度出发，通过预测用户和设备的移动模式来应对该问题可能更为合适。事实上，理解终端设备（或雾节点）的移动行为可能有助于在雾计算中实现高效的服务放置和服务管理。

6.2.3 能效

关于雾服务管理中的能耗，我们发现针对雾中某些方面的能耗研究较少

环境。我们确定了以下因素：考虑碳足迹的模型、利用风力涡轮机或太阳能电池板等可再生能源，以及考虑终端设备（传感器）在剩余电池寿命方面的能量限制、通信链路的能量等。在这些情况下采用随太阳走和随月亮走策略有助于高效管理能耗；例如，通过控制智能照明、通风、空调等设备。

6.2.4 通用且有效的映射

从第4.3节可以看出，已有许多公式化方法与解决方案被提出以解决特定应用程序的服务放置问题。文献中给出的这些放置策略（主要是启发式方法）考虑了不同的假设（基础设施信息、应用程序拓扑、QoS属性和指标等）以及不同的目标，使得它们难以进行比较。事实上，由于标准的多样性，实际中处理所有这些参数几乎是不可能的。因此，当前出现的问题是：哪些标准最为重要，应当被纳入以开发出有效的解决方案？根据这些标准，我们能否对现有的

方案并确定相关的方法？还是应该彻底革新，提出一种新的通用且易于升级的方法论？许多值得深入探讨的开放性问题。

6.3 与评估环境相关的挑战

我们建议在此描述一个我们认为从评估环境角度来看最为重要的挑战。

6.3.1 统一环境

通过表 4，我们可以清楚地观察到研究社区使用不同的工具来测试和开展实验。每种工具都有其特定性，并适用于特定的问题（用例），如第 4.4 节所述。尽管已有大量工作针对SPP挑战展开研究，但我们注意到目前尚缺乏一个通用的开发环境，能够处理大范围的标准化物联网应用程序，并支持考虑各种网络拓扑结构。因此，有必要构建一个统一平台，涵盖大多数相关概念，易于使用，并有利于开展广泛的实验。基于第 5.1 节提供的分类方案和场景，本文的贡献在于提出一些基础要素，以此为基础设计一个通用且可扩展的模型，以覆盖不同的雾计算用例。

7 结论

本文重点研究雾环境中的服务放置问题（SPP），该问题目前仍是一个开放性课题，亟需广泛讨论和解决方案。本文对现有研究工作进行了综述，给出了SPP的描述，并确定了与此问题相关的五个场景。从四个不同维度（集中式与分布式控制平面、离线与在线调度、静态与动态系统、是否支持终端用户/雾节点移动性）对解决方案进行了分类阐述。文章讨论了多个针对SPP的算法提案。最后，基于放置分类法，利用这些方面对文献中提出的 SPP解决方案进行了分类。具体而言，与现有综述相比，本研究提出了一种新的分类方案，旨在简化用户在特定情境下获取参考文献的途径，并更方便地识别与放置相关的挑战。