《edge computing：vision and challenge》论文阅读

边缘计算的综述文章

---

前言

本文试图构建边缘计算的概念，首先分析为什么需要边缘计算，之后给出本文对于边缘计算的定义和看法，接着给出一些用例进行学习，如cloud offloading等，从细节执行方面解释边缘计算，最后给出一些可能的机遇和挑战。

---

一、对边缘计算的需求以及定义

（1）为什么需要边缘计算

网络的边缘产出的数据越来越多，因此直接在网络边缘处理数据是更加高效的选择（相比云计算）：
1.从云端传入边缘：云端的数据处理速度可以越来越快，但数据传输速度将成为云计算模式的瓶颈，网络带宽的需求将难以支撑。在边缘进行处理能获得更短的响应时间，更高效的处理，更小的网络压力。
2.从边缘传上云端：几乎所有的电子设备都会变成IoT的一部分，如空气监测仪，甚至麦克风，他们将既作为生产者，又作为消费者。可以推断未来数据会超过十亿级并越来越多，这会造成大量的数据根本无法传回云端。

上图展示了传统的云计算架构：生产者产出数据上传云端，消费者向云端发送使用数据的请求，云端将结果传回。然而在物联网中并不有效：（1）由于数据量太大（还杂），这种模式将造成巨大的网络带宽和计算资源的浪费；（2）隐私保护将是巨大挑战；（3）大多数IoT的终端节点是能量受限的（energy-constrained），而无线通信模式是非常耗能的，因此将计算任务offload到边缘节点会更加节省能源。
3.数据生产者与数据消费者角色的转换：首先，在云计算模式中终端设备通常作为数据消费者，如从YouTube上下载视频，但IoT中它可能同时作为生产者和消费者，角色的转变要求边缘更多的功能配置，举例：每分钟，油管用户会上传72h的新视频内容，脸书用户会上传250万个内容碎片，推特用户会发推近30万次，ins用户会po近22万个新照片。这些照片和视频非常庞大，如果直接上传会占用巨大的上载带宽，因此需要在边缘缩减和调整到合适的分辨率再上传。

（2）边缘计算是什么？

定义“边缘”为沿着数据源和云端数据中心路径上的计算和网络资源。比如手机就是身体与云间的“边缘。”
边缘计算的基本准则是计算应该发生在接近数据源的地方。
与雾计算：作者认为边缘计算和雾计算是可以相互转换（interchangeable）的。但边缘计算更聚焦于“things”端，雾计算更聚焦于基础设施端。作者认为边缘计算在未来会对人类社会产生和云计算一样巨大的影响。
下图展示了边缘计算的两种计算流（computing stream）。在边缘，things既是数据生产者，又是数据消费者。things不止向云端请求服务和内容，也执行一些来自云端的计算任务，比如计算卸载（offloading）、数据存储、缓存（cache）和处理、从云端向用户分发请求和运送服务。因此边缘需要满足可靠性、安全性和隐私保护等要求。

（3）边缘计算的好处

边缘计算期望将计算任务放在靠近数据源的地方进行。作者列举了来自社区的一些早期结果来说明益处，主要包括以下两方面：
1.响应时间的减少
2.能源消耗的减少

二、案例学习

1.云卸载（ Cloud Offloading）

在边缘计算中，边缘拥有确定的计算资源，这为“将一部分工作负载从云端卸载”提供了一个机会。Cloud Offloading是一种能源和性能表现的权衡（energy-performance tradeoff）
不同于传统模式中边缘服务器只缓存数据，边缘计算模式中数据和应用在数据上的操作（operations）也会缓存到边缘上。在物联网中，边缘既是生产者又是消费者。
举例一是在线购物服务。用户可能会频繁操作购物车，默认购物车的改变都在云端进行，那么生成新的购物车视图将花费大量的时间，具体取决于网络速度和服务器负载。如果是移动设备则时间开销会更长，因为移动网络带宽更低。
在此场景下，如果将购物车更新卸载到边缘节点，那么延迟将会dramatically reduced。如前所述，用户的购物车数据和相关操作（加减商品项等）会缓存到边缘节点，当用户请求抵达边缘节点，新的购物车视图可以立即生成。当然，边缘节点缓存的数据需要与云端同步，但这可以在后台进行 。
另一个问题是边缘节点间的协作，当用户从一个边缘节点移动到另一个边缘节点。一个可能的方案是将数据缓存到用户可能到达的所有边缘节点。
综上，基于边缘计算，时间敏感的应用的延迟和用户持续性体验将得到显著地提升。

2.视频分析（ Video Analytics）

由于冗长的数据传输延迟和隐私问题，云计算已经不再适用于需要视频分析的应用。就算数据能够到达云端，上载和对巨量的数据进行分析也会花很长时间。在边缘计算中，云端只用生成请求并将其push到目标区域的所有“things”上，这些things可以执行分析请求，只讲结果传回云端。在这种模式下我们可以利用每一个thing的数据和计算能源，并且更快的得到分析结果。

5.边缘协作（ Collaborative Edge）

云已经成为学术界和工业界事实上的大数据处理计算平台。它有一个关键条件是数据已经被云端拥有或者能够被传上云端进行处理。但由于隐私问题和太大的数据传输开销，拥有数据的利益相关者彼此间通常不愿意共享数据。
协同边缘(Collaborative edge)技术被提出，该技术将地理分布的多个利益相关者的边缘连接起来，而不受其物理位置和网络结构的影响。这些类似点对点的互连边缘节点为利益相关者提供了共享和合作数据的机会。
协同边缘通过创建虚拟化共享数据视图为地理上分散的数据安全加上保险。终端用户通过一个预定义的服务接口访问虚拟化的共享数据，应用利用这些公共接口为终端用户完成复杂的服务，这些接口是由协同边缘的参与者提供的，具体的计算只发生在相应参与者自身的设备上，这样隐私安全就得到了保障。
大多数参与者都可以从协同边缘中受益，从而降低运营成本和提高盈利能力。

---

三、机遇和挑战

1.可编程性（ Programmability）

云计算优势之一：基础结构（infrastructure）对用户来说是透明（transparent）的。用户将程序部署到云端，由云提供者决定程序如何运行。通常程序只用一种语言编写，并为特定的目标平台编译，因为程序只会在云上运行。
但边缘计算中，计算由边缘节点完成，而边缘节点大多都是异构（ heterogeneous）平台，他们的运行时间（runtime）不同，程序员在编写部署到edge的应用程序时面临巨大的挑战。
为了解决可编程性问题，作者提出了 computing stream的概念：沿着数据传播（ propagation）路径上一系列应用到数据上的功能/计算（ functions/computing）。功能/计算可以是应用程序的全部或部分功能，只要应用程序定义了计算应该在哪里进行，计算就可以发生在路径的任何地方。computing stream是软件定义的计算流，这样可以在数据生成设备、边缘节点和云环境上以分布式和高效的方式处理数据。根据边缘计算的定义，很多计算可以在边缘而不是中心云上完成。在这种情况下，计算流可以帮助用户确定应该执行哪些功能/计算，以及在边缘发生计算后数据如何传播。功能/计算的分布式度量可以是延迟驱动的、或者能源成本、TCO和硬件/软件的具体限制。详细讨论在6.优化指标。
在计算流中，功能可以被重新分配，与功能一起的数据和状态（state）也应该被重新分配。此外，协作问题(例如，同步、数据/状态迁移等)必须在边缘计算模式的多个层中进行处理。

2.命名（naming）

每一层在特定的消息中都需要一种机制来标识发送方和接收方，这种机制在下层叫寻址，上层叫命名。
在边缘节点的顶部，有很多应用程序在运行，每个应用程序都有自己的关于服务如何提供的结构。与所有的计算机系统一样，边缘计算中的命名方案对编程、寻址、事物识别和数据通信都非常重要。边缘计算的命名方案需要处理事物的流动性、高度动态的网络拓扑、隐私和安全保护，以及针对大量不可靠事物的可伸缩性。
传统的命名机制 如DNS何 uniform resource identifier能够很好的满足大部分网络的要求，但它们对于边缘网络来说不够灵活，因为边缘中的things是高度移动性（highly mobile）和资源受限的。此外，对于网络边缘的一些资源受限的things，基于IP的命名方案可能过于沉重，无法支持，因为其复杂性和开销。
两种新的命名机制可以用于边缘网络： named data networking (NDN)和 MobilityFirst。
（1）NDN：它为以内容/数据为中心的网络提供了一个层次结构的名称，对业务管理具有人性化的特点，并为边缘提供了良好的可扩展性。然而，它需要额外的代理来适应其他通信协议，如蓝牙或ZigBee等。与NDN相关的另一个问题是安全性，因为它很难将硬件信息与服务提供商隔离开来。
（2）MobileFirst：它可以将命名与网络地址分离，以提供更好的移动性（ mobility）支持，如果应用于具有高度移动性的边缘服务，将会非常高效。但是，命名时需要使用的是MobileFirst的全局唯一标识(GUID)，而在家庭环境等网络边缘的相关固定信息聚合服务中，GUID是不需要的。MobileFirst的另一个缺点是GUID不人性化，服务管理困难。
对于一个相对较小和固定的边缘网络，如家庭环境（home environment），有一种可能的解决方案是：让edgeOS为每个thing分配网络地址。在单个系统中，每个thing都可以有一个独特的、人性化的命名，描述了以下信息:location (where), role (who), and data description(what)，例如，“kitchen.oven2.temperature3”。然后edgeOS会给这个thing分配标识符和网络地址，如下图所示：
这个人性化的名称对于每个thing都是唯一的，它将用于服务管理、事物诊断和组件替换。对于用户和服务提供者，这种命名机制使管理变得非常容易。此外，这种命名机制为服务提供商提供了更好的可编程性，同时阻止了服务提供商获取硬件信息，更好地保护了数据的隐私性和安全性。唯一标识符和网络地址可以从人性化的命名中映射。标识符可以用于 edgeOS的things管理，而网络地址，如IP地址或MAC地址，将被用来支持各种通信协议，如蓝牙、ZigBee或WiFi等。对于高度动态的环境，如城市级系统，我们认为这仍然是一个开放的问题，值得社区进一步研究。

6.优化指标（ Optimization Metrics）

在边缘计算中，我们有多个具有不同计算能力的层，这使得工作负载分配（ workload allocation）成为一个大问题。我们需要决定哪一层来处理工作负载，或者在每个部分分配多少任务。为了选择最优分配策略，我们将在本节中讨论几个优化指标，包括延迟、带宽、能源和成本（cost）。
（1）延迟（latency）：延迟是评估性能的最重要指标之一，尤其是在交互应用程序/服务中。云计算拥有高计算能力，但延迟并不仅由计算时间决定 。Long WAN delays会极大地影响实时/交互密集型应用程序的表现。为了减少延迟，工作负载最好在距离最近的层完成，该层须具有相对网络边缘的things来说足够的计算能力。但最近一层并不总是最优选择，我们需要考虑资源使用信息，以避免不必要的等待时间，以便找到一个逻辑上最优层。
（2）带宽（Bandwidth）：从延迟的角度来看，高带宽可以减少传输时间，特别是对于大数据(如视频等)。对于短距离传输，我们可以建立高带宽无线接入，将数据发送到边缘。一方面，如果工作负载可以在边缘处理，那么与在云上工作相比，这种更短距离传输的延迟可以大大改善，同时也节省了边缘和云之间的带宽。而且，由于传输路径短，传输可靠性也得到了提高。另一方面，就算边缘不能满足计算需求，虽然不能减少传输距离，但至少在边缘对数据进行了预处理，上传数据的大小会显著减小。因此，我们需要评估是否需要高带宽连接，以及边缘适合哪种速度。在分配工作负载时，需要分层考虑计算能力和带宽使用信息，以避免竞争（ competition）和延迟。
（3）能源（Energy）：对于网络边缘的thing来说，电池（battery）是最珍贵的能源。对于endpoint layers，将工作负载卸载到edge是一种能源无耗的做法。那么对于一个给定的工作负载，将其 offload到边缘是否比直接在本地计算（compute locally）更节能？关键是计算能源消耗（computing energy consumption）和传输能源消耗（transmission energy consumption）间的权衡。通常，我们需要首先考虑工作负载的功率特性（power characteristics），它是否是计算密集型（computation intensive）的？本地运行需要消耗多少资源？除了网络信号强度（network signal strength），数据大小以及可用带宽也会影响传输能源开销。只有当传输能源开销比本地运算小时，我们才会倾向于使用边缘计算。然而如果我们考虑整个边缘计算过程的能源消耗而不是只考虑端点能源消耗时，最优分配策略会发生变化。总体能源消耗应该是每个使用到的层的能源消耗的累加，和端点层类似，其余每层的能源消耗可以用本地计算开销和传输开销之和估计。举例，当本地数据中心繁忙时，工作负载会被持续上传到更高一层，和本地计算相比，多跳传输会引起更多的能源消耗，显著的增加开销（overhead）。
（4）成本（cost）：从服务提供商（如YouTube、Amazon等）的角度来看，边缘计算为他们提供了更少的延迟和能耗，潜在的吞吐量增加和用户体验改善。因此，处理同等单位的工作负载他们能赚取更多的钱。例如，基于大多数居民的兴趣，我们可以在建筑层（ building layer）边缘放置一段流行视频。城市层（ city layer）边缘可以摆脱此任务，并处理更复杂的工作，总吞吐量可以增加。服务提供商的投资是在每一层中构建和维护things的成本（cost）。为了充分利用每一层中的本地数据，提供商可以根据数据位置向用户收费。因此需要开发新的cost模型，以保证服务提供商的利润和用户的可接受性。

---

四、总结和附录

本文提出了对边缘计算的理解，其基本原理是计算应在数据源附近进行。然后，本文列举了一些案例进行分析，最后，提出了值得研究的挑战和机遇，包括可编程性、命名、数据抽象、服务管理、隐私和安全以及优化指标。
fog computing：(2016). OpenFog Architecture Overview. OpenFog Consortium Architecture Working Group. Accessed on Dec. 7, 2016. [Online]. Available: http://www.openfogconsortium.org/wp-content/ uploads/OpenFog-Architecture-Overview-WP-2-2016.pdf
cloudlet：DOI: 10.1109/mprv.2009.82
The Case for VM-Based Cloudlets in Mobile Computing