边缘计算Edge Native概念、技术及架构

「来源: ｜架构师技术联盟 ID：ICT_Architect」

随着 2020 年 5G 行业应用的快速发展，当前的边缘计算能力在实际应用中体现出部分不足，无法完全满足各类行业场景的实际诉求。一个关键因素在于 MEC 平台无法完全独立于运营商 5G 网络之外，网络能力与计算能力两者必须相互协同以进一步提升方案效率。在这样的背景下，本白皮书提出面向未来网络演进的 Edge Native 理念以支持运营商与行业面向未来的行业数字化转型。

本文首先分析边缘计算发展现状及 5G 行业市场边缘需求，边缘计算虽进入 2.0，但在 5G MEC 部署过程中仍然存在若干痛点，因此需要新的 Edge Native 理念。

其次，阐述Edge Native 产业理念及主要技术能力，Edge Native提供联接和计算的高效协同，是运营商网络以行业市场为主的中期目标架构。其中包含边缘编排、边缘智能、边缘安全等多种增强技术能力。

随着边缘计算产业的发展逐步从产业共识走向落地实践，边缘计算的主要落地形态、技术能力发展方向、软硬件平台的关键能力等问题逐渐成为产业界的关注焦点，边缘计算 2.0 应运而生。

边缘计算 2.0主要包括云边缘、边缘云和边缘网关三类落地形态；以“边云协同”和“边缘智能”为核心能力发展方向；软件平台需要考虑导入云理念、云架构、云技术，提供端到端实时、协同式智能、可信赖、可动态重置等能力；硬件平台需要考虑异构计算能力，如 X86、ARM、GPU、NPU 等。

据不完全统计，全球在 2020 年开展了超过 5000 个行业试点项目，其中约 60% 均涉及 MEC 部署。以中国三大运营商为例，已在 40 多个城市开展了 100 多个基于边缘计算的 5G 商业应用试点项目，覆盖了多个行业和应用场景，包括智慧工厂、矿山、能源等。

2020 年中国工业和信息化部的“绽放杯”5G 应用大赛中，5G MEC 的使用率达到 43%，相比去年增长 10 个百分点，在参加总决赛的 30 个项目中，MEC 的使用率超过 80%，5G MEC 已成为 5G 应用关键使能技术。

结合上述行业实践，我们可以看出当前 5G MEC 技术上仍然存在一些不足。这些不足主要体现在网络部署及设备能力、软件开发两个方面。在网络部署及设备能力上：

MEC可较好满足单一场景需要，但各场景对 MEC的部署位置、形态等差异较大，因此需要 MEC 可以支持更丰富的异构设备及组网形态；

MEC平台及其承载的应用需要更强的数据分析能力，尤其是基于 AI 的高效智能化数据分析，因此需要MEC 在软硬件上都要提升 AI 能力；

行业应用对于网络传输、可靠性要求普遍较高，因此 MEC 需要与行业应用、运营商网络进行高效协同；系统隔离、数据安全能力仍有待进一步提高。

在边缘应用软件开发方面，开发者面对 5G MEC 的场景以及多样的 MEC 平台形态，需要考虑最大化的使用到 5G MEC 的开放能力。一个典型的 MEC 应用开发者流程如下：

选择服务框架：根据应用开发者的语言技能，结合应用的最终运行场景进行应用开发态包含如应用框架、三方件、数据库等的选择。即在同一个 MEC 平台上，多微服务框架之间可以进行互相的注册发现、通信以及相关的服务治理。

定义 Rest API：简而言之，是应用开发者需要确定自身应用对外的交互接口，对外能提供对应能力；

使用 5G 网络能力：充分使用 5G 网络的低时延，大带宽等能力，并且是代码级的使用。即 5G 网络能力能够进行抽象，为开发者提供如 SDK/Rest API 等方便编程的能力；或者能够抽象为应用模板，使得开发者能够直接使用 Orchestrator 进行编排管理，而不需要关心里面具体的实现细节；

适配多种平台：这里的平台需要区分为两层，即 IaaS 和 PaaS 层，即既需要应用能够适配 X86/ARM 等 平 台， 同 时 也 需 要 能 够 使 用 Openstack/Kubernetes 等 IaaS 平台，同时 MEP 平台也能够提供如基础数据库、安全、人工智能、区块链等边缘解决方案能力；

DevSecOps/Orchestration：即应用需要端到端的DevSecOps 工具链支撑，同时也需要能够端到端的能力编排，如应用在部署时的依赖应用、三方能力等；

为了更好地满足未来 5G 行业市场的发展，5G 确定性网络产业联盟（5GDNA）、EdgeGallery开源社区、边缘计算产业联盟（ECC）和工业互联网联盟（AII）共同提出 Edge Native（边缘原生）的产业理念。

首先，Edge Native 与 Cloud Native（云原生）类似，都是一种长期文化与理念。因此其包含的范畴可能随着产业的发展而发生变化。就如同 Cloud Native 诞生之初更关心软件开发的 12 因子原则，而随后 2018 年 CNCF 将Cloud Native 定义为一种范式，让应用更加适应并使用云的特性，如弹性、分布式，而不需要关心底层的技术实现，从而实现快速部署、按需伸缩、不停机交付的特性。

其次，Edge Native 与 Cloud Native 是一体两面，体现了 ICT 产业的重心不断向边缘转移。在这一转移过程中，Cloud Native 的技术面临了一些挑战，包括：端到云中心RTT时间较长，所有的计算、存储、网络消耗以及管理需要在中心终结。

传输成本与计算成本相对较高隐私与数据安全的挑战而 Edge Native 则体现出了部分截然不同的特征和价值：

由于 Edge Native 融合了更多的电信联接概念，导致熟悉 IT 的开发者较难理解边缘环境的一些架构、参数、特征等。所以边缘平台需要面向开发者将网络属性，包括 3GPP 等定义的具体参数进行友好的抽象表达。

另外，对于 5G 网络行业数字化转型而言，Edge Native 也是网络的目标架构。基于 Edge Native 可在边缘云环境下深度利用边缘计算特有价值特性，高效构建、运行和维护管理时延敏感的边缘应用。

Edge Native技术架构以边缘侧 5G 网络能力开放为特征，基于云边协同和边边协同的边缘网格技术、面向复杂场景跨网络的边缘编排技术、支持多语言 /serverless 和边缘自治的边缘框架技术、大量异构初始数据的低时延 / 实时预处理分析的边缘数据技术、基于认证加密和区块链的边缘可信技术、基于异构边缘智能硬件和硬件加速的边缘 AI 技术。

边缘基础设施 EdgeInfra

边缘基础设施是 Edge Native 的底层基础，包括硬件与平台技术。硬件上，边缘基础设施不仅需要考虑增强计算能力，也需要考虑如何更好的支持 5G 网络所需要的大流量转发能力。

因此需要支持异构硬件如 CPU（ARM 或 X86）、GPU、NP 等。平台技术上，目前越来越多的应用逐渐容器化 / 虚拟化。底层基础设施平台逐渐收敛至 Kubernetes 相关产品。但是 Kuberenetes 对于 MEC 应用的容器安全性、隔离性等有一些限制，需要对基础设施提出更高的诉求：

增 强 的 电 信 网 络 支 持：电 信 MEC 场景需要Kubernetes 增强应用及平台的多网络平面隔离，多租户增强，以及电信网络能力增强（如 TSN 等）。

容器与虚机的混合编排能力：电信网络功能及边缘应用厂商的容器化甚至虚拟化进展较慢，需要支持容器与虚机的混合编排。

边缘网络 EdgeNetwork

边缘计算平台作为联接 5G 网络与应用、最终用户的桥梁，需要在保障自身网络联接能力的基础上进一步加强与应用的协同，提供完善的 5G 网络开放能力：

5G 网络能力开放：ETSI MEC 定义了一系列网络开放能力，如位置信息等；同时 3GPP 与电信运营商也定义了基于 3GPP NEF 的网络开放架构。

算网一体的边缘计算平台：MEC 对下承载 5G 网络能力的打通，对上提供应用必须的计算与网络资源。MEC 平台需要对 5G 网络基础连接能力、计算能力、行业所需的确定性网络能力进行高效编排。

边缘编排器EdgeOrchestrator

由于边缘节点具有容量较小，部署环境复杂等特征，需要在整体边缘领域提供较强的边缘编排能力，以满足以行业为代表的业务 SLA：

边缘自治：边缘节点面临的弱网络等情况可能导致其与中心节点断联，出现如数据不同步，应用难以恢复等问题。

插件式的多云支持：EdgeOrchestrator 需要针对不同场景适配典型的基础设施层（如各种云平台/裸金属），如集群场景下可以支持 Kubernetes、Openstack，单机场景下支持 K3S、MicroKubernetes，裸金属场景下可能需要支持如 RunC。

边缘协同EdgeCollaboration

MEC 边缘节点，即需要与运营商网络增强协同，也需要支撑最终应用客户端的协同，同时也需要考虑在多个 MEC 节点之间的协同，如算力的共享，网络的编排等等：

边边协同：结合 EdgeOrchestrator 可以对整网的MEC 节点进行统一的协同编排。

边云协同：由于云端/中心端通常具备海量计算能力，并且能提供给应用一系列的开放能力，通过边云协同可以使 MEC 上的应用充分使用云端的能力。

边端协同：由于 VR/AR/ 视频为代表的终端应用对时延有严格的要求，同时也对图像渲染等能力有一定要求，因此需要从架构 / 技术上保证 MEC 节点到端侧的高效通信，提供边端的高效数传协议，并通过 MEC 提供图像处理、渲染等能力。

边缘智能EdgeAI

边缘计算与人工智能结合的课题，目前在学术界与工业界都有比较深度的分析与研究。无论基于边缘计算节点进行就近训练，还是将中心节点训练好的模型下载到边缘进行推理，都有比较多的场景。结合目前高校与业界的深度讨论与探索，目前诉求如下：

统一的边缘智能框架与模型：结合边缘、终端、中心协同，提供模型分割、数据分割、分布式学习、增量/迁移学习的引擎，以及对应的算法与协议接口。

AI 异构算力的统一调度能力：边缘计算平台可以提供 HAL（Hardware Abrastraction Layer）层为最终应用提供异构硬件的资源抽象，提供屏蔽异构差异的统一硬件资源，并由 MEC 智能调度合适的硬件资源运行不同类型的服务为应用提供最佳的运行效率。

边缘安全 EdgeSecurity

边缘平台的安全要求毋庸置疑，结合行业对于安全的诉求，EdgeSecurity 需求包括如下：

提供边缘平台端到端安全机制：边缘平台需要提供基础设施安全可信、网络安全可信（如网络隔离，网络监测与防护预警）、数据安全可信、应用安全可信等能力。如为防止 MEP 与 APP 等之间的通信数据被拦截、篡改，MEP 与 APP 等之间的数据传输应启用机密性、完整性、防重放保护等等功能。

不可篡改的数据保存联盟链：通过抽象应用镜像摘要如 Hash 等 Meta 信息，并对此 Meta 信息加密后保存到区块中，将每个边缘节点作为私有区块数据存储点进行管理，同时接入统一的公有链进行协同，保障了应用的端到端数据安全

边缘存储 EdgeData

目前包括 IEEE 等研究组织都在对边缘计算上的存储进行多方面研究。此外边缘计算的分布式特点也对其存储系统提出了相应的诉求：

分布式存储：其数据一致性需要 EdgeData 系统自行保持一致，支持去中心化存储系统之间的互联互通，包含冗余，容灾，边边数据协同等场景。

异构化存储：边缘设备针对场景可采用不同存储软件或存储介质，EdgeData 需要解决不同存储软件或者存储数据的抽象问题。

轻量化存储：例如针对 IoT 场景海量设备的监控数据和业务消息，可以提供轻量化的 TSDB 方案 ( 如TDEngine 等 )。

虽然2020年基于MEC的各类5G行业试点项目均取得了不小的进展，但对 Edge Native 来说仍然只是一个起点。其整体理念与框架仍有待完善，各种具体技术也需要进一步深入研究。本次合作的联盟和开源社区还将继续探讨 Edge Native 技术架构，携手推动 Edge Native 的产业落地和实践。

更多内容参考<Edge Native技术架构白皮书>。

1、边缘计算发展现状及5G行业市场对边缘的需求

1.1 边缘计算 2.0 及 5G MEC

1.2 5G MEC 产业现状及价值呈现

1.3 5G MEC 存在部分挑战

2、Edge Native 产业理念及主要能力

2.1 Edge Native 概念和产业价值

2.2 Edge Native 平台架构能力

3、Edge Native 产业实践

3.1 EdgeGallery：Edge Native 的开源实践

3.2 基于 Edge Native 的中国移动 OpenSigma 平台实践

3.3 基于 Edge Native 的中国联通 MEC 平台实践

4章、行业探索和未来展望

参考来源：Edge Native技术架构白皮书