2.4 边缘计算软件架构

在边缘计算中，软件架构可以简单理解为底层硬件和上层服务之间的“中间层”。如图2-7所示，边缘计算软件架构包含较为广泛的含义，我们可以将其大致分为面向边缘服务器的系统层架构、面向终端设备的应用层架构以及面向开发者的编程模型。系统层架构旨在统一管理边缘服务器的所有硬件资源并通过抽象提供易用性较高的各类API，应用层架构旨在根据具体场景的特点搭建定制化的应用发布平台，从而为终端设备提供各类服务。系统层架构的资源抽象为应用层架构的服务供应提供了基础，编程模型使得各类边缘服务的高效开发和快速迭代成为可能。在边缘计算软件架构中，以上三者共同实现了硬件资源到计算服务的转化。

2.4.1 系统层架构

系统层架构位于边缘计算软件架构的底层，它通常包含部署在边缘服务器上与硬件资源管理和基础服务API相关的中间件。在系统层架构中，虚拟化是一种常用的技术，它为各类异构硬件建立相同的软件堆栈以实现资源抽象。抽象可以向上层提供统一的资源视图并确保不同应用之间的隔离性，这样管理程序便能够快捷地监视所有资源的使用情况。另外，系统层架构中实现的中间件大多是与服务管理、资源分配以及网络通信相关的基础功能，它们进一步地为上层服务提供了接口。由于系统层架构屏蔽了硬件的异构性且更多地关注基础服务，所以具有较强的通用性。无论是云-边-端架构还是边-端架构，边缘服务器的系统层架构都是类似的。接下来，我们将依次介绍系统层架构中的虚拟化层与服务管理层。

虚拟化层旨在实现高效的边缘资源管理。边缘资源主要包含通用服务器提供的计算资源、区域网络附加的存储资源以及由交换机和路由器组成的网络资源。除了种类繁多，硬件资源还极大地受到多样化用户需求和具体服务场景的影响。例如，目标检测等计算密集型任务可能必须在配备GPU或FPGA等专用设备的边缘服务器上处理。因此，硬件资源的异构性是不可避免的。虚拟化层需要对各类设备和资源进行虚拟化以方便上层的管理和调度。需要注意的是，虚拟化技术在云中心同样得到了广泛应用，两者的虚拟化层主要存在以下区别：

❑边缘服务器上虚拟化层的基本原理与云中心大体相同，但所采用的虚拟化技术完全不同。由于边缘服务器所拥有的各类资源远少于云中心，所以直接应用云中心的粗粒度虚拟化技术（如虚拟机和Hypervisor）往往会导致较大的资源浪费和低效的服务管理。为了提高资源利用率，边缘服务器的虚拟化层必须采用容器等轻量级的虚拟化技术以降低整个系统的启动开销和服务延迟。另外，无服务器计算基于现有的云中心软件架构建立新的抽象层，实时为用户分配充足的资源而不需要预先为固定服务器付费 ^[15] 。

❑云中心软件架构通常为每个云服务器配置独立的虚拟化层，其核心目标是将本地硬件资源与上层软件服务彻底解耦。由于云服务器具有较强的通用性和类似的体系结构，所以通过集群的方式建立统一的资源视图是可行的。然而，边缘服务器之间的差异相对较大，并且大多数情况下它们需要相互协同以组成边缘网络。在多接入边缘计算中，边缘软件架构的虚拟化层需要抽象整个边缘网络资源，而不能仅考虑单个边缘服务器。

服务管理层的目标是基于虚拟化层实现IaaS、PaaS、SaaS和FaaS等服务方式。具体来说，服务管理层对经过虚拟化层抽象的逻辑资源进行调度和优化，并针对不同的边缘场景制定灵活的资源分配策略以极大地提高资源利用率。进一步地，服务管理层通过实现一些与基础服务相关的中间件向上层服务提供灵活可靠的API。另外，服务管理层也可以直接向用户或终端设备提供计算任务卸载等服务。服务管理层的主要目标包含以下几点：

❑服务管理层需要对虚拟化资源进行管理和调度，从而确保与资源相关的细节对上层透明。用户所需的服务类型往往是多样化的且容易受到具体场景的影响，很显然计算密集型、存储密集型和通信密集型场景下所需的资源类型是不同的。终端设备的移动性、网络环境的易变性以及多个边缘服务器间的广泛协同也对资源分配策略提出了更高的要求。因此，通过高效的资源调度来提高边缘计算的效率十分关键。

❑服务管理层需要向上层提供与基础功能相关的API或向终端设备提供直接的服务接口。所有的服务API都是基于边缘中间件实现的，它们主要包括服务注册模块、服务通信模块、流量监控模块和任务卸载模块。在多接入边缘计算中，服务管理层还需要为终端设备的卸载决策提供支持。服务管理层必须协调相同服务的多个计算请求，并将它们路由到合适的服务器上以充分利用边缘资源，或者主动调整网络资源以应对终端设备的异构性和移动性。

2.4.2 应用层架构

应用层架构位于边缘软件架构的上层，主要面向终端设备且通常以系统层架构为基础。这种软件架构常见于AI和IoT领域，如AIoT软件架构。在应用层架构中，大量与设备代理和服务管理相关的中间件被部署在边缘网关和IoT设备上。这些中间件使得异构设备能够通过多种通信协议接入边缘网络中，同时确保边缘网关能够有效控制和管理海量的IoT设备。边缘网关还借助这些中间件以容器的形式向IoT设备提供各类服务。特别地，系统层架构关注云-边资源的整合以及服务API的提供，而应用层架构关注边对端的管理以及应用产品的发布。应用层架构通常需要实现以下目标：

❑建立设备抽象以增强边缘网关对IoT设备的管理。在系统层架构中，边缘服务器借助虚拟化技术和资源抽象向上层提供服务API，侧重对硬件资源和基础服务的管理。与此不同的是，在应用层架构中，对IoT设备进行抽象并在边缘网关上主导它们是更加重要的。这种抽象大多是通过三层设备代理实现的。设备服务层负责与IoT设备进行交互，核心服务层负责管道通信和数据存储，支持服务层则负责与微服务进行交互。边缘网关基于设备代理向IoT设备提供服务发现、服务注册和云服务等各种容器化应用。

❑搭建应用管理平台以推动边缘应用生态的发展。在系统层架构中，服务管理层仿照云计算范式通过各种边缘中间件实现了任务卸载模块。与此不同的是，在应用层架构中，海量的、不断涌现的IoT设备导致新应用接口的开发势在必行，容器化应用的发布是更加关键的。所以，在搭建应用管理平台时必须重点考虑设备异构性和应用容器化。一般来说，应用管理平台可以分为发布平台和分发平台。发布平台负责向应用开发者提供容器管理和可视化配置，分发平台负责向边缘网关提供经过认证的应用和服务市场。另外，由于边缘网关几乎承载了所有的计算请求，所以应用层架构对于任务卸载模块的需求没有那么强烈。

2.4.3 编程模型

在云计算编程模型中，程序员面向几乎确定的目标平台开发和编写程序，得益于运行时环境的广泛支持，这些应用可以很容易地被部署在云中心的服务器上。为了确保云计算基础设施对用户完全透明，云服务供应商通常会对应用进行封装并向终端设备提供简单易用的服务接口。然而，这种传统的编程模型难以直接应用在边缘计算中。边缘服务器大多是异构的且任务运行往往受到具体场景的影响，迁移自云中心的计算任务无法直接部署在边缘网络中。因此，根据边缘场景的特点构建新的运行时环境是十分有必要的。边缘计算编程模型旨在基于新型运行库向应用开发者提供各类服务API，从而支持更多异构设备的接入和边缘业务的推出。实际上，高效的编程模型对IoT和边缘计算的深度融合以及边缘框架的落地起到了关键作用。与云计算编程模型和IoT服务模型相比，边缘计算编程模型具有以下特点：

❑边缘架构中存在海量异构设备和资源，硬件架构、资源类型和通信协议都是多样化的，这导致边缘资源的管理和调度十分复杂。边缘计算编程模型必须屏蔽异构性和复杂性。

❑边缘架构是面向“能力”的架构。终端设备往往具有不可预测的移动性，它们并不关心服务是由边缘服务器还是云中心提供。边缘计算编程模型必须以云-边资源协同为基础，并保证边缘场景下服务的连续性。

❑在云计算编程模型中，应用开发者可以借助远程网络调用预先在云中心对服务进行测试，这使业务更新和快速迭代变得十分方便。考虑到边缘场景可能具有特定的访问权限，边缘服务开发者难以提前获取真实运行环境和可用资源等关键信息。边缘计算编程模型必须克服这种地理局限性并为应用开发者提供足够的边缘信息。

❑在IoT服务模型中，边缘服务之间的通信接口通常采用以主题为中心的发布/订阅模式。考虑到移动性、需求变化和服务器协同可能对这种通信方式造成影响，边缘计算编程模型必须为开发者屏蔽边缘场景的动态性。

以上四大特点指明了边缘计算编程模型的核心目标，即通过抽象等方式屏蔽终端设备、边缘服务器的异构性以及边缘资源的多样性。应用开发者只需要关注核心业务的逻辑、功能和编排，而不用了解底层硬件的复杂性和边缘环境的动态性。实际上，边缘架构需要一种面向服务的编程模型，图2-8展示了服务组件框架（Service Component Architecture, SCA）中的模块结构。除此之外，设备无关边缘计算和微服务编排语言（Microservice Orchestration LanguagE, MOLE）相继被提出。设备无关边缘计算旨在构建边缘基础设施与应用开发者之间的抽象层，从而实现高效的资源管理和应用配置。微服务编排语言将应用开发者的业务逻辑转化为微服务声明，并通过编译器生成与平台无关的执行脚本。这样一来，开发者便能轻松将各类服务部署在可用的边缘设备上。