下载掌阅APP，畅读海量书库
立即打开
我们可以将边缘架构的目标总结为：实现云-边资源整合和云原生应用的下沉、接入多种IoT设备并增强边对端的管理、建立边缘智能开放平台、云通过控制边来影响端等。为了推动边缘架构的尽快落地，许多研究人员对具体场景中的共性问题进行抽象，同时整合边缘网络的资源并向应用开发者和终端设备提供开放接口，从而实现通用性较高的边缘计算框架。然而，目前尚未出现整合边缘架构全部要素和所有环节的统一开源框架，它们大多针对特定的服务环节或者架构要素。具体来说，边缘计算的开源框架大致可以分为面向云、面向边以及面向端三类，接下来我们将依次介绍它们的架构特点和技术原理。
注意 面向端的开源框架运行在边缘服务器上而不是终端设备。面向端所强调的是将终端设备接入边缘网络并加强边对端的管理。以IoT为例，终端设备上运行的通常是融合了边缘计算特点的嵌入式操作系统。
Kubernetes（又称为K8S）是谷歌提出的一种运行在云中心的容器编排框架，它通过生命周期管理、应用通信以及集群调度等机制极大地增强了容器的容错能力 [16] 。K8S通常采用声明式定义语言以实现自动化部署，并为分布式系统提供了基础设施层。该框架还提供了与集群交互的统一接口，允许开发者在微服务架构下编写容器化的应用程序。
注意 面向云的开源框架可能同时实现了面向边的目标，如StarlingX。在云-边协同中，云通常能起到整合所有资源的主导作用，所以我们将其归类为面向云的开源框架。
StarlingX是一种由Intel和Wind River联合推出的面向电信网络及边缘计算的资源服务管理框架，它能够在云中心和边缘网络中实现自动化容器部署、管理和编排 [17] 。该框架旨在支持边缘间协同、云-边资源整合和云-边-端协同，同时它也包含了很多核心网络功能。从底层实现来看，StarlingX是一个以OpenStack平台为基础的软件栈，包含服务打包工具、编译工具、安装配置工具、面向电信云的VIM、OpenStack平台以及WindRiver的MTCE平台。该框架包含六大组件，即服务管理、故障管理、软件管理、基础管理、平台调度和配置管理。StarlingX通过这些组件部署并管理OpenStack平台以使用其计算、存储和网络资源。
KubeEdge是华为提出的一种支持云原生容器化应用编排的边缘计算开放平台，它旨在将云中心的应用程序和编排功能扩展到边缘服务器上 [18] 。图2-9展示了KubeEdge的整体框架图。该框架以容器化应用部署框架Kubernetes为基础，构建了支持各类网络和应用程序的基础边缘架构。
图2-9 KubeEdge框架示意图
KubeEdge可以有效提供端到端的边缘服务管理和部署。在Kubernetes的管理下，它还支持云-边-端协同和云-边之间的元数据同步。
作为面向边的开源框架，KubeEdge具有很多显著优势。传统业务可以高效地运行在边缘服务器上以降低响应延迟，同时也减少了云-边之间网络带宽的消耗以及服务成本。该框架提供了简单易用的API以方便开发人员编写基于常规HTTP或消息队列遥测传输（Message Queuing Telemetry Transport, MQTT）的容器化应用，同时也使大量现有云原生应用的部署变得更加容易。得益于Kubernetes的原生支持，KubeEdge可以帮助用户高效地编排应用和管理设备。另外，数据在边缘端生成并被处理，隐私安全得到了保证。
面向边的开源框架可以简单看作裁剪和定制化后的云计算框架。K3S是Rancher提出的一种面向各种边缘场景的轻量级Kubernetes发行版，它旨在借助有限边缘资源在无须Kubernetes协助的情况下实现高效的服务管理和容器编排 [19] 。
得益于K3S的支持，Kubernetes集群可以运行在x86、ARM64和ARMv7等处理器平台。该框架借助底层优化充分发挥出IoT、CI和ARM设备的性能，同时简化了用户操作并提高了系统安全性。K3S能够被部署在无人值守的远程位置，并在资源受限的情况下高效执行IoT设备的工作负载。另外，由于需要额外部署Kubernetes管理层，K3S一般不涉及云-边协同。
EdgeX Foundry是Linux基金会提出的一种面向工业物联网和边缘计算的开源微服务框架，它旨在提供与硬件平台、操作系统和服务供应商无关的通用解决方案 [20] 。图2-10展示了EdgeX Foundry的整体框架图。该框架关注海量异构IoT设备的接入和管理、边缘网络的数据传输以及算力受限设备上的计算。
图2-10 EdgeX Foundry框架示意图
基于EdgeX Foundry框架，我们可以很容易地构建针对各种IoT场景的边缘系统。该框架能够充分利用有限的边缘资源，从而使边缘服务可以直接运行在类似树莓派的设备边缘服务器上。几乎全部的计算请求直接由树莓派组成的EdgeX网关处理，为主干网节省了大量的带宽资源。EdgeX Foundry框架主要包含四个抽象层。设备服务层负责适配通信和数据协议以接入IoT设备。核心服务层包括注册与配置、核心数据、元数据和终端命令。支持服务层负责日志文件、通知警告、规则引擎和服务调度。导出服务层负责用户注册、用户交互、服务分发和附加服务。
某些情况下IoT设备可能需要与云中心取得联系。AWS IoT是亚马逊提出的一种专门为IoT解决方案提供云服务和设备支持的开源框架，它旨在将各类智能设备接入亚马逊云并为基于IoT的应用程序提供丰富的云服务 [21] 。AWS IoT支持终端设备通过LoRa技术接入各类网络以实现高效的云-边-端协同。同时，该框架使用MQTT协议来实现服务器与异构IoT设备之间的通信。
AWS IoT关注与终端设备之间的交互以及数据传输，该框架主要包含四种服务。设备软件负责为IoT设备提供网络接入支持。控制服务指几种常见的用于管理IoT设备的AWS IoT服务。数据服务对实时视频、传感器事件、工业设备和数字可视化中的IoT数据进行分析。核心服务将IoT设备连接至AWS云并提供消息收发、设备安全、数据管理和互联支持等服务。
不同架构往往为特定的目标而设计，并且针对专门的应用场景。以云计算为中心的架构更适合应对各种在线网络服务、离线数据分析和深度神经网络（Deep Neural Network, DNN）模型训练等实时性要求不高的应用，云中心可以提供这类计算和I/O密集型场景所需的强大算力。云-边协同的边缘架构更适合应对工业物联网、无人驾驶、智能家居、远程医疗和虚拟现实等实时性和隐私要求较高的应用，基于协同机制的边缘网络能为这类资源受限的场景带来极低的延迟。因此，满足所有应用场景中不同需求的统一边缘架构是不存在的，架构选型十分必要且尤为关键。
架构选型旨在根据实际业务需求、具体应用场景以及现有技术栈进行综合决策以选择性价比最高的边缘架构或开源框架，从而实现充分利用边缘基础设施、降低部署开销和运营成本、满足终端设备和用户需求等目标。一般来说，架构选型表现为分别面向云-边-端的开源框架的调研和选择。目前而言，以K8S为代表的面向云的开源框架已经十分成熟，所以这类框架的选择余地相对较小。面向端的开源框架大多需要在边上部署一套与设备管理相关的微服务。在选择这类框架时必须考虑所支持的负载类型能否满足业务需求，例如，有的框架可能无法运行视频处理或AI模型推理等工作负载。同时，对IoT设备代理相关协议的支持也是架构选型要关注的问题。
接下来以面向边的开源框架为例讨论架构选型要考虑的关键问题。从实际业务需求的角度来看，架构选型需要考虑的特性包括云-边协同、容器化编排、去中心化等。同时，架构选型还受到具体应用场景的影响，例如，在面向IoT的边缘架构中终端设备管理、是否支持MQTT协议和框架开源状况等都是十分重要的问题。考虑到现有技术栈和运营成本，K8S原生支持、部署开销及复杂性、组件资源占用也是架构选型所关注的重点。我们将其总结为以下几点：
❑云-边协同：为了实现高效协同应选择侧重云-边资源整合的开源框架，如同为轻量级的K8S，KubeEdge的协同功能比K3S更完善且性能表现更优。
❑容器化编排：选择能完美兼容云原生生态并可以高效管理边缘资源的框架比较合适。
❑去中心化：KubeEdge移除K8S管理层以实现真正的分布式部署，这有利于增强边缘自治能力并提升系统稳定性。
❑终端设备管理：应该关注开源框架管理终端设备的能力以及对边缘异构场景的支持。
❑MQTT协议支持：支持MQTT协议对面向IoT和卫星网络的开源框架来说至关重要。
❑框架开源状况：需考虑项目成熟度、开源时间以及是否受到云原生计算基金会的资助。
❑K8S原生支持：云中心大多使用K8S框架，选择原生支持的框架能复用现有技术栈。
❑部署开销及复杂性：与兼顾云-边的StarlingX相比，KubeEdge的部署过程相对简单。
❑组件资源占用：在资源受限的边缘网络中开源框架组件占用的内存应该尽可能少。