由CloudNative引发的思考：什么是EdgeNative（边缘原生）

Posted 2021-04-24 开源先锋地带

更多精彩，请点击上方蓝字关注我们！

关于Cloud Native，在CNCF目前已经达成了共识，并输出了1.0版本的定义：

• 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
• 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
• 云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

并且还有对应的  12-factors :         

• 基准代码：一份基准代码，多份部署
• 依赖：显式声明依赖关系
• 配置：在环境中存储配置
• 后端服务：把后端服务当作附加资源
• 构建，发布，运行：严格分离构建和运行
• 进程：以一个或多个无状态进程运行应用
• 端口绑定：通过端口绑定提供服务
• 并发：通过进程模型进行扩展
• 易处理：快速启动和优雅终止可最大化健壮性
• 开发环境与线上环境等价：尽可能的保持开发，预发布，线上环境相同
• 日志：把日志当作事件流
• 管理进程：后台管理任务当作一次性进程运行

  
  

在做边缘计算当中，我们自然而然的会下意识的将Cloud Native的技术应用到边缘节点上，不管是NearEdge场景还是MEC场景，边缘计算的普及过程是一个渐变的过程，所以随着边缘技术的深入使用，可以大致的分为几个过程[注1]：

   

• Stage1（Device-Only）：设备部署到边缘，此时边缘设备的运算能力可能很强，可以很快的回馈到用户，但是没有与周边通信（如中心节点等）的场景。
• Stage2（Edge Enhanced）：将CloudNative的应用部署到边缘，通过中心管理，但是利用了边缘的物理位置优势，更近一部可能利用的边缘节点提供的一些计算便利或者API进行简单的边缘加速，但是整体上还是依赖于CloudNative的技术与整体管理。
• Stage3（Edge-Native）: 最后的阶段就是边缘原生的状态，在讨论边缘原生的状态之前，我们还是需要对边缘原生进行一些定义。

 

我们在讨论边缘计算（或者MEC）的时候，通常是会有一下几个典型特点：

• 资源受限: 即边缘计算不像云计算那样，可以假设资源无限，你必须要关注应用以及管理平台的资源消耗。
• 分布式:这个直观意义上就可以理解，边缘计算的核心就是把一些计算任务卸载到靠近用户或者数据输入的地方，提供相应的计算、存储以及网络。
• 低延时/实时：这个也很好理解，就不赘述了。
• 不稳定：即边缘节点很有可能部署在一些不受控的地方，会导致边缘节点有很多云计算无法想象的问题，比如异常断电、网络不可达等等，当然也会导致更加容易遭受攻击。
• 安全/韧性：原则上边缘计算需要提供更高的安全性与可用性，在收到攻击之后能够以最小系统运行。
• 与5G的结合：通过将5G网络的能力通过边缘计算释放给边缘应用，同时能够将边缘计算平台内嵌到和5G移动网络中。
• 硬件多样化：不同于数据中心的高度标准化和抽象化，边缘计算对于节点的定制于运维会提出更高的诉求，需要对于环境、位置的感知更高，而不是对于硬件的高度抽象。
• 智能化：不管是数据还是流量，能够智能的进行offloading，并执行本地任务，从而提升整体网络的运行效率，提供给最终用户的优质体验。

结合这些特点（优点或者诉求），对于边缘节点上运行的PaaS/应用提出了对应的要求：

• 轻量化：即无法像云/数据中心那样，无限的进行应用无状态的水平扩展，无法无限制的申请资源，软件只能在有限的条件下，进行scale并且尽可能的降低资源消耗，比如数据库就需要引入轻量化的数据库等等。
• 清晰的Dependency  Graph: PaaS应用需要有明确的依赖图谱，用以评估是否适合运行到边缘节点。
• 边缘自治：即边缘软件，能够在与中心断网的场景下进行自治。
• Mobility：在使用5G能力的时候，同时提出的需求，即边缘平台如何跨运营商为应用提供一致的体验，同时运营商之间的协作，也是管理平面需要考虑的。
• 异构硬件支持：即在不同的硬件平台之上，需要边缘PaaS能够提供跨平台的硬件加速等等。
• 开发者（IT/CT鸿沟）:用鸿沟描述可能有点夸大，但是通常很多时候CT和IT的Terminology非常不一样，或者说在通过边缘平台将CT等能力开放出去的时候，如何让IT背景或者大多数的应用开发者如何理解。比如我们讲到的TSN确定性网络，IEEE定义了Interval/MaxFramesPerInterval/MaxFrameSize/TransmissionSelection/TSpecTimeAware等等很多参数，第一次拿到这些会很蒙，所以边缘平台就需要将这些网络抽象的更加“developer-friendly”，比如将上述这些参数可以抽象为带宽等等；还有CT一般会有很多标准参考，如3GPP，ETSI，标准上定义了很多的接口，详细定义了接口协议，接口参数，如何让开发者更简单的支持，也是需要边缘平台考虑的。

 

基于此，EdgeGallery提出了EdgeNative的概念，EdgeNative(Draft)的想法可能包含如下场景：

• EdgeFramework：通过提供如插件式框架，多语言SDK等等降低开发者开发难度。
• EdgeData：提供更加轻量化的边缘数据库服务。
• EdgeTrusted：提供安全的边缘框架，如应用安全接入，安全容器，最小系统等等。
• EdgeAI：提供更加智能的边缘服务，同时也可以集成业界主流的一些机器学习框架，如Tensorflow，华为的MindSpore等等。
• EdgeMesh: 类比于ServiceMesh，多个边缘节点如何高效的通信，比如通过一些高效的通信协议，来降低南北向流量带宽的消耗，比如通过EdgeMesh提供给边缘应用非侵入式的电信网络加速等等。
• EdgeInfra：可以提供跨异构平台的硬件加速框架等能力。
• EdgeOrchestration：提供如Mobility，边缘自治，电信网络抽象配置等等能力编排能力。
• EdgeBlockChain：将区块链的去中心化安全能力，以及一些区块链安全能力可以作为PaaS能力更加容易的提供给应用二次开发。
• Edge-Devops：提供给开发者一站式的Devops开发体验，如一键式的工程初始化，边缘能力的样例代码生成提供给应用开发者，一些API模拟器，以及一些平台（x86/ARM）迁移工具。
• EdgeApplication：能够符合上述诉求的应用，我理解都可以称之为EdgeNative Application。

  

EdgeGallery致力为开发者提供5G原生、边缘原生的边缘计算平台与架构，欢迎大家来EdgeGallery社区参与讨论~~

参考文档：

• 注1：https://www.cs.cmu.edu/~satya/docdir/satya-ieee-edge2019.pdf 

• https://medium.com/@mfcaulfield/7-rules-for-edge-native-applications-add70cb244ac 

• https://blogs.gartner.com/thomas_bittman/2020/04/17/cloud-native-isnt-edge-native/ 

关于我们

我们是电信网络云化、自动化的信息窗口，传递最新产业动态和资讯；

我们服务于开源项目和社区，致力于推动开源来繁荣电信产业和生态；

我们是网络开源产业观点的罗马广场，原创和转载有深度见解的好文。欢迎加入！

-----

-----

欢迎添加运营小助手微信进入5G MEC社区