2.3　软件计算架构

软件架构的作用是将边缘计算架构中的各个实体有机组合起来，并最终将硬件计算资源转化为各类计算服务提供给边缘计算前端用户和开发者。按照云计算服务模式，由软件架构提供的计算服务可以分为IaaS、PaaS、SaaS以及更细粒度的FaaS。在边缘计算中，边缘资源同样会转化为这几种形式为前端设备提供服务。考虑到边缘系统架构的特点，实现边缘计算服务的软件架构与云计算相比有所不同。

2.3.1　一般边缘计算软件架构

边缘计算的软件系统架构是将上述介绍的边缘计算中各类实体硬件有机组织起来，从而以便捷、高效的方式为前端设备提供计算服务。前端用户通过各类通信标准（移动蜂窝网络、蓝牙/Wi-Fi/ZigBee个域网、NB-IoT/LoRa广域网等）接入边缘网络后，会被分配到各边缘服务器上进行运算。对于多数两层或三层的边缘计算硬件架构，运行其上的软件架构是类似的，主要包含基础设施层和平台管理层（如图2-8所示）。其中基础设施层直接负责各类硬件资源和设备的组织与虚拟化，为应用提供通用、统一的资源使用和分配方法。而平台管理层则是在物理资源之上，提供IaaS、PaaS和SaaS的服务实现。

1. 基础设施层

基础设施层主要分为硬件资源和虚拟层两部分，在这两部分基础上，边缘计算基础设施管理系统能够整合所有的硬件资源形成一个稳定、通用的运行环境，使得上层的边缘服务可以在这个环境中被部署、执行和管理。

硬件资源指各边缘服务器上配备的计算资源、存储资源和网络资源。通用服务器有较好的性能，价格相对低廉。存储硬件提供存储能力，存储节点可以是网络附加存储（Network Attached Storage）和存储区域网络（Storage Area Network）等存储方式。网络通信资源则包括交换机和路由器等设备。这些硬件资源根据采用的硬件架构不同会有不同的配置，一般部署在网络接入设备以及用户驻地网络等，通过虚拟层为边缘服务提供处理、存储和数据传输功能。

考虑到边缘服务对硬件需求的多样性，在通用硬件上直接实现各类边缘计算服务几乎是不可能的，而配置大量异构的硬件设备也会带来难以承受的硬件和维护成本。此外，考虑到用户的移动性和需求的动态性，专用硬件资源难以满足动态多变的用户请求。因此，在边缘计算的基础设施层，需要对硬件资源进行抽象，在真实的硬件之上建立虚拟化网络资源，对边缘服务所需的软件和底层硬件进行解耦，保证各类服务可以成功部署在底层物理资源上。虚拟化的典型解决方案包括以操作系统为中心的Hypervisor虚拟化方案和以应用程序为中心的Container虚拟化方案。本书将在第5章展开介绍虚拟化技术。

2. 平台管理层

边缘计算平台管理层建立在虚拟化资源之上，将硬件资源、平台和软件转变为IaaS、PaaS和SaaS服务。具体而言，平台管理层包含虚拟化资源管理和边缘应用服务平台，将网络中的资源分配给不同的服务，提供边缘服务的运行和管理。

虚拟化资源管理负责将虚拟化后的硬件资源灵活、高效地分配给边缘场景中的各个服务用户。根据边缘场景中用户所需服务的类型（如传输密集型、计算密集型和存储密集型）将资源按需分配给不同的应用，同时考虑用户移动性、需求变化以及网络环境等多种因素来灵活调度资源。资源的恰当分配直接影响边缘服务器的资源利用率，这是控制边缘成本、优化用户体验的关键环节。

边缘计算应用服务平台向上直接为用户提供计算卸载和服务使用的接口，向下负责注册、管理边缘服务。边缘应用服务平台通过一系列中间件实现，通常包括通信服务模块、服务注册模块、无线网络信息服务模块以及流量卸载模块。

• 服务注册模块：服务注册模块整合各个边缘计算服务的相关信息，包括服务相关接口、版本信息和服务状态（可用性）等。前端应用程序可以根据计算任务的需求特点选择调用相应的服务。
• 通信服务模块：通信服务模块负责通过事先定义好的API（Application Programming Interface），建立运行在虚拟机上的应用程序与边缘应用服务平台之间的相互通信，以支持平台管理层为应用程序生命周期提供相关支持，如应用程序所需的资源、最大容忍延迟等。
• 流量卸载模块：该模块通过监测、分析无线网络和用户信息，对用户请求和数据流量进行优先级排序。该优先级主要用于边缘服务器对前端用户的信道资源分配以及边缘网络中的链路资源分配。
• 无线网络信息服务模块：无线网络信息服务模块负责记录无线网络的实时状态以及用户端设备的相关信息。无线网络实时状态包括蜂窝网小区ID、小区当前负载、上行和下行可用带宽等，用户端设备信息包括用户位置、用户吞吐量、用户相关服务质量、已建立的无线连接等。考虑到边缘网络中的前端任务卸载直接受到网络状况的影响，无线网络信息服务对网络状态的刻画有助于用户做出最恰当的计算卸载决策，节省通信与计算资源。

2.3.2　多接入边缘计算架构

2016年，欧洲电信标准化协会（European Telecommunications Standards Institute，ETSI）将边缘网络的称谓由移动边缘计算更名为多接入边缘计算。在多接入边缘计算架构中，用户可以在接入不同网络的情况下共享边缘资源，也可以通过切换不同的接入方式提高边缘计算的服务质量。ETSI给出的多接入边缘计算架构如图2-9所示。

与一般边缘计算架构类似，多接入边缘计算架构同样包含基础设施层和平台管理层。其中基础设施层着重强调各个边缘服务器通过相互之间的链接构成边缘服务网络，通过大量、密集的边缘服务器形成的网络整体为前端的海量用户提供服务。平台管理层从应用程序的生命周期出发，为边缘服务提供基本功能集合并制定应用程序管理规则，在多接入的场景中着重强调服务授权、流量规则、解决冲突和DNS配置等方案。

与一般边缘计算架构不同的是，多接入边缘计算架构单独剥离了多接入边缘协调器（Multi-Access Edge Orchestrator）。该模块作为多接入边缘网络框架中的核心模块之一，负责服务器组网、管理及分配硬件资源、边缘服务实例的部署、协调边缘用户请求的服务路径、卸载任务在多边缘服务器中的分配等。具体包括以下功能：

①管理终端用户卸载决策。此模块作为多接入网络核心模块，负责调度用户请求。主要从两个方面协调用户的请求：

• 通过服务部署与请求调度来应对用户请求。当用户请求某一特定服务的时候，协调器须将请求路由到相应的服务器上。由于多接入场景存在多个可选的服务器，因此需要根据服务评价指标（如最大容忍的卸载端到端时延）灵活地协调所有用户的请求。用户的卸载端到端时延包括无线传输时延、边缘服务器网内传输时延和服务器处理时延。因此协调策略可分为三个部分：无线接入节点、边缘服务网内路由和处理器处理时序。通过协调各请求的接入节点可有效缓解拥塞的通信链路，降低无线传输时延；通过协调请求的边缘网内路由，可有效缓解拥塞链路和路由器转发时间；通过协调处理器处理时序，可按照各请求的最早、最晚截止时间，尽量满足多用户请求。
• 通过资源分配方案迎合用户请求。考虑到边缘用户的移动性和多变性，一成不变的服务部署方案很难迎合边缘网络的这一特点。因此除了协调用户的请求来迎合边缘网络资源，我们也需要主动调整边缘网络的资源来满足用户多变的请求。具体来说，通过用户请求的分布来合理部署多个服务实例，以缓解通信时延和处理时延，通过扩容或者新建应用实例来满足不断增长变化的用户需求。

②管理部署的边缘计算主机，维护计算、存储、传输资源以及服务器间拓扑结构。

③管理边缘网络所提供的服务。检查软件包的完整性和真实性等相关要求，并在必要时对其进行调整以符合系统要求。

除了与边缘网络直接相关的架构设计，边缘计算的范式对传统计算模式的关键技术均具有重要影响，在编程模型、操作系统、网络管理、服务管理等方面引领了一系列技术创新。

2.3.3　AIoT软件架构

考虑到当前AIoT主要面向市场产品的落地，其中的边缘网关更多的是基于上述一般架构针对场景的定制化产品落地，技术重点强调在边缘网关与应用平台两个关键部分。如图2-10所示，以腾讯IoT EIDP［1］为例展示了典型的AIoT技术架构。其中边缘网关直接面向前端的物联网设备应用提供各类服务，这些服务通常由虚拟化引擎（如Docker）提供，包括服务发现、协议转换、AI中间件、云端连接服务及具体的服务实例化容器。应用平台部分根据开发及市场需求分为应用与模型发布平台、应用与模型分发平台。其中应用与模型发布平台面向边缘模型和服务的开发者，提供Docker管理、应用管理、可视化配置应用、应用发布等。而应用与模型分发平台则可以看作面向各个边缘网关终端的应用与模型市场，除了模型及应用镜像仓库之外，设备管理、应用管理、网络代理、认证授权等也是应用与模型分发平台的重要模块。

2.3.4　卫星边缘计算架构

微电子技术的蓬勃发展，使得微型卫星成为可能。从传统的重达500千克的地球观察者1号卫星（EO-1），到现在的仅重几千克、体积在10厘米级的立方体卫星，卫星的设备成本及发射成本在一路下降，这使得卫星的大规模部署成为可能。从星链计划［3］到黑杰克计划［4］，低轨卫星星座逐渐展示出其在军事、民用领域的重大潜力，获得政府、企业、学术界各方的广泛关注和研究。伴随着云计算、边缘计算相关技术的发展，低轨卫星星座也需要具备多星协同、自主运行、能力开放的在轨边缘计算能力。

不同于地面上的边缘计算架构，运行在低轨道上的卫星时刻处在与地球的相对运动之中，这使得任何一个单一的低轨卫星都不足以给地面上的前端设备提供稳定的边缘计算能力。因此，直接将前面介绍的边缘系统架构用于卫星边缘计算时无法正常运转。这就要求对边缘计算的系统架构做出调整，使其能够适应低轨卫星的系统特点。

目前国内外已针对低轨星座在轨计算的研究开展了一系列工作。如DARPA的黑杰克计划，期望在550km轨道上建立80～100个卫星节点的低轨星座，能够协同、自主地进行任务运算，而运维仅需要一个2人小组，其归功于其中的PitBoss系统（类似于中控平台）管理卫星轨道、服务管理、任务调度等核心模块，实现低轨星座的自主运行。欧洲宇航局也提出了OS-SAT计划，期望利用市面已有的设备建立低成本、高可用的低轨卫星计算系统，并面向第三方开放。英国企业Exodus Orbitals也提出了一项在轨运算服务计划［5］，并期望在2021年将计算能力开放给普通开发者。此外，卡内基-梅隆大学也提出了Orbital Edge Computing项目，面向典型的卫星遥感任务，提出了初步的星座协同运算方案，并开发了全系统仿真。表2-2展示了在轨卫星边缘计算近年相关项目的基本情况和预期进度。

①仿真系统地址为http://qaanaaq.andrew.cmu.edu:8080/。

当前关于卫星边缘计算架构的研究，主要针对卫星与地面的相对移动、卫星本身的能源不稳定等特点。为应对这些问题，多个机构提出了不同的技术路线，并开展了前沿探索。本节将主要介绍计算卫星流水线技术以及动态星团组网技术。

1. 计算卫星流水线技术

地面图像处理是在轨卫星边缘计算的主要任务场景之一。由于低轨卫星的覆盖范围相比同步卫星较小，且存在卫星与地面之间的相对运动，使得在轨计算的图像采集难以使用传统同步卫星现有的技术。对于同一颗卫星，在不同时刻，其所覆盖的地面区域是不同的，这意味着：

①对于每一颗卫星而言，其面向区域的计算任务是伴随着轨道运动在发生周期性变化。

②对每一个区域而言，其计算任务在不同时刻会在不同的卫星上执行。

理想状态中，如果各颗卫星能够及时处理其对应区域的图像处理任务，则多颗卫星伴随轨道移动可以实现轨道图像处理任务的覆盖和及时响应。然而，考虑到低轨微型卫星处理能力十分受限，当其移动到新的区域时（即接收到新的任务时），虽然能够顺利采集图像，但旧区域的任务极可能仍未完成，从而来不及处理新进入区域的计算任务。

为解决此问题，卡内基-梅隆大学提出计算卫星流水线（Computational Nanosatellite Pipeline，CNP）技术，将多颗卫星组织起来，共同处理单一卫星无法完成或来不及完成的图像处理任务。CNP技术的基本思想是根据任务特点控制卫星阵型及任务分配，将采集到的图像任务切割并分配到多颗卫星上进行并发运算，从而将多颗卫星有机组织起来。如图2-11所示，运用CNP技术，图像首先被分割为多个块（tile），这些块被分配到多颗卫星上进行并发运算，之后运算结果再汇聚或发回地面。

除任务分割外，CNP技术根据任务需求对卫星阵型进行调整，可分为帧距阵型和紧凑阵型。在帧距阵型中，每颗卫星相距的空间刚好使得各自采摄的图像相邻一帧距离（如图2-11中的第1、3、5颗卫星）。在紧凑阵型中，卫星之间的距离尽可能被缩短，能够支持算力的集中，处理实时性要求较高的任务。根据卫星阵型和任务分割策略的不同组合，CNP技术提供四种运算模式：帧距块并发、紧凑块并发、帧距帧并发、紧凑帧并发。

①帧距块并发。CNP技术中相邻的两颗卫星之间保持帧距，即两颗卫星拍摄的地面图像是正好相邻的两帧。每台设备均拍摄地面图像，形成连续的区域，并处理其中一部分图像块数据，如图2-12a所示。

②紧凑块并发。紧凑是指相邻卫星之间保持尽可能短的距离，每颗卫星并行处理不同的图像块数据，如图2-12b所示。

③帧距帧并发。相邻两颗卫星保持帧距，每颗卫星处理各自的图像帧，从而在整体上完成连续区域的图像处理，如图2-12c所示。

④紧凑帧并发。相邻卫星之间保持尽可能短的距离，每颗卫星处理不同的帧图像数据，如图2-12d所示。

显然，这四种运算模式是为了应对不同的应用场景。帧距块并发和帧距帧并发两种模式用于单位图像的计算负载相对稀疏的情况，允许卫星之间相邻一定的距离以增加对地面区域的覆盖。当每帧图像仅需要处理关键信息时，采用块并发的方式。当每帧图像需要完整处理时，则使用帧并发的方式。紧凑块并发和紧凑帧并发则用于单位图像的计算负载较密集、单一卫星无法完成关键帧处理的场景。此时，通过将多颗卫星紧凑排列，能够集中算力完成一帧图像中的计算任务处理。如图2-12所示，当单帧的图像任务负载较大时，多颗卫星通过块并发的方式集中处理。当遇到连续帧任务负载较大时，则利用帧并发的方式进行处理。

由CNP技术可以看到，卫星边缘计算相比一般场景的边缘计算，对边缘服务器的移动性和任务分割具有更高的要求，也更接近于D2D和高移动性的泛在边缘场景。

2. 动态星团组网技术

低轨卫星与地面之间的相对移动不仅影响到任务与卫星间的匹配关系，同时也影响到卫星与地面之间的数据传输链路。对于地面上的固定位置，一颗卫星在其上方的过顶时间通常在10分钟到半小时不等，这意味着计算任务需要在这段延迟之内完成。虽然CNP技术可以加速任务处理，但对于复杂度较高的任务而言，在确定其计算量之前依然难以保证任务在时限内处理完成。

与CNP技术形成互补的另一种方式是“动态星团组网架构”，通过考虑计算任务特点、轨道信息以及各卫星节点上的负载，动态地选择一部分卫星形成“星团”来完成一批计算任务。如图2-13所示，星团中包含三种角色的卫星节点：协调节点、汇聚节点以及运算子网。其中运算子网是共同形成星团的卫星集合，这些卫星相互协作共同完成批量的计算任务。协调节点是直接与地面设备通信的节点，接收来自地面前端设备的计算请求，判断该请求对应的计算任务，并分发给计算子网中的卫星节点进行协同处理。待计算任务处理完成之后，各卫星将计算结果传输给汇聚节点返回地面。不同于协调节点在接收请求时自然确定，汇聚节点是由协调节点收到计算请求后，根据轨道移动模型和估计计算延迟来选定的。选定的汇聚节点需要在任务完成的时刻移动到地面前端设备的上方，从而保证任务完成后能够第一时间将计算结果返回。不同于传统的集群管理方法，动态星团组网中各卫星节点的相对位置、卫星与前端设备的相对位置均处于随时变化的状态。这对多边缘卫星协同、底层寻址、数据可靠传输等方面均提出了较高要求。

卫星边缘计算是一种较为新颖的边缘计算场景，可以视作一种特殊的泛在移动场景。其中边缘服务器（低轨卫星节点）与前端设备之间、边缘服务器相互之间均存在相对移动，这一移动性是伴随着轨道具有周期性的。如果将卫星边缘计算中移动的周期性这一条件放宽，则接近于一般意义的泛在移动边缘场景，对系统架构、底层协议、计算模型等方面会有更高的要求。

2.3.5　编程模型

边缘计算的普及有望将几乎所有的智能设备带入类云环境中，前端设备不需要携带计算和存储资源，可以通过远程通信使用边缘设备上的计算与存储资源。考虑到边缘设备以及边缘服务的多样性，急需提出新的编程模型以支持各类设备接入边缘网络和边缘服务的快速开发迭代。

当前多个机构提出了用于“物联网+边缘计算”场景的编程模型，如微软Azure IoT Edge、AWS Greengrass、EdgeX、百度OpenEdge等。这些边缘框架普遍沿用了传统编程模型，边缘服务开发者在开发过程中需要明确定义数据来源、数据格式、边缘服务接口、边缘服务地址等。这样的编程模型在边缘计算的环境中面临以下几方面的挑战，有可能严重阻碍边缘服务及相关应用的快速开发迭代。

①边缘服务访问的局限性。在基于云的计算框架中，各服务组件需要预先运行在云中心设备或其他参与软件周期的设备上，从而允许开发者应用通过网络进行调用。但在边缘场景当中，边缘资源往往仅有特定区域或特定用户能够访问。而服务开发者通常无法得知具体服务的访问区域和访问权限信息，导致开发边缘服务时需要大量的服务查找及状态分支逻辑，甚至导致服务在实际场景中不可用。

②边缘资源的多样性。不同于通用云服务器，按照当前对边缘计算的设想，边缘设备可以是任意形式，其配备的资源类型、资源数量、通信方式甚至硬件架构均可能存在较大差异。这导致边缘服务和应用开发者几乎不可能在开发过程中明确指定边缘资源及相应资源的调用方式。

③边缘场景的高度动态性。考虑到边缘计算场景中的移动性，边缘设备、边缘资源均可能处于不稳定的服务状态，如在车联网场景中，高速移动的车辆与边缘服务网络之间链路的不稳定将直接导致边缘服务无法使用。而现有编程方式通常不考虑服务稳定性和可用性，开发者也难以在开发过程中对各类移动场景进行准确处理。

④固化的边缘服务方式。针对多样化的物联网应用，各边缘服务之间多采用基于主题的发布/订阅（topic-based pub/sub）接口进行服务间通信，并且需要手动定义服务间的路由。然而在边缘场景中，由于移动性、业务需求等因素，边缘服务时常会面临迁移、负载波动等问题，这使得预先定义好的服务组合在真实环境中极有可能无法正常运转。

为解决上述问题，促进边缘计算生态和产业的快速发展，当前研究界与科研界在编程模式方面展开了一系列前沿探索，如图2-14所示。如NEC公司欧洲实验室与日本方案创新部门提出的Fog Function（FogFunc），旨在用Serverless思想建立一个轻量级、动态的事件驱动编程模型。维也纳工业大学同样基于Serverless技术提出“设备无关边缘计算（Deviceless Edge Computing）”，在开发者与边缘设施之间建立一个抽象管理层，用于建立自动化的资源配置与应用管理过程。弗吉尼亚理工大学提出了微服务编排语言（Microservice Orchestration LanguagE，MOLE）。MOLE是一种声明式领域特定语言（Declarative domain-Specific Language，DSL），开发者仅关心如何根据业务定制微服务声明（Declarative Specifications of Microservices）即可，编译器会根据微服务声明产生与平台无关的执行计划，该执行计划进一步由MOLE Runtime在可用的边缘设备上执行。

图2-15展示了使用MOLE方式的开发及调用过程，开发者根据业务需求设计服务组合脚本，规定服务间的逻辑流程。组合脚本进入编译器后，首先会被提取微服务及相应的微服务结构图，形成微服务执行序列。边缘网关在接收到编译完成后的序列后，按照执行图组织本地的计算资源，并根据前端用户的服务请求完成微服务的调用过程。

可以看到，面向边缘环境编程模型的核心思想是将前端应用的多样性、边缘设备和资源的多样性隐藏起来，让开发者只需要关心其核心的服务组合与编排，不需要了解底层设备标准及开发流程，从而极大地简化开发过程，加速边缘服务与应用生态的发展。