下载掌阅APP，畅读海量书库
立即打开
现在，我们已经对云中心、边缘服务器和终端设备的特点有了深入的认识。需要注意的是，边缘计算架构不仅包含这三大架构要素，而且还涉及底层网络基础设施、服务中间件和应用程序管理框架等 [6] 。图2-1展示了边缘计算的通用分层架构。以云计算范式为中心的云层位于架构的最上层，云中心拥有大量的计算、存储和网络资源，能够满足各种服务的需求。边缘层靠近数据生成端或消费端，包含多种由边缘服务器组成的节点集群，并通过Internet网关与云层建立连接 [5] 。最底层的感知层由海量且异构的终端设备或物联网传感器组成，它们一般借助网络层提供的多种通信协议接入边缘层。
从上述的通用分层架构可以看出，边缘计算与云计算存在密不可分的联系。两者之间的协同揭示了边缘架构的基本运行原理，即边缘场景中延迟敏感的计算任务往往由靠近数据端的边缘服务器处理，而云中心则负责处理在多种不同场景中共享的全局性计算和存储任务。边缘计算的基础设施、服务对象、用户需求和系统挑战并不是一成不变的，所以通用分层架构在不同的应用场景中往往表现各异，大致可以分为云-边-端架构、边-端架构、端-端架构和其他架构。接下来，我们将结合边缘架构、三大架构要素和应用场景的特点对它们进行详细讨论。
图2-1 边缘计算通用分层架构
如图2-2所示，云-边-端架构本质上就是包含云层、边缘层和感知层的通用架构，它可以应对边缘计算的大部分应用场景。三层架构将原本位于终端设备的本地计算转变为位于边缘服务器或者云中心的边缘计算，在这个过程中边缘服务器可能需要频繁与云中心进行通信。为了能够充分利用云中心强大的处理能力，边缘服务器大多位于网络边缘而不是设备边缘。正如第2.2节所讨论的那样，位于网络边缘（本地边缘）的服务器拥有比设备边缘更多的各类资源，这将有利于加强边缘层对终端设备的管理。在云-边-端架构中，终端设备首先会通过接入网向本地边缘服务器发起请求，若本地边缘服务器无法处理则会将请求转发至云中心。
图2-2 云-边-端架构示意图
让我们通过一个具体的例子进一步理解云-边-端架构的特点。在移动边缘计算中，分布广泛的移动基站不仅可以构建无线广域网以满足智能手机等终端设备的通信需求，而且还可以作为本地边缘服务器来提供相应的计算服务 [7] 。智能手机、移动基站和云服务供应商等共同构成了云-边-端硬件架构 [8] 。若在距离更近的移动基站上处理服务请求，那么将获得较低的传输延迟。若将任务卸载至云服务供应商，那么任务计算时间将显著下降。很显然这两种方式具有各自的优缺点，云-边-端架构旨在通过计算任务卸载来最小化服务请求的总延迟。边缘架构是一种面向“能力”的架构，边缘服务器和云中心凭借各自的“能力”和方式为终端设备提供服务。是否将任务卸载至云中心对终端设备往往是透明的，只要实现所规定的QoS即可。一般来说，延迟要求极低的应用、具有隐私要求的业务、实时性推理任务和频繁的计算请求通常在边缘服务器上处理，而计算复杂度高、数据量大且运行周期长的任务应该被卸载至云中心。
云-边-端架构中存在两种关键的协同机制，即云-边协同和云-边-端协同。云-边协同强调的是云和边在资源上的协同，而云-边-端协同必须以云-边协同为基础，强调的是云通过控制边来影响端。接下来我们将依次介绍这两种协同机制的原理。
1.云-边协同
在云-边-端架构中，云-边协同旨在整合云中心和边缘服务器的基础设施、数据和应用等多种资源。云计算架构和服务的发展很显然比边缘计算更加成熟，云-边-端架构中边缘层的设计也极大地受到云层的启发。因此，云中心往往是云-边协同的主导者。协同的最终目标是实现高效的服务供应，这意味着云和边在资源上的协同将不可避免地受到云计算服务供应的显著影响。云-边协同因具体的服务供应方式而异，主要有以下两种情况：
❑当云中心通过IaaS方式为用户提供服务时，云-边协同主要指的是云和边在基础设施方面的互补。在这种协同模式下，云中心负责对云-边基础设施中所有计算、存储和网络等资源进行综合管理、高效配置和调度优化。同时，IaaS在云和边之间还存在明确的分工。云中心大多面向大范围的延迟容忍性业务，而边缘服务器大多面向区域受限的延迟敏感性业务。边缘计算和云计算在基础设施层面的协同为PaaS的协同提供了基础。
❑当云中心通过PaaS方式为用户提供服务时，云-边协同主要指的是云和边在数据以及应用方面的互补。在这种协同模式下，云中心负责将云-边包含的所有数据和应用以单个统一的视图提供给用户或终端设备。同时，PaaS在云和边上的表现也是不同的。云中心大多提供长周期、非实时、全局的数据和应用分析服务，而边缘服务器大多提供短周期智能应用、实时性数据分析和面向场景的资源配置等服务。
注意 云-边协同也可以看成云层IaaS、PaaS和边缘层IaaS、PaaS在服务供应方面的协同。虽然云-边协同关注IaaS和PaaS两种方式，但是实际的边缘服务器大多采用FaaS方式。
接下来我们简单介绍云-边协同的具体实现过程。从IaaS和PaaS等服务供应的角度来看，云-边协同是一种典型的资源协同。在实际的云-边-端架构中，资源协同具体表现为云计算容器化应用的下沉和云原生应用的部署。从云层的角度来看，资源协同意味着通过云中心的编排功能将部分应用下移至边缘网络，这些应用往往以容器的形式向用户提供服务。在这个过程中，云层扮演控制平面的角色而边缘层是单纯的计算平台，云中心可以像对待普通云节点那样管理边缘服务器。从边缘层的角度来看，资源协同要求将云原生应用合理地部署在边缘服务器上，在部署过程中应该重点关注边缘应用的运行效率。因为边缘服务器往往具有计算资源受限和网络环境复杂多变等特点，所以部署云原生应用时必须根据具体场景对云层组件进行适当裁剪和定制化。
2.云-边-端协同
云-边协同将云中心和边缘服务器的基础设施、数据和应用等多种资源整合起来，为云-边-端协同提供了基础。为了实现服务供应和计算任务卸载，边缘服务器需要对终端设备进行有效管理和控制。因此，边缘层上通常运行着与终端设备管理服务相对应的工作负载。云中心的控制节点首先向由边缘服务器组成的节点集群下发指令，然后通过边缘层上的服务管理程序来影响对应终端设备的行为。云通过控制边来影响端，这样便实现了云-边-端协同。需要注意的是，在云-边-端架构的具体场景中，终端设备一般不会直接与云中心交互，而是通过边缘服务器发送服务请求或者获取处理结果。
如图2-3所示，边-端架构仅包含通用分层架构中的边缘层和感知层（以及网络层），也被称为两层边缘架构。在边-端架构中，边缘层完全脱离了云层的控制，服务供应方式由云-边协同和云-边-端协同转变为边-端协同。边缘服务器不会通过Internet网关与云中心通信，它必须独立应对终端设备的服务请求。这种架构一般常见于服务需求高度定制化的边缘场景，例如大学校园网、工业园区网和企业内部网等。这些场景非常注重数据隐私和通信安全，并且具有确定的服务对象和服务类型。另外，延迟敏感的新型应用也大多被部署在边-端架构中，无须与云中心进行通信，从而避免可能出现的高延迟。综上所述，我们可以看出边-端架构往往由边缘场景的具体特点决定，边缘服务器的服务配置直接受到定制化需求和应用类型的影响。边-端架构和边缘场景之间紧密的联系再次印证了边缘计算是位于“上下文”中的计算。
图2-3 边-端架构示意图
在边-端架构中，边缘服务器可能位于网络边缘，也可能位于设备边缘。面向服务需求高度定制化的场景时，边缘服务器大多位于网络边缘并拥有相对较多的计算和存储资源。这种情况下通常需要在网络边缘部署密集的服务器集群，从而满足各种定制化的服务需求。面向延迟敏感的新型应用场景时，边缘服务器大多位于与终端设备距离更近的设备边缘。其目的是尽可能靠近数据端以实现低延迟的服务供应，这种新型应用往往不需要消耗太多算力。无论位于网络边缘还是设备边缘，边缘服务器之间通常存在大规模的协同。当单个边缘服务器没有足够的能力处理终端设备的服务请求或者不具备对应的服务类型时，多个边缘服务器可以构成小型网络以实现协同运算。此时，所有边缘服务器都是运算节点，与终端设备进行交互的那个被称为接入节点。
接下来我们将介绍边-端架构的一个显著特点，即边-端协同。与云-边-端架构中的云-边协同类似，边缘层的边缘服务器与感知层的终端设备之间同样存在协同。以IoT为例，边-端协同表现为边缘服务器对终端设备的管理和控制，以及终端设备与边缘服务器之间的通信两个方面。边缘服务器依托边缘层管理平台和IoT软件即服务（Software as a Service, SaaS）平台间接控制终端设备。IoT SaaS平台上部署着与海量异构终端设备相对应的微服务，该平台通过微服务获取并处理终端设备采集的实时数据。IoT SaaS平台还可以通过微服务下发控制指令，从而实现对终端设备的高效管理。边缘层管理平台负责管理所有软硬件资源，同时监视边缘服务器的运行状态、应用负载和故障情况。边缘层管理平台向IoT SaaS平台的微服务提供必需的计算资源，并通过IoT SaaS平台管理这些服务的整个生命周期。终端设备与边缘服务器之间的通信管道是基于代理实现的，代理通常支持多种标准的网络通信协议。一方面，终端设备采集的数据可以通过管道上传至代理所对应的边缘服务器。另一方面，控制指令也借助代理管道下发到终端设备。
实际上，实现边-端协同的关键在于中间件。需要注意的是，边缘计算中间件与云计算中间件存在较大区别。在云计算中，中间件是云中心与上层应用之间的桥梁，同时也是各种服务供应的基础。为了实现这个目标，中间件必须高效整合云中心的各种软硬件资源，其核心目标是实现高效资源管理。云中间件将通用资源和物理环境解耦，并向上层应用提供统一规范的接口。边缘计算范式与具体的边缘场景相联系，需要考虑终端设备的特点，所以中间件的目标有所不同。终端设备大多具有异构性、分布广泛和位置不固定等特点，有必要通过透明方式实现服务供应，从而屏蔽底层设备的复杂性。由此可见，边缘中间件的核心目标是实现终端设备和各类硬件的抽象，同时为计算、通信、数据管理和隐私安全等服务提供通用的API。另外，边缘中间件还负责终端设备与边缘服务器之间的交互，例如在IoT中边缘服务器可以通过代理与终端设备进行通信。综上所述，云中间件侧重管理云中心的各种资源，而边缘中间件侧重对终端设备进行抽象。另外，云-边-端架构中云-边-端协同的实现同样离不开边缘中间件。
如图2-4所示，端-端架构由通用分层架构的感知层要素组成。这种架构大多面向远离云中心、主干网和基站的户外作业场景，因此缺少通用的边缘服务器和网络层基础设施。由于网络环境恶劣且各类资源极度受限，所以传统的边-端架构或云-边-端架构无法应对。在这类场景中，端-端架构是唯一且被迫的选择。端-端架构的两个“端”指的都是终端设备。通过设备直连或多跳通信等方式可以在多个设备之间构建自组网，最终实现分布式边缘计算的基础网络设施。特别地，单个终端设备可以将难以处理的高计算复杂性任务卸载至由其他终端设备组成的边缘网络。在边缘网络中，多个终端设备通过协同运算的方式为该任务提供所需的算力。在端-端架构中，终端设备既能进行任务卸载也会成为其他终端设备的边缘服务器，边与端的界限变得较为模糊。
图2-4 端-端架构示意图
注意 端-端架构是由多个终端设备组成的分布式计算架构，也被称为泛在边缘架构。在这种架构中，终端设备可以充当“边缘服务器”，它位于设备边缘，即设备边缘服务器。
端-端架构具备简单灵活、方便快捷、通信延迟低和可扩展性高等特点。终端设备无法与云中心或本地边缘服务器取得联系，必须借助其他终端设备实现特定场景下的任务卸载。在这个过程中，设计高效的分布式协议来管理边缘网络中各类资源和服务的全局信息是十分关键的。考虑到户外环境复杂和设备电源有限等特点，端-端架构往往使用长距离（Long Range, LoRa）通信技术等低功耗广域网通信协议 [9] 。另外，端-端架构还需要解决邻居发现和服务搜索等问题。
除了上述讨论的云-边-端架构、边-端架构和端-端架构等几种常见的边缘架构，人工智能（Artificial Intelligence, AI）、IoT和卫星网络等领域的边缘架构也不断涌现。AIoT（AI of Things）架构强调AI和IoT的结合，它旨在通过规范终端设备和AI基础产品来提高边缘任务的处理效率。卫星边缘架构旨在充分发挥低轨卫星在遥感和导航等领域的巨大价值，它借助边缘计算为终端设备提供实时的网络服务和强大的计算能力。接下来，我们将详细介绍它们。
1.AIoT架构
边缘计算极大地扩展了云计算的应用场景，同时也推动了IoT和AI的快速发展。从这个角度来看，AIoT架构的诞生似乎是必然的。另外，该架构与边缘分析存在紧密联系。边缘分析将AI应用部署在数据源头并充分利用边缘端的计算资源，从而降低服务延迟并增强IoT的能力。AIoT架构的提出很好地满足了这一愿景，其核心思想就是在智能网关上处理IoT产生的实时流式数据以减少云中心的数据流量 [10] 。
如图2-5所示，AIoT架构本质上是一种特殊的云-边-端架构，它包含海量异构的IoT设备（终端设备）、提供网络接入服务的AIoT智能网关（边缘服务器）和拥有大量资源的边缘智能管理平台（云中心）。AIoT智能网关和IoT设备之间存在密切的边-端协同，其目的是屏蔽设备的多样性并规范设备的行为以便高效地处理各类实时计算请求。AIoT架构目前已经得到腾讯、阿里和小米等多个云服务提供商的支持，相关开发人员也搭建了负责AIoT设备管理和AI基础产品分发的云中心 [11] 。云中心带来了灵活可靠的计算、存储和网络资源，使得边缘智能管理平台支持各种不同的AIoT产品成为可能。云中心还可以利用来自IoT设备的海量实时数据训练更优的神经网络模型。为了在靠近IoT设备的位置部署计算能力，智能网关必须运行经过修剪或压缩的轻量级神经网络模型 [12] 。另外，应用数据大多可以被处理成紧凑的结构化形式，显著降低了网络带宽消耗。
注意 传统云-边-端架构中不同边缘服务器之间普遍存在协同现象，且云-边协同整合了所有资源并提供了一个统一的视图。与此不同的是，AIoT架构中智能网关需要独立应对服务请求并高效运行AI应用，更多情况下云中心仅负责设备管理、产品分发和规则更新。
图2-5 AIoT架构示意图
2.卫星边缘架构
从边缘计算发生的地理环境来看，卫星边缘架构是对传统边缘架构的补充和延伸。对于悬崖、陡坡和山谷等极端地形或者通信成本较高的偏远地区来说，部署大量陆地网络基础设施是不切实际的 [13] 。为了突破地形的限制并增强网络设施对自然灾害的抵抗能力，构建卫星网络系统十分必要。另外，云计算和边缘计算等技术的发展使基于卫星的服务供应成为可能，终端设备必须快速获取实时的遥感图像和导航数据。在这种背景下，卫星边缘架构应运而生。
如图2-6所示，卫星边缘架构实际上是一种特殊的边-端架构，多个低轨卫星（边缘服务器）和终端设备共同构成了卫星网络的基础设施。不同于同步卫星，位于近地轨道的卫星与位于地面的终端设备并不是相对静止的。卫星运动和地球自转导致它们的相对位置发生周期性的变化，卫星边缘架构设计必须考虑这种移动性。在实际的场景中，终端设备倾向于将任务上传至多个卫星节点以确保能够及时得到处理结果。需要注意的是，这种方式与传统边-端架构的多接入边缘计算有所不同。
注意 传统边-端架构中边缘服务器的位置通常是固定的，多个协同的边缘服务器组成运算网络，从而为具有移动性的终端设备提供服务。与此不同的是，卫星边缘架构中不同边缘服务器之间以及边缘服务器与终端设备之间的相对位置都会发生周期性的变化。在这种场景中，传统边-端架构的协同运算方式将完全失效。
图2-6 卫星边缘架构示意图
在卫星边缘架构中，周期性移动对终端设备和卫星节点之间的任务匹配以及通信链路造成了显著影响。基于卫星协同的边缘计算已经得到研究人员的广泛关注，接下来我们将介绍两种典型的协同运算方式：
❑卫星流水线协同。这种协同方式主要面向实时性要求较高的地面图像处理任务。在这个过程中，低轨卫星根据终端设备发出的任务指令对覆盖范围内采集的图像进行处理。然而，与较大的覆盖范围相比，低轨卫星的计算能力稍显不足。同时，周期性的移动导致单个卫星难以及时处理这些图像。卫星流水线协同旨在对需要采集的图像范围进行分割，由多个在位置上连续的卫星节点依次处理。每个卫星在处理前一个任务的同时也会采集部分图像交给后一个卫星处理，从而实现高效的流水线和并发运算。
❑动态星团协同。这种协同方式主要面向数据通信量较大的高复杂性任务。在这个过程中，终端设备向低轨卫星提交具有截止时间的计算请求，并且需要批次传输大量的输入数据。为了限时完成高负载的计算任务，一定数量的卫星节点将会被编入动态星团中。动态星团协同包括负责分发计算任务的协调节点和负责返回处理结果的汇聚节点。这种协同运算网络的规模是根据任务类型动态确定的，相对位置的变化导致其协同机制比传统集群更为复杂。