边缘计算面临什么问题

目前边缘计算已经得到了各行各业的广泛重视，并且在很多应用场景下开花结果。根据边缘计算领域特定的特点，本文认为6个方向是未来几年迫切需要解决的问题：编程模型、软硬件选型、基准程序与标准、动态调度、与垂直行业的紧密结合以及边缘节点的落地。

1.编程模型

编程模型可以使开发者快速上手开发应用产品，从而快速推动领域的发展。在云计算场景中，用户程序在目标平台上编写和编译，然后运行到云服务器，基础设施对于用户是透明的，例如亚马逊基于此编程模型推出的 Lambda 计算服务，可使用户无需预配置或者管理服务器即可运行代码，极大地方便了用户的使用。然而，边缘计算模型与云计算模型存在较大的区别，从功能角度讲，边缘计算是一种分布式的计算系统，具有d性管理、协同执行和环境异构的特点，如图4所示：

从图4可知，边缘计算包含3个关键内容：

1） 应用程序/服务功能可分割。边缘计算中的一个任务可以迁移到不同的边缘设备去执行，任务可分割包括仅能分割其自身或将一个任务分割成子任务，任务的执行需要满足可迁移性，即任务可迁移是实现在边 缘设备上进行数据处理的必要条件。

2）数据可分布。数据可分布既是边缘计算的特征也是边缘计算模型对待处理数据集合的要求。边缘数据的可分布性是针对不同数据源而言的，不同数据源来源于数据生产者所产生的大量数据。

3）资源可分布。边缘计算模型中的数据具有一定的可分布性，从而要求处理数据所需要的计算、存储和通信资源也具有可分布性。只有当边缘计算系统具备数据处理和计算所需要的资源，边缘设备才可以对数据进行处理。

因此，传统的编程模型并不适合边缘计算。边缘计算中的设备大多是异构计算平台，每个设备上的运行时环境、数据也不相同，且边缘设备的资源相对受限，在边缘计算场景下部署用户应用程序会有较大的困难。Li等人针对边缘设备资源受限的特性设计了一种轻量级的编程语言EveryLite，该工作将计算迁移任务中主体为接口调用的、时间和空间复杂度受限的计算任务称为微任务（micro task）， EveryLite能够在物端设备上处理边缘计算场景中微任务，经过实验对比可以发现EveryLite的执行时间分别比JerryScript和Lua低77%和74%，编译后内存占用量分别是JerryScript和Lua的18. 9% 和1. 4%。因此，针对边缘计算场景下的编程模型的研究具有非常大的空间，也十分紧迫。

2.软硬件选型

边缘计算系统具有碎片化和异构性的特点。在硬件层面上，有CPU，GPU，FPGA，ASIC等各类计算单元，即便是基于同一类计算单元，也有不同的整机产品，例如基于英伟达GPU的边缘硬件产品，既有计算能力较强的DRIVEPX2，又有计算能力较弱 的Jetson TX2 ;在软件系统上，针对深度学习应用， 有 TensorFlow， Caffe， PyTorch 等各类框架。不同的软硬件及其组合有各自擅长的应用场景，这带来了一个问题：开发者不知道如何选用合适的软硬件产品以满足自身应用的需求。

在软硬件选型时，既要对自身应用的计算特性做深人了解，从而找到计算能力满足应用需求的硬件产品，又要找到合适的软件框架进行开发，同时还要考虑到硬件的功耗和成本在可接受范围内。因此，设计并实现一套能够帮助用户对边缘计算平台进行性能、功耗分析并提供软硬件选型参考的工具十分重要。

3.基准程序和标准

随着边缘计算的发展，学术界和工业界开始推出越来越多的针对不同边缘计算场景设计的硬件或软件系统平台，那么我们会面临一个紧迫的问题，即如何对这些系统平台进行全面并公平的评测。传统的计算场景都有经典基准测试集（benchmark），例如并行计算场景中的PARSEC、高性能计算场景中的 HPCC、大数据计算场景中的BigDataBench。

由于边缘计算仍然是较新的计算场景，业界仍然没有一个比较权威的用于评测系统性能的Benchmark出现，但是学术界已经开始有了一些探索工作SD-VBS和MEVBench均是针对移动端设备评测基于机器视觉负载的基准测试集。 SD-VBS选取了28个机器视觉核心负载，并提供了C++和Matlab的实现；MEVBench则提供了一些列特征提取、特征分类、物体检测和物体追踪相关的视觉算法负责，并提供单线程核多线程的C++实现。 SLAMBench是一个针对移动端机器人计算系统设计的基准测试集，其使用RG&D SLAM作为评测负载，并且针对不同异构硬件提供C++，OpenMP， OpenCL 和 CUDA 版本的实现.CAVBench是第1个针对智能网联车边缘计算系统设计的基准测试集，其选择6个智能网联车上的典型应用作为评测负责，并提供标准的输人数据集和应用-系统匹配指标。

由于边缘计算场景覆盖面广，短期来看不会出现一个统一的基准测试集可以适应所有场景下的边缘计算平台，而是针对每一类计算场景会出现一个经典的基准测试集，之后各个基准测试集互相融合借鉴，找出边缘计算场景下的若干类核心负载，最终形成边缘计算场景中的经典基准测试集。

4.动态调度

在云计算场景下，任务调度的一般策略是将计算密集型任务迁移到资源充足的计算节点上执行。 但是在边缘计算场景下，边缘设备产生的海量数据无法通过现有的带宽资源传输到云计算中心进行集中式计算，且不同边缘设备的计算、存储能力均不 相同，因此，边缘计算系统需要根据任务类型和边缘设备的计算能力进行动态调度。调度包括2个层面：

1） 云计算中心和边缘设备之前的调度；

2）边缘设备之间的调度。

云计算中心与边缘设备间的调度分为2种方式：自下而上和自上而下。自下而上是在网络边缘处将边缘设备采集或者产生的数据进行部分或者全部的预处理，过滤无用数据，以此降低传输带宽；自上而下是指将云计算中心所执行的复杂计算任务进行分割，然后分配给边缘设备执行，以此充分利用边缘设备的计算资源，减少整个计算系统的延迟和能耗。 2017年，Kang等人设计了一个轻量级的调度器 Neurosurgeon，它可以将深度神经网络不同层的计算任务在移动设备和数据中心间自动分配，使得移动设备功耗最多降低了 94.7%，系统延迟最多加快了40.7倍，并且数据中心的吞吐量最多增加了6. 7倍。边缘设备间也需要动态调度。边缘设备的计算、存储能力本身是不同的，并且会随着时间的变化而变化，而它们承担的任务类型也是不一样的，因此需要动态调度边缘设备上的任务，提高整体系统性能，防止出现计算任务调度到一个系统任务过载情况下的设备.Zhang等人针对延迟敏感性的社会感知任务设计了一个边缘任务调度框架C〇GTA，实验证明该框架可以满足应用和边缘设备的需求。

综上所述，动态调度的目标是为应用程序调度边缘设备上的计算资源，以实现数据传输开销最小化和应用程序执行性能的最大化。设计调度程序时应该考虑：任务是否可拆分可调度、调度应该采取什么策略、哪些任务需要调度等。动态调度需要在边缘设备能耗、计算延时、传输数据量、带宽等指标之间寻找最优平衡。根据目前的工作，如何设计和实现一种有效降低边缘设备任务执行延迟的动态调度策略是一个急需解决的问题。

5.和垂直行业紧密合作

在云计算场景下，不同行业的用户都可将数据传送至云计算中心，然后交由计算机从业人员进行数据的存储、管理和分析。云计算中心将数据抽象并提供访问接口给用户，这种模式下计算机从业人员与用户行业解耦和，他们更专注数据本身，不需对用户行业领域内知识做太多了解。

但是在边缘计算的场景下，边缘设备更贴近数据生产者，与垂直行业的关系更为密切，设计与实现边缘计算系统需要大量的领域专业知识。另一方面，垂直行业迫切需要利用边缘计算技术提高自身的竞争力，却面临计算机专业技术不足的问题。因此计算 机从业人员必须与垂直行业紧密合作，才能更好地完成任务，设计出下沉可用的计算系统。在与垂直行业进行合作时，需要着重解决3个问题：

1）减少与行业标准间的隔阂。在不同行业内部有经过多年积累的经验与标准，在边缘计算系统的设计中，需要与行业标准靠近，减少隔阂。例如，在针对自动驾驶汽车的研究中，自动驾驶任务的完成需要使用到智能算法、嵌人式 *** 作系统、车载计算硬件等各类计算机领域知识，这对于计算机从业人员而言是一个机遇，因此许多互联网公司投人资源进行研究。然而，若想研制符合行业标准的汽车，仅应用计算机领域知识是完全不够的，还需要对汽车领域专业知识有较好的理解，例如汽车动力系统、控制系统等，这就需要与传统汽车厂商进行紧密合作。同样，在智能制造、工业物联网等领域，同样需要设计下沉到领域内、符合行业标准的边缘计算系统。

2）完善数据保护和访问机制。在边缘计算中，需要与行业结合，在实现数据隐私保护的前提下设计统一、易用的数据共享和访问机制。由于不同行业具有的特殊性，许多行业不希望将数据上传至公有云，例如医院、公安机构等。而边缘计算的一大优势是数据存放在靠近数据生产者的边缘设备上，从而保证了数据隐私。但是这也导致了数据存储空间的多样性，不利于数据共享和访问。在传统云计算中，数据传输到云端 ，然后通过统一接口来访问，极大地方便了用户的使用。边缘计算需要借助这种优势来设计数据防护和访问机制。

3）提高互 *** 作性。边缘计算系统的设计需要易于结合行业内现有的系统，考虑到行业现状并进行利用，不要与现实脱节。例如在视频监控系统中，除了近些年出现的智能计算功能的摄像头，现实中仍然有大量的非智能摄像头，其每天仍然在采集大量的视频数据，并将数据传输至数据中心。学术界设计了A3系统，它利用了商店或者加油站中已有的计算设备。然而实际情况下，摄像头周边并不存在计算设备。因此，在边缘计算的研究中需要首先考虑如何部署在非智能的摄像头附近部署边缘计算设备。 在目前的解决方案中，多是采用建立更多的数据中心或AI—体机来进行处理，或者采用一些移动的设备，如各种单兵作战设备，来进行数据的采集。前者耗费巨大，且从本质来说，仍然是云计算的模式；后者通常使用于移动情况下，仅作为临时的计算中心，无法和云端进行交互。在视频监控领域，Luo等人提出了一个尚属于前期探讨的EdgeBox方案，其同时具备计算能力和通信能力，可以作为中间件插人到摄像头和数据中心之间，完成数据的预处理。 因此，如何与垂直行业紧密合作，设计出下沉可用的边缘计算系统，实现计算机与不同行业间的双赢是边缘计算面临的一个紧迫问题。

6.边缘节点落地问题

边缘计算的发展引起了工业界的广泛关注，但是在实际边缘节点的落地部署过程中，也涌现出一些急需解决的问题，例如应该如何建立适用于边缘计算的商业模式、如何选择参与计算的边缘节点和边缘计算数据、如何保证边缘节点的可靠性等。

1）新型商业模式。在云计算场景下，云计算公司是计算服务的提供者，它们收集、存储、管理数据并且负责软硬件、基础设施的建设和维护，用户付费购买服务，不需要关注计算节点本身的成本，也无需关注服务质量的升级换代过程。这种商业模式为用户使用云服务带来了便利，也让云计算公司具备盈利能力，从而更好地提高服务质量。

而在边缘计算场景下，边缘节点分布在靠近数据生产者的位置，在地理位置上具有较强的离散性，这使得边缘节点的统一性维护变得困难，同时也给软硬件升级带来了难度。例如提供安全服务的摄像头，在使用过程中需要进行软硬件的升级，软件的升级可以通过网络统一进行，而硬件的升级需要亲临现场。依赖于服务提供者去为每一个边缘节点（摄像头）进行硬件的升级和维护会带来巨大的成本开销，而服务的使用者一般不关注也不熟悉硬件设备的维护工作。又如，在CDN服务的应用中，需要考虑 CDN服务器是以家庭为单位还是以园区为单位配置，不同的配置方式会带来成本的变化，也为服务质量的稳定性增加了不确定因素，而维护CDN所需的开销，需要考虑支付者是服务提供者还是使用者。

因此工业界需要寻求一种或多种新的商业模式来明确边缘计算服务的提供者和使用者各自应该承担什么责任，例如谁来支付边缘节点建立和维护所需的费用、谁来主导软硬件升级的过程等。

2） 边缘节点的选择。边缘计算是一个连续统，边缘指从数据源到云计算中心路径之间的任意计算和网络资源。（在实际应用中，用户可以选择云到端整个链路上任意的边缘节点来降低延迟和带宽。由于边缘节点的计算能力、网络带宽的差异性，不同边缘节点的选择会导致计算延迟差异很大。现有的基础设施可以用作边缘节点，例如使用手持设备访问进行通信时，首先连接运营商基站，然后访问主干网络。这种以现有基础设施当做边缘节点的方式会加大延迟，如果手持设备能够绕过基站，直接访问主干网络的边缘节点，将会降低延迟。因此，如何选择合适的边缘节点以降低通信延迟和计算开销是一个重要的问题。在此过程中，需要考虑现有的基础设施如何与边缘节点融合，边缘计算技术会不会构建一个新兴的生态环境，给现有的基础设施发生革命性的变化？

3）边缘数据选择。边缘节点众多，产生的数据数量和类型也众多，这些数据间互有交集，针对一个问题往往有多个可供选择的解决方案。例如在路况实时监控应用中，既可以利用车上摄像头获得数据，也可以利用交通信号灯的实时数据统计，还可以利用路边计算单元进行车速计算。因此如何为特定应用合理地选择不同数据源的数据，以最大程度地降低延迟和带宽，提高服务的可用性是一个重要问题。

4）边缘节点的可靠性。边缘计算中的数据存储 和计算任务大多数依赖于边缘节点，不像云计算中心有稳定的基础设施保护，许多边缘节点暴露于自 然环境下，保证边缘节点的可靠性非常重要。例如， 基于计算机视觉的公共安全解决方案需要依赖智能摄像头进行存储和计算，然而在极端天气条件下，摄像头容易在物理上收到损害，例如暴风天气会改变摄像头的角度，暴雪天气会影响摄像头的视觉范围， 在此类场景中，需要借助基础设施的配合来保证边缘节点的物理可靠性。同时，边缘数据有时空特性，从而导致数据有较强的唯一性和不可恢复性，需要设计合理的多重备份机制来保证边缘节点的数据可靠性。因此，如何借助基础设施来保障边缘计算节点的物理可靠性和数据可靠性是一个重要的研究课题。

在边缘节点落地过程中，已经有了不少尝试，例如联通提出了建设边缘云，其规划至2020年建设6000~7000个边缘节点，将高带宽、低时延、本地化业务下沉到网络边缘，进一步提高网络效率、增强服务能力。因此针对如何选择边缘节点，处理好边缘节点与现有基础设施的关系，保证边缘节点的可靠性的研究非常紧迫。