【啃论文俱乐部】雾计算的编排

Q&A

什么是雾计算？

​ 雾计算（Fog Computing），在该模式中数据、（数据）处理和应用程序集中在网络边缘的设备中，而不是几乎全部保存在云中，是云计算（Cloud Computing）的延伸概念，由思科（Cisco）提出的。 ----来自百度百科

雾计算是干什么的？

​ 国家在大力发展物联网，物联网发展的最终结果就是将所有的电子设备，移动终端，家用电器等等一切都互联起来，这些设备不仅数量巨大，而且分布广泛，只有雾计算才能满足，现实的需求对雾计算提出了要求，也为雾计算提供了发展机会。有了雾计算才使得很多业务可以部署。雾计算有几个明显特征：**低延时和位置感知，更为广泛的地理分布，适应移动性的应用，支持更多的边缘节点。**这些特征使得移动业务部署更加方便，满足更广泛的节点接入。 ----来自百度百科

和云计算有什么区别之处？

​ 与云计算相比，雾计算所采用的架构更呈分布式，更接近网络边缘。雾计算将数据、数据处理和应用程序集中在网络边缘的设备中，而不像云计算那样将它们几乎全部保存在云中。数据的存储及处理更依赖本地设备，而非服务器。所以，云计算是新一代的集中式计算，而雾计算是新一代的分布式计算，符合互联网的“去中心化”特征。 ----来自百度百科

难道就是CDN（Content Delivery Network – 内容分发网络）？

​ CDN，内容分发网络。1998年由Akamai公司提出。这种技术主要强调的是缓存技术！这里的服务器也可以称为缓存服务器。它需要中心平台的控制，比如负载均衡、内容分发和调度等功能模块。(它依然受云的控制，作为缓存节点，缩短云和用户之间的传输距离，云把请求任务发给CDN服务器，CDN将内容发送给用户)

​ Fog computing，雾计算。2012年由思科提出。它需要雾节点，实际上也是中间件，但更加关注基础设施。

​ 所以雾计算并不是CDN，仅仅是两种不同的分布式实现方式，CDN还是从云上获取数据，而雾计算强调的是直接在本地获取。

雾计算的编排又是干啥的？

​ 与云计算不同，雾资源基于受约束的异构节点，其连接可能不稳定。在这种复杂的场景中，需要定义和实现编排流程，以确保可以提供应用程序和服务，同时也要考虑到已存在的协议。

我的感受

​ 雾计算这个定义在2011年就已经被美国纽约哥伦比亚大学的斯特尔佛教授提出， 想到的是用“雾”的概念来防止他人入侵。发展到当前社会5G时代下，各个方向都趋近于更加分布式，分布式存储，分布式计算，分布式管理等等等等。所以一些看似当前用不到的技术有可能为未来埋下了伏笔。

雾计算分层架构与功能

分层架构

上图展示的是雾计算基本的三层架构，即 IOT层、雾计算层、云计算层

在其他文献中还包括有四层、五层、六层架构方式：

四层：雾计算层分为边缘节点和中间节点，其他不变

五层：雾计算层分为边缘网络、中心网络和核心网络

六层：雾计算层分化为传输层、硬件层、算法层、区域计算

看似不一样的架构，其实核心是一个意思，都是在IOT设备发送请求之后，雾计算设备进行处理，如果无法进行，就转发到云计算，可以进行就在本地雾计算设备上进行，有效的降低了云通信通道的拥堵。

功能

根据美国国家标准与技术研究所（NIST）的要求，雾计算的基本特征包括

• 低延迟：与云服务的操作相比，雾计算节点更接近最终用户，可以更快地分析和响应用户生成和请求的数据；
• 地理分布：与云计算不同，在雾计算基础设施上运行的服务和应用程序需要地理分布部署和管理
• 异构性：允许收集和处理从不同来源获得并通过多种网络通信方式收集的信息
• 互操作性和联合：资源必须能够彼此互操作，服务和应用程序必须跨域联合
• 实时交互：雾计算服务和应用程序涉及实时交互，而不仅仅是批处理
• 可扩展性：允许快速检测工作负载响应时间的变化以及网络和设备条件的变化，支持资源的弹性。

关于雾计算架构，NIST指出，其最底层是由一个个雾节点组成的，雾节点是与智能终端设备或接入网络紧密耦合并向这些设备提供计算资源的物理组件（例如网关）或虚拟组件（例如虚拟机）。它需要支持以下一个或多个属性：自治性、异构性、分层集群、可管理性和可编程性

从时间线的角度来看看那些容易混淆的概念

比如很多人会把**雾计算、边缘计算、多址边缘计算（MEC）**搞混淆，很多文献也把它们搞混，是由于这几个概念都是与云计算结合，并作为云计算的补充，且目标主要是边缘设备。其实，雾计算主要在多层架构服务，且设备较多；边缘计算的设备往往没有那么多；MEC则类似于将边缘计算进行实施，将计算和存储都带入RAN（Radio Access Network），

还有类似于移动云计算，汽计算（Mist computing），移动临时云计算（Mobile Adhoc Cloud computing），露计算（Dew computing），薄云计算（Cloudlet Computing）。这些名字是笔者自己翻译的，感觉意思都是大差不差。上述的几个名词，其实是差不多的定义，笔者认为可能命名不同，细节不同，但是大差不差。

编排的概念

所谓编排，就是指在分布式系统中，经过某些手段、技术、方法使分布式的分模块合理的调度、部署，以满足客户的业务需要。–笔者自己的定义，欢迎补充。现在的编排可以是软件上的定义，也可以应用于硬件上，其实也就是让一个个的小块合理的分配资源，用于满足某个特定的目标。

雾编排：是一种服务的生命周期的管理方式，为了向用户发出的请求提供服务并且确保服务等级协议（SLA），它必须监控底层基础设施，及时的对其的更改做出反应，并遵守隐私和安全法规。

雾计算相关领域的编排

编排也存在于本工作范围之外的雾计算相关领域，如容器编排、软件定义网络（SDN）和网络功能虚拟化（NFV）

SDN和NFV

SDN的主要特点是分离经典网络设备上紧密耦合的控制和数据平面。因此，SDN可以将网络控制功能分配出去，而不会在单个管理点中丢失集中式（逻辑上）网络视图。NFV的目标是简化通用硬件上使用虚拟网络功能（VNF），这是一种基于软件的网络服务。NFV的好处是可以降低成本和提高网络功能的弹性。这些技术旨在发展网络层，通过网络服务的管理和编排（MANO）扩展网络可用性和性能。

SDN目前缺乏通用的软件接口，也就是北行接口，NFV编排其依赖于不同的基础设施模型。这两个目前都还是处于婴儿期，仍然需要很长时间的研究。

容器编排

由于设备资源有限，那么使用容器（一种轻量级和占用空间小的虚拟化形式）是一种更好的选择，比虚拟机作为运行环境更合适一点。Docker是最著名的一种，当然还可以使用容器编排解决方案，也就是Kubernetes、Docker Swarm、Nomad和Marathon on Mesos，用于管理容器的生命周期，包括有放大或缩小容器生命周期、进行自我修复、迁移容器和管理异构基础设施，抽象容器执行的物理设备。那么由此可以采用容器编排解决方案来实现和自动化雾计算的一些基本特征：异构性、地理分布和可扩展性。

不过，容器一样有局限性，不是特别适合作为雾编排的直接解决方案。

• 在服务的编排场景中，由部署的工件交付的功能以及它们之间的关系是内核，但在容器的编排场景中，这不一定正确。
• 容器不具备设备感知能力，在决定哪一个应该处理每个请求时，它们不会考虑服务实例的地理位置。

所以，在涉及到地理位置时，比如让用户连接最近的节点，这件需求就无法实现。

反而在资源丰富的设备，也就云设备，容器管理甚至可能更有利，因为云有更好的性能和负载能力，但是，部署在云上就又会增加通信延迟，这就和雾计算的实现目标背道而驰。

所以，容器编排仅仅实现了部分功能，并不会提供完整的生命周期管理，也不符合隐私和安全规定，所以容器编排仅仅可以作为雾编排的一个组件来进行服务。

一些相关工作的开展

上表可以看出，大部分的研究还是针对于将编排和管理关联的部分

• 107讨论了智能城市应用背景下雾计算的主要功能，主要关注雾计算的连接性和设备配置方面，只探讨了几个编排功能：资源管理、通信管理和安全。

• 140中，作者提出了雾编排的研究挑战，并对云、雾、边缘和MEC编排架构进行了调查。虽然选择了75个作品进行分析，但其中只有四个作品对其提出的架构进行了比较。

• 98建立了DEPO4IOT（Deployment and Orchestration Approaches for IoT），作者使用编排作为服务组合的同义词，而不是像本次调查那样包含服务组合和聚合其他几个功能的更广泛的协调和管理功能。

• 112的作者调查了一些文献，介绍了雾计算的主要特点，常见应用领域、物联网的现有软件和硬件平台以及研究挑战。雾计算编排被详细描述为这些挑战之一，但其功能仅部分讨论。

• 72探讨了雾计算的应用程序管理，并确定了其三个主要方面：应用程序架构、应用程序放置和应用程序维护。

  作者提出了针对上面三个方面的三个分类法。虽然分类涵盖了一些雾编排功能，但其他重要功能超出了范围，例如请求接纳、通信管理和雾基础设施相关的监测和资源管理。

研究方法论

本次研究根据SLR方法进行研究，以下进行详细的介绍

研究问题

首先定义研究问题，确立研究方向，应该取得那些结果，并作为SLR的方向引导。

指定了五个研究问题：

1. 编排的目标是什么？–收集目标，揭示打算解决哪些雾计算问题。最终和问题5的结果进行比较，确定雾编排真正的方向。
2. 究竟要编排什么东西？–展示文献中的专业术语，并将这些作为支持编排概念的一些功能，而不是作为资源管理的子领域。
3. 编排控制的拓扑结构是什么样子？–完成拓扑结构就可以很容易的理解可能产生的问题，结合其他范例，提出解决方案。
4. 要考虑哪些架构层？–本问题的答案会显示雾计算的趋势，以及雾计算和通信与故障管理以及实现编排目标的相关性。
5. 编排要包含哪些功能？–有助于整合编排方案，可以从最先进的架构中进行整合。

这些问题也会成为下一步的搜索关键词

搜索进程

搜索过程包括选择使用的在线搜索数据库、具体日期和搜索字符串细化。

本次搜索关键词为“orchestrat* AND ( fog OR edge OR mec )”（“编排*和（雾或边缘或mec）”）

当然关键词可以变化一下，比如“orchestrating”, “orchestrated” and “orchestrator”.

接收和排除标准

作者来自于巴西利亚大学，接收有以下的标准：

• 英文出版物
• 2012年开始（由于雾计算从2011年才有概念）
• 介绍架构模型、技术或方法的出版物，应用于雾计算中的编排。

排除有以下标准：

• 重复的出版物
• 目标在于网络层的出版物
• 我们已经分析过的出版物
• 仅仅只关注一种功能，而不是将其大范围的协调统一

质量评估

去重之后，1758份出版物的数量减少到1066份。标题和摘要的筛选将出版物数量减少到130份。

确保资源管理、监控和安全是最常用的编排功能，所以将编排作为最主要的关键词，查询出了145份文献，最终选择了50份。

数据分析

图七显示了各年份有的文献的数目，可以看到在2017年受到了很大的关注，虽然概念提出是在2011年，但是科研领域对其的研究却滞后很多，2021年只统计了两个月的数据，近几年针对其的关注度一直很高。

研究问题结论

针对于研究方法论里面的研究问题，得出了结论

编排目标

编排本身是功能和过程的协调，其目标可以被视为其组成部分目标的结果。

总结出来有以下几个目标：

了解了这么几个目标之后，结合问题5的结论，就可以理解雾编排将RM作为最主要的功能的意义。

也展现了雾编排方向上的改变，从管理雾基础设施确保服务到管理和协调功能，协调用户需求和提供服务之间的关系。

协调的实体

最常被作为编排目标的实体是服务，就是广义上来讲，交付的软件，必须在雾平台上使用，也有论文将其定义为服务组件、服务段或者微服务，也提出了细粒度软件（fine-grained piece of software）的概念。而为了强调其依赖关系，也有人将其称为服务链或者服务组合。

也有文献将其称为应用程序，少数论文也使用了类似于微服务的应用程序组件。

另一个编排的实体是任务，也表现为任务的组合、管道或者工作流

其他的实体就和具体编排的任务有关。类似于“边缘函数”（将在雾节点上执行的代码部分）的管道、“移动查询”、“分析管道”、移动边缘设备等等。

很多被提及的实体，类似于上一段上我提及的那些，都是具体情况具体分析，被归进了others。

所谓的这些差异性的实体，笔者将其抽象为"服务"，表示由现有编排框架管理的可执行代码段。

编排控制拓扑结构

本问题旨在确定数据流和决策的编排的控制拓扑结构，确定了三种结构：

1. 集中式，只有一个中心节点作为编排器；
2. 分散式，其中节点组有一个局部领导节点，领导以预定义的方式协作进行决策；
3. 分布式，其中所有节点都可以交互以对整个基础设施做出决策。

集中式

首先说一说集中式，很多文献都提到了集中式的拓扑结构，将编排器处于中心位置，这样确实编排起来更简单，资源管理也更简单。但是仍然有单点故障的后果，很多文献都提出了SPOF（Single Point of Failure）的解决方案：将复制和重选中心点结合在一起，那么在这样的情况下，编排器不可用的情况下，就有备选方案（重新选择编排器）。

也有其他的方案。每一个服务在云中设置中央服务器，负责提供给用户发出的请求。为了提高服务性能，可以在雾节点上放置分区服务器，以便附近的用户可以连接到此本地服务器，并在本地管理其服务相关数据，而不是连接到云。雾节点会定期更新集中式服务器，使其能够全局查看服务使用情况。当雾节点无法执行额外的本地服务器或无法保证SLA时，它会拒绝分配，或者在已经分配时，它会将本地数据迁移回云。

each service has a centralized server in the cloud that supplies the requests made by the users. To improve service performance, a partitioned server can be placed on fog nodes so the users in the vicinity can connect to this local server and have their service-related data managed locally instead of connecting to the cloud. Periodically, the fog nodes update the centralized server so it can have a global view of the service usage. When a fog node cannot execute an additional local server or cannot guarantee the SLAs, it denies the allocation or, when already allocated, it migrates local data back to the cloud.

笔者认为，上段所述的方案还是和CDN差不多，所以我将原文也粘贴了进来，欢迎大家探讨。

分散式

这个拓扑结构是很少的论文所提及的结构，一些功能可以分布在多个节点之间，这些节点必须交换有关其管理的资源的状态信息，并且必须使用可用信息（可能是部分信息）做出决策。

几篇论文里提及的结构不是很一样，具体来讲

第一种

虚拟化基础设施被划分为多个域，叫做节点组，其中一个节点是控制器，也可以理解为是编排的中枢。控制器使用peer-to-peer (P2P)协议通信，把中心实体叫做Fog Orchestrator（FO）–雾编排器，经由它传递给分布式实体的过程，叫做Fog Orchestrator Agents（FOA）–雾编排器代理，必要的时候FOA操作也可以当做中心实体，比如在连接线路不够，没办法连接FO的情况下就这么办。

在别的文献中也存在“北行通信用集中式，南行通信和编排用分散式”，还有“雾层创建中途服务器实体，负责所需地理区（客户需求），有请求时就将查询广播到IOT的边缘网关，负责跟踪负责区域内目标，每个边缘网关有已安装的查询表，在超出查询范围时回馈给中途服务器，旨在降低通信成本”

第二种

中央编排模块安排在云上，负责接收服务请求，并将其传递给雾层中分散的模块，将其称为“中介”。中介负责管理IOT设备的资源和发现IOT设备，以地理位置为标准将其聚集在一起，也保证其私密性。然后经由IOT处理完成之后，中介将其汇总并返回给请求设备。

第三种

在这种方法中，云中有集中的应用程序控制器来管理应用程序的位置以及生命周期。编写一个特定的进程（可以理解为不间断运行的一个脚本），运行在云上，用于自动发现新的雾节点，这些雾节点指的是可以分享它们自身资源的节点组。每一个节点都有一个负责站点协调、资源管理、资源监控的服务。根据云中的应用程序策略，应用程序控制器就可以使用多个雾节点的资源，有效的提高了应用程序的性能。

第四种

每个节点都可以为了每一个系统中的应用程序担任一个或者多个角色，比如说leader或者host。使用位置感知算法，以位置为主要特征，确定特定节点为本应用程序的leader，将一组节点设置为本应用程序的host，用于控制系统中的该应用程序。每个应用程序的基础，都有几组节点，每组节点有一个leader，这些节点就根据需要进行交互，确定获取和释放资源。

分布式

这种编排拓扑结构就没有所谓的中央节点或者leader，所有的节点都可以就编排进行决策然后发送给其他节点。

主要有以下几种方式：

• 可以通过资源可用性决定是否以及在何处落实任务（可以选择在本节点，或者其他节点，或者云上）

• 每个雾设备轮换着编排，让其中一个设备进行编排，将可移动的设备朝着需求更大，请求更多的方向进行移动。

• 设置一个Service Defined Orchestrator（SDO – 服务定义编排器），和其语义相同，其负责的是每个节点的部署的服务。SDO使用共识机制来从共享资源中获取资源并分配资源。

• 从应用程序的设计入手，应用的部署就要有雾节点之间的协作。每个节点要对于其可以做哪些应用中的任务做出决策，同时为了更好的做出决策，本节点也要接收其他相邻的节点的资源信息和通信延迟的信息。

总结

集中式是最常被引用的控制拓扑结构，但是其中很多没有解决SPOF（Single Point of Failure）风险。所以要提高容错能力。

前文提到，异构性是雾计算基本特征之一，那么编排器所在节点往往应该是最强大的可用节点之一。考虑到高可用性，要将其运用于一组节点，甚至要包括集群，复制等需求，乃至可以将编排器在云上执行，但是目前并没有论文针对其展开讨论。

要实现数据同步和数据处理，那么雾计算设备就需要有良好的通信能力和良好的性能，但是往往还是会出现通信连接受阻和计算资源有限的问题。

涵盖的架构层

让我们回顾一下，编排要考虑的层次有几层。雾计算作为云计算的拓展，将计算资源提供给更靠近用户边缘来执行服务，考虑到了三层的架构（云层，雾层，IOT），其中雾层就包括了云和用户之间的所有内容。

雾层

如上图所示，将服务完全安排在雾层中。由于涉及到不少异构设备，那么，资源管理功能就要将这一部分安排妥善。对比于IOT层，他们的数量仍然是比较中等的。这层不是特别复杂，起码对于多层而言，是很简单的。那么即使当他们需要云资源的时候，也就是缺少适当的雾资源的服务，他们可以通过云服务商提供的api来进行雾计算的编排。

雾和云层

如上图所示，有些论文在考虑雾层的同时也考虑了云层的用以服务，那么在这样的情况下，雾编排就必须将两个层面上的可用资源进行监视和管理，而且这种管理复杂性会大大增加。

IOT、雾和云层

这样要考虑到物联网设备上的资源的时候，其的编排就大有不同了。很明显要对于用户的设备进行管理和调度。而且由于物联网设备的数量众多，其复杂性将远远高于上面两种编排方式。

其他

还有很多其他的论文对此进行了重新的编排，设定了一些新的框架。

1.云、数据中心、雾设备和IOT设备。

将协调器放在云上，执行服务额资源仍然基于IOT层。本框架将IOT设备放在一个基于地理位置创建的集群中，选择一个设备作为主导体，原文称为‘Mediator’，协调器将请求发给这个Mediator，然后让这个Mediator来执行。

使用一个互联网规模上运行的发现机制，允许雾层分布在几个独立的站点上，使用Internet协议（BGP&DNS）发现站点。将发现之后的站点与编排器进行共享。Sunstone框架。

仅应用于IOT层，其中一个物联网设备被设置为主要代理，其主要任务是编排组成请求服务的任务，让他们可以利用一个或多个较近的设备上执行任务。

2.更多的框架将物联网设备作为了编排任务中心，由于涉及到终端设备，用户的隐私和资源仍然是这些想法中的一个大的拦路虎，并且进行资源管理更是很难，笔者与原作者都认为本方案完全不可行。

一个通用的雾计算架构要完成的功能

现在回答RQ5，提取了解决雾计算编排的功能模块和体系结构之后，发现了很多功能是已知的，前面也早就提到过了，类似资源管理这样的。

但是仍然可以找到一些很细节的功能，比如说“按照某一策略来重新定位雾节点使其更好的处理计算复杂的局部变化”这样的功能，这样的功能很具体。

将其总结如下：

对请求的过滤

要有一种最起码的过滤机制，让编排的框架接收雾计算供应商给出的产品中可用服务。已经有人提出了这个问题并发布了API，该API可以集成到请求的管理系统中，或者直接创建请求服务的实例化（直接开始）。

这个功能也可以保证SLA和QoE协议，收到请求时可以验证雾计算基础设备是否准备好了，以及请求的用户是否具有等待、交互和及时接收结果的最低限度的资源（信号、电量等），当无法满足时，直接拒绝。

服务管理

SM是产品组合中服务生命周期的一个功能。完成服务之前，要检查服务的依赖项，而且服务可能有执行时的特殊要求，比如像最小数量的内存占用。这样的信息必须在服务创建阶段就已经被确定好，而且要应用于服务请求到达后的每个生命周期。也要提供执行环境的规则和服务映像。将可执行代码和有关约束和需求一起放在一个数据库中，将其定义为“服务存储库”的数据库。

服务管理可以将大的服务拆分为几个小的服务同时执行，保证他们之间服务隔离的同时，要提供更好的资源利用率。如果发现请求的服务无法完成，SM还可以继续要求增加资源，将其交给资源管理RM，若有可用资源，让RM负责改进，若没有可用资源，RM要请求放弃服务或者将服务迁移，若也没有地方迁移，通知SM是否可以接收更低的性能。

让服务管理（SM）和资源管理（RM）两个合理的交互，时时刻刻检查每个服务的所需资源。

资源管理

资源管理可以分为几个子过程（例如资源发现、分配、供应、调度、解决等），顺序和名称都不重要，因为实际过程中各家有各家的命名和规则。

资源发现流程负责找到可以匹配的新的雾节点，雾节点可以采用自我广播这样的主动寻找策略，编排器也可以通过Internet来进行搜索，找到之后就会按照原先设定好的协议进行通信和集成。收到请求之后，编排器自动找到像NDS这样的已经被证明的互联网工具找到雾计算的提供者，基于区块链提出协议。

有关于新的雾节点和资源可用状态监控信息将被存储在上文提到的数据库中。该数据库可以通过节点定时发送的定期消息、监视事件、服务管理操作进行实时更新。

接收到请求之后，RM必须合理分配运行请求所需的资源。资源分配旨在以适当的方式提供计算资源的任务，以便服务或应用程序能够实现其定义的性能和 QoS 目标。计算资源往往是有限的，必须好好的利用，在网格计算、高性能计算和云计算当中，也都进行了研究。资源分配与多个研究领域相关，因为它旨在优化使用可用资源 。资源分配，也称为资源供应，是 RM 的一个子过程，负责从资源清单中选择和保留执行服务的最佳可用资源。为了避免与资源过度分配和分配不足相关的问题，使用深度学习方法来做出有关扩展雾资源的决策。 在 TACRM，为每个用户估计一个信任值。基于此值，定义用户的优先级，并用于定义分配的资源量。如果可用，具有最高优先级的用户应该收到最多的请求资源。

雾计算中的资源调度负责根据现有的调度策略将可用资源最佳可行地分配给服务需求。它的目标是满足 QoS 要求和 减少服务的执行时间。服务的设置利用先前 RM 描述的子流程来找到可以执行所有服务组件并满足 QoS 和 SLA 的最佳资源集。一些论文专注于计算卸载，这是一 种在资源更丰富的节点（或云中）上设置服务（或服务的一部分）的功能，防止请求者耗尽其资源，并将结果发回。

服务开始执行后，场景可能会动态变化，可能需要采取措施来保证理想的性能并优化资源使用。自动缩放是负责采取这些行动的资源管理子流程。文献中提出了各种方法来解决这个问题。例如，水平扩展，根据负载的增加或减少添加或删除服务实例。或垂直缩放，调整分配给服务的资源大小。缩放行为可以是主动的，基于尝试预测负载变化并采取行动来预测它的技术，或者它可以是被动的，基于在负载变化发生并达到特定阈值后采 取行动的预定义规则，例如CPU 使用率高于 90 %。在 RECAP中，提出的框架执行应用程序建模， 记录应用程序特征、依赖关系和限制。此后，此信息将用于根据需要自动垂直和水平扩展应用程序。PiCasso 是一个服务编 排框架，以小型板计算机 (SBC)作为底层基础设施，利用容器作为执行环境。其他论文使用修改后的容器编排解决方案来处理其提案中的资源管理。Kubernetes的作者扩展了 Kubernetes，添加了一个本地服务映像存储库和一个标签系统，用于将服务需求映射到雾节点，考虑到节点的资源和位置，明确记录在 Kubernetes 上附加到它们的标签上.

监测

雾计算作为一种范式，要通过雾节点来在用户附近提供计算能力，这让资源可用性带来了不确定性。必须经常性、实时性的监视资源。除了验证可用性，也要对于SLA和QoE分析资源所必须满足的要求进行监视。

由于雾节点的上述限制，必须对其资源（能量、CPU、内存、存储、加速器、附加传感器）进行本地监控。此信息可用于做出有关接受新服务、卸载等的决策。根据控制的雾计算拓扑，此信息可以存储在本地以 支持自主决策，与其他节点交换或者，为了支持集中决策，交换到中央模块以更广泛地了解所有基础设施。

优化

优化在雾计算研究中起着重要作用，因为雾计算的基本目标与延迟、能耗或资源利用率等指标的优化有关。优化问题通常由编码要做出的决策的变量、变量应满足的约束和目 标函数构成。优化的目标是找到最小化或最大化目标函数并满足约束条件的解决方案。雾编排器的优化模块实 施算法和技术以最小化某些指标（例如延迟、网络负载）和/或最大化其他指标（例如资源可用性）。这些优化可以 帮助编排器实现其他复合指标（例如 QoS、QoE、SLA）。该模块还必须考虑服务存储库中可用的每个服务的要求 和约束。

移动预测器功能是可用的。服务管理功能使用它来预测移动用户的位置，并利用此信息放 置或替换该用户请求的服务并遵守 SLA。

提出了一种优化函数，它根据服务的位置计算拓扑的最优重新配置，以保证商定的 QoE/QoS。使用贝叶斯迭代强化学习方法来重新配置服务的拓扑。

与服务分发相关的其他方法是

(1) 将服务分解为微服务的直接无环图 (DAG)并进行重复数据删除，找到被多个服务使用的子DAG，并防止它们在基础设施中的倍增。

(2)使用与云数据中心服务器整合相同的方法整合服务。目标是拥有最少数量的服务副本，并在此过程中将用户请求重定向到整合的服务，从而优化资源使用。使用对等域历史数据的分析来改进在域之间卸载服务的决策。对已收集的数据进行了分析。

预测未来场景以预测行动是一些论文中发现的一种优化策略。在 [ 132 ] 中，每个 Fog 设备运行一个代理，该代理负责其网段（网络范围）中的编排。一次一个设备还负责区域编排，这是一项查看区域（所有段的总和）负载并将移动边缘设备（重新）定位到需要更多资源的段的功能。使用网络负载预测来优化其资源和服务管理 操作。除了预测网络负载，通信负载预测和计算负载预测是文献中发现的其他方法。优化可用 于QoS 验证。一种非常适合资源受限设备的无模型机器学习技术（称为强化学习）用于完成此任务。

CHRIOT使用特定领域建模语言 (DSML)来描述雾环境：雾节点和服务组合。它还制定了编码环境属性和要求的可满足性模理论 (SMT)约束，从而能够使用SMT求解器在运行时动态计算最佳系统（重新）配 置。

通信管理

使用不稳定的网络与资源受限的异构设备进行通信也是一个必须解决的挑战。这些雾计算特性将限制适合在这种情 况下使用的通信协议和工具。提出了一种机器对机器 (M2M)通信模块，该模块部署到雾节点，用于与南向接口上的附加设备和传感器进行通信。该模块负责收集生成的数据和监控信息（资源可用性、电池电量等）.使用 OpenMTC M2M 框架来实现所提出的模块，还使用了M2M通信。针对南向通信提出了其他方法：层间通信、地理寻址 (GA)消息传递和基于插件通信。

提出了一种负责西行通信的通信管理功能，即在对等雾域之间频繁交换消息。 交换的消息有三个目标： (1) 传达可用资源和使用它们的规则；(2) 测量将用于保证 IoT 服务的 QoS 要求的传输延 迟，以及 (3) 创建每个域的历史数据数据库，以通过使用分析改进卸载决策。

很多论文提出了很多不同的通信模式，笔者认为这些通信模式都不是普适性的代表，反而应该在具体行业各有建树。

节点代理

要在雾节点上运行服务，必须在其上部署执行环境。此外，为了协调不同雾节点之间的服务，准确了解资源可用性很重要。这两个操作可以远程执行。前者可以使用节点上的容器编排解决方案来执行。后者可以通过远程调用操作系统原语来实现，但在网络不可用的情况下，信息无法恢复并且可能丢失。在这两种情况下，这些方法都要求雾节点的环境和配置分别符合每一个。一种更灵活的方法是部署一个雾节点代理，一个负责在本地管理节点的模块。该模块可以在不同平台上实现，可以 进行本地操作，例如保存监控信息和管理正在执行的服务的生命周期，并且可以与其他代理或中央编排模块进行通信，具体取决于编排的控制拓扑框架到位。

安全

信息安全和隐私是雾计算环境中的重要课题。一些雾节点和附加传感器和执行器的硬件限制、分布式架构和网络不确定性是增加attack并限制可以应用的安全解决方案的雾特性。

关于在数据通信和存储上使用安全性，只有少数文章确立了实施条件。尽管他们的架构描述了安全模 块，但还没有实现，他们的提议仅包含一个概念架构。

通过VPN、防火墙、PKI（公钥基础设施）加密通信、区块链。或者使用多用户来进行考虑。

总结

AC-Admission Control of incoming requests；SM-服务管理；RM-资源管理； MO-监控；OP-优化；CM-通信管理；NA-Node 代理和SE-Security。

可以看出没有一篇论文实现了本节中介绍的所有功能。呈现的通用雾计算编排架构整合了所有分析的提议。它显示了所解决的编排功能以及作者为实现它们而做出的选择，有助于希望更好地了解该主题的最新技术的研究人员。 作为最近的一个研究领域，这些提案首先尝试以结构化和协调的方式聚合与雾中编排相关的几个功能，重点关注它 们之间的交互并考虑跨层通信。因此，资源管理和监控是分析提案中实现最多的功能，因为它们与服务的执行环境 直接相关，并且是实现第2节中提到的一些基本雾特性的基础，例如低延迟（通过提供靠近用户的资源，并通过监 控来衡量和伴随）、实时交互和可扩展性，通过及时监控事件来表明需要改变资源分配。 有许多雾计算论文分别关注每个功能，例如优化、安全，获得更广泛和更深入的主题并分析不同的方法。编排研究可以集中在如何让所有功能同时正常工作的管理和协调问题上，所有这些都有助于现有编排框架提出的具体目标。从这个意义上说，使用策略来确定在每个集成功能中必须发生的优化算法和技术的选择可能是一个研究方向。因此，雾编排提案可以采用每个功能的最新技术，通过参数化使其遵循编排框架中规定的策略，而不是提出关于一两个功能的新内容。

在这样的背景下，仍然要对于1.隐私和安全2.实地化考察3.标准化执行环境进行进一步的研究和努力。