开源边缘计算平台研究分析

黄 倩，黄 蓉，王友祥，陈 杲（中国联通研究院，北京 100044）

0 引言

2020年，5G商用引爆通信业发展。以往通信设备都是软硬件一体，一旦标准技术换代，就得研制新设备，导致投资大、灵活性差。5G 引入SDN∕NFV 技术后，采用标准服务器、存储器和交换机来承载软件化网络功能，替代原有软硬件一体专有设备，解决了通信设备迭代更新难度大的问题。随着5G 不断向软件定义网络方向发展，网络架构变得更加灵活，为了适应这种变化，传统CT、IT、公有云厂商也适时推出了开源边缘计算平台项目。

1 边缘计算平台现状

万物互联时代到来，边缘计算规模和业务复杂度发生了根本变化：边缘实时计算、分析和边缘智能等新型业务不断涌现，对边缘计算效率、可靠性和资源利用率提出了更高要求；因此，诸多厂家提出建设边缘计算平台，平台涉及边缘侧网络、计算以及存储资源管理，提供基础功能，如设备接入、安全校验、监控等，其接口、架构、管理逐步成体系。但各厂家的边缘计算平台差异较大，行业边缘应用部署时需要适配不同边缘计算平台，导致跨平台应用部署难度大，故考虑引入开源技术打造5G MEC 边缘计算架构和能力开放的事实标准，打破当前边缘计算平台市场烟囱式、碎片化现状，降低产业应用客户上车门槛，实现规模复制，通过开源协作方式构建统一5G MEC 平台。下文从边缘计算平台参考架构入手，引出2 种开源边缘计算平台进行分析。

2 典型边缘计算平台参考架构

2020 年，在OSF 边缘计算小组（Open Stack 基金会主导）发布的《边缘计算：架构，设计和测试的下一步》白皮书中，开源基础设施运营商和供应商联合定义了以下2类典型边缘参考体系结构模型。

a）集中式控制平面模式：传统单数据中心环境下中心控制器和边缘计算节点由广域网连接。该模式从集中运营角度看有优势，安全性高，但节点严重依赖集中式数据中心来承载管理和协调边缘计算、存储和网络服务，边缘节点自主性差，是一种传统架构模式。

b）分布式控制平面模式：多数控制服务驻留在大∕中型边缘数据中心上，也要求边缘站点自身功能全面。这种体系结构比较灵活，尤其在网络连接丢失情况下更凸显其优势，但由于需要跨地域运行大量控制功能，管理编排类型服务更复杂。KubeEdge 属于此类去中心化架构模式。

3 开源平台项目分析

KubeEdge和OpenNESS是市面上较为常见的开源平台，均采用了通用VNF Manger 和NFV Orchestrator组件，参考了标准ETSI MANO 体系结构，但其特点不尽相同，详细分析如下。

3.1 KubeEdge

2019 年，KubeEdge 由华为捐给CNCF 基金会，基于Kubernetes（简称k8s）构建，100%兼容k8s API，是Kubernetes IoT Edge WG 关键参考架构之一，可提供云边协同能力开放。

3.1.1 整体架构

该平台分为云端、边缘端和终端3层，是解耦式的架构，具体如图1所示。

图1 KubeEdge整体架构

a）云端：负责应用和配置策略下发，通过旁路设计开发CloudCore 组件，进行边缘节点同步和维护，利用list watch与Kubernetes集群做信息同步。

b）边缘端：负责运行边缘应用和管理接入设备。Edgecore 支持CRI，底层可以对接多种container runtime、device Twin 和DEvent Bus，主要做设备元数据管理以及MQTT 协议订阅和发布，从而完成与终端设备通信。

c）终端：运行各种边缘设备。设备终端有多类访问协议，部分新设备可能直接支持MQTT 协议。但部分专用设备存在专用协议，KubeEdge 采用Mapper 设计，可将专有设备协议转换成MQTT协议，实现边缘应用和云上设备数据同步和管理。

3.1.2 主要特点

KubeEdge针对边缘侧实际环境做了诸多优化。

a）云边可靠协同：采用双向多路复用消息通道，支持边缘节点位于私有网络中，云边消息传输默认使用Websocket 消息封装，减少通信压力，高时延下仍可正常工作。

b）边缘离线自治：通过消息总线和元数据本地存储实现节点离线自治，节点故障恢复也无需listwatch，从而降低网络压力，提升故障恢复速度。

c）边缘极致轻量化：边缘侧节点Edgecore 内存约70M，支持CRI 集成containerd 和CRI-O，优化了runtime 资源消耗，方便在资源受限边缘上运行；保留了Kubernetes 的管理面，重新开发了节点agent，大幅降低边缘组件资源占用率。

d）k8s 原生支持：云端可以通过k8s API 管理边缘设备和边缘应用程序。

但是作为一个开源项目，KubeEdge 仍有很多方面待继续完善。

a）不支持设备协议如OPC-UA。

b）不支持使用数千个Edge 节点和数百万个设备评估并启用更大范围的Edge群集。

c）不支持对大型Edge 集群的应用程序进行智能调度。

3.2 OpenNESS

由Intel 主导，OpenNESS 是一套开源软件开发套件，为在用户边缘侧或网络边缘侧等位置运行的应用提供单一应用托管环境，旨在多种网络接入方式（Wi-Fi∕4G∕5G等）下助力边缘业务管理与编排，通过抽象化去除网络复杂性，让开发人员可以像编写云软件一样轻松编写适用于边缘的软件，该项目在Akraino Edge Stack（Linux基金会项目）中被广泛应用。

3.2.1 整体架构

OpenNESS 由边缘节点和边缘控制器2 个部分构成。

a）边缘节点：支持多种网络接入方式，能够从IP、S1_U 或者SG1 接口提取数据；支持针对5G 延迟、多租户和服务注册流量定向，并支持部署边缘应用。

b）边缘控制器：一般处于数据中心、云中或边缘等位置，进行边缘平台编排，采用GUI 方式，支持其他通信服务提供商采用API 方式链接到自己的控制器GUI 环境。图2 为OpenNESS 抽象描述，展示边缘节点上软件和云控制器与其他技术相互配合的使用方式。

图2 OpenNESS整体架构

3.2.2 主要特点

OpenNESS 当前侧重4G∕5G 功能集成、底层Cloud native能力以及不同硬件资源适配能力。

a）支持独立5G NR 和增强平台感知部署。有5G接入模块，AF可与NEF通过N33接口或者与PCF通过N5 接口通信，帮助MEP 下发分流规则以及事件订阅等，支持HTTP∕2、HTTPS∕oAuth2 协议；OpenNESS 的DataPlane模块是所有边缘开源项目中比较独特的。

b）高效扩展简化编排：可以与Kubernetes（将来还包括Openstack）配合使用，可用于预配边缘资源并为网络边缘配置增强型平台感知功能，虽然本身不包含服务编排，但具备可连接到服务编排器的控制API。

c）提供应用使能服务能力：提供API，可供应用实现服务注册、发现、订阅和已订阅服务查询。

d）灵活扩展性强，多云兼容：基于微服务和开源API，OpenNESS可以为AWS Green grass、Microsoft Azure IoT Hub 和百度IntelliEdge 提供云连接器，因此更易于实施升级和更新管理。

3.3 对比分析

整体来看，各平台涉及的技术栈基本一致，但在部署形态、架构、编排策略、可靠性和应用场景等方面仍有差异（见表1），因此未来多平台共存将是常态，如何加强各平台间的协作将是未来的研究重点。

表1 开源边缘计算平台性能分析对比

4 3GPP&ETSI边缘计算平台架构映射分析

4.1 3GPP

3GPP 主要关注的是网络架构对MEC 特性的支持，其中5G 网元UPF 作为边缘计算的数据锚点、涉及用户面重选、灵活业务疏导和计费等服务质量保障方面内容；MEC 与5G 的融合架构主要关注3 个接口：MEC 平台与NEF 的接口N33，与PCF 的接口N5，与UPF的接口N6。目前由Intel开发的OpenNESS平台也已经搭建了5G+MEC测试床。

4.2 ETSI

ETSI 对MEC 的定义为在移动网络的边缘提供IT服务环境和计算能力。MEC 架构设计遵守基础资源开放、平台能力开放（通过MP1 接口，为APP 提供ME services ）、网络能力开放（RNS API、Location API、bandwidth API、UE identity API）、管理能力开放、本地流量卸载以及移动性管理等原则。

4.3 部分开源平台映射关系

OpenNESS 符合ETSI MEC 框架，其中边缘控制器对应MEPM，边缘服务对应MEP，边缘应用对应ME APP。OpenNESS主要参考ETSI MEC规范，OpenNESS与ETSI 的映射关系如图3 所示，其中蓝色及橘色部分由OpenNESS实现。

图3 OpenNESS与ETSI的映射关系

5 运营商实施建议

随着企业大步向云原生时代迈进，电信运营商也逐步将云原生技术扩展到边缘侧，并密切关注全过程中的安全性、服务遥测、计算性能、弹性和扩展性，以便未来以开放互操作的方式调整组织、业务和运营流程，加快部署节奏，降低总成本和运维风险，笔者建议如下。

a）提供统一边缘计算参考实现标准，聚焦整体框架、接口定义及实现方式，并进一步统一面向应用的接口，降低应用开发伙伴上车门槛，逐步打破各家烟囱式MEC方案，打破市场隔离。

b）积极与公有云厂商合作，作为当前公有云服务提供商的补充，可避免重复部署资本密集型基础设施，实现快速上市和测试新行业用例，共享行业应用程序生态系统资源。

c）打造新协作生产关系，改善运营商与厂家之间的关系，由传统的供应关系改为合作，联合设备厂家、应用厂家以及科研机构从不同角度加强协作共建，构建开放的生产关系，打破传统的封闭式合作模式，激活商业创新。

d）重点关注边缘计算平台的异构硬件支持、移动性支持、IT∕CT鸿沟的关键技术点以及平台是否支持边缘节点轻量化部署和边缘离线自治。

总体看来，当前边缘计算相关创新和开源化进程仍处于早期阶段。虽然开源将打破旧有设备供应链格局，但在开放架构下，如何加强各开源平台间协同创新，保障各方利益，平衡开源和专利保护，这些有待进一步研究与探讨。