linus_ben的博客

假设我们在一个边缘网关设备上引入了kubeedge，那该边缘网关就相当于k8s中的一个node节点，在node节点里可以包含多个pod，每个pod就可以承载一个应用程序或者微服务，pod的实现在kubeedge中可以用docker，容器或者CRI-O技术，pod之间的通信可以直接使用部署在kubeedge中的kubelet，作为应用开发者不需要关心pod的管理和维护过程，也不需要关心如何通信，这些都由edged完成了，只需要专注于业务开发即可。数据处理的模型是来自云端的裁剪还是在本地边缘设备生成的问题；

网络切片作为一种比较前沿的技术，当前并没有太多系统的资料可以学习，很多的技术资料都是比较分散地分布在论文和一些技术博客中，笔者当前是通过论文的解读获取相关的技术信息，在过程中笔者总结了相关的技术栈，本文就是针对该技术栈的一次探讨，抛砖引玉，为读者入门网络切片提供一些帮助。

前面笔者基于5G网络端到端分解了网络切片的核心模块，包括切片编排器和核心网，接入网的切片资源基本分配方案，详见参考文献【1】，但是并没有给出详细的设计方案。本文通过对文献【2】论文的解读，着重探讨接入网侧切片编排器实现方案，进一步从技术视角对网络切片的实现进行解读。

本文开始的元数据处理将真正展现kubeedge边云协同处理数据的能力。它可以像在云上使用kubernents一样，对云原生API接口进行调用，实现应用在边缘设备上的快速部署，在云端和边缘侧的无缝迁移。这一系列解读的主题包含MetaManager、edged、servicebus和edgehub几个模块，笔者将依然按照前面逆向的思路，从代码架构、上下文通信，主流程和业务的视角进行解读。

边缘智能是边缘计算中一个非常重要的方向。它将边缘计算和人工智能算法结合起来，在边缘设备上就近处理目标检测、物体跟踪，识别等任务。这种处理方式可以降低时延，减少数据上送云端对回传网络的冲击，同时保证数据的隐私和安全性。但是，我们要面对一个问题，即现有的人工智能算法是否可以直接应用于边缘侧，还是我们需要重新设计一套原生算法。本文将探讨边缘智能网关的全栈解决方案，提供一套工程化的实现框架，从硬件、操作系统、数据平台和智能编程库选型入手，帮助读者选型快速搭建一个边缘智能网关出来。

0 背景 本文重点解读kubeedge项目中的mapper模块。该模块位于kubeedge的edgecore的南向边缘侧，主要对接入kubeedge的终端设备，进行协议的适配和转换，使其可以和边缘设备通信，转换后的协议是我们前面描述的mqtt协议，当然也支持http协议。当前该模块支持BLE、MOBUS等多种物联网协议的转换，这部分代码单独有一个git路径【1】，有自己独立的架构和功能特性。笔者将从代码架构，模块的上下文，订阅和发布消息的角度对其进行解读。1 mapper代码架构

5 5G核心网切片 核心网的网络切片与RAN的网络切片不同，首先是资源方面，不涉及空口资源，其次从协议栈方面，也跟RAN的协议栈有很大差异，主要实现用户接入管理，会话管理，数据分发等功能，在协议栈的切片上，与RAN协议栈关注的资源点不同。最后在网络层级上处在一个更高阶的位置，可以看到其下的所有网络切片资源，但是相对RAN，与用户的距离更加远，边缘计算服务能力更强，因此在涉及边缘计算卸载方面，需要考量这些因素的影响。 如下是5G核心网为例的网络切片实现方案。图中核心网处在R

前面介绍了切片的网络编排器主要实现切片的管理和控制，在切片的实现上，并没有过多涉及。切片的实现主要依赖具体的物理网络设备和资源，本小节从5G RAN层面，介绍切片的实现。5G RAN切片的实现主要包含三类资源，分别是空口资源，协议栈资源和基站设备资源。每一类资源根据其资源特点被划分为不同的切片，并被赋予不同的实例ID，最终提供给切片编排器供其分配。同时也会根据切片编排器发送的控制信息，对切片进行重新的分配，合并和扩展。

边缘计算可以支持就近的计算卸载，让数据在靠近数据源的设备上处理。对于边缘计算低时延的应用场景来说，网络性能的好坏，直接影响着卸载算法的整体耗时，决定着整个算法模型的可行性。因此如果想实现低时延卸载算法，除了获得合适的计算资源以外，还需要更加精细的网络资源的管理。对于需要进行低时延处理的数据，在网络上提供单独的通道和资源，报文在调度和转发时具备更高的优先级，保证报文可以第一时间被响应。要实现上述功能传统的做法是提供专网，5G中提出了网络切片技术，即在物理网络上切出一系列面向定制化服务的逻辑网络，使具体业务独占

前面笔者有对边缘计算系统做过一次综述，从本文开始，笔者将重点解读边缘计算技术栈，首先介绍的是边缘计算卸载技术。所谓卸载技术，即将终端或者云端的计算任务卸载到边缘侧，通过综合判断性能、能耗、时延等指标，将数据或者计算模型下沉（上传）到合适的位置。在边缘计算的卸载中，基本的卸载策略是明确卸载谁，卸载到哪里，怎么卸载，何时卸载以及卸载多少的问题。本文也基于该卸载策略展开论述，并最终给出卸载的基本功能和评判的标准。

本文继续解读kubeedge项目中的eventbus（事件总线）模块，这个模块与上一节介绍的devicetwin（设备孪生）相关联。主要通过mqtt协议与终端设备进行通信，将devicetwin模块的期望状态发布给终端设备，并订阅来自终端设备的实际状态，上送给devicetwin模块。这个模块虽然不及设备孪生模块在边缘计算模块核心，但是却是打通终端设备和边缘设备通信的重要模块。下面笔者将从这个模块的架构、与上下文模块的交互和内部核心流程三个角度，分解这个模块，帮助读者理清其中的代码逻辑和业务流程。

今天开始笔者将详细解读其中的kubeedge开源项目，该项目是云边融合的典型项目，它将云端的应用编排和管理扩展到了边缘设备，基于kubernents构建，实现了云边可靠协作、边缘自治、代理和设备管理，可以非常容易地将已有的复杂机器学习、图像识别、事件处理等部署到边缘端。本文将从设备孪生入手，详述什么是设备孪生，设备孪生的价值以及kubeedge中设备孪生是如何实现的，希望对读者学习和研究kubeedge有一定的帮助和启发。

边缘计算是近年来刚刚兴起的新方向，已经有不少公司在逐步投入人力和物力，其中既有BTA、华为、字节跳动这样的大厂，也有EMQ等创业公司，前面已经对此做过分析。本文从另外一个视角分析这个新型的方向，笔者在招聘网站上搜集了边缘计算方向的岗位，并且对这些岗位从技术、业务和管理的角度进行对比，得到边缘计算方向的能力要求，希望对想要从事这方面工作的读者有所帮助。

边缘计算开源项目是当前业界为解决垂直领域的计算和网络资源应用问题提出的一套解决方案，根据不同的应用场景有多种类型的平台。笔者将github上关注度较高的边缘计算开源平台进行了对比研究，简述了每个开源项目设计目标，基本功能和应用场景，帮助用户在自己的领域选择合适的边缘计算平台。...

当然在传统的CDN视频领域，除了网宿科技这样的老牌企业外，新兴的PPIO，字节跳动的火山引擎，UCloud等企业，也依赖布局的视频节点，利用边缘计算技术，提供更低时延，更佳用户体验的业务。参与角逐的公司，包括传统的通信设备企业，如华为、中兴、新华三，也有传统的服务器公司，如浪潮、联想，还包括三大电信运营商，电信、移动、联通，互联网BAT也不甘示弱，从阿里云到腾讯云、百度云，都在往边缘计算方向延伸，试图在其中分一片天下。针对已有的产品我们也可以从产品经理的视角去剖析其中的价值点，找到真正带动市场的点。....

上一篇文章主要从终端的角度分析了AR终端功能模块、系统组成和通信方案。本文将AR边缘计算架构的视角往上移一层，来到边缘设备侧，分析一下在边缘侧，是如何支持和实现AR相关业务和数据的处理的。我们知道AR业务需要处理大量的实时数据，包括视频、图像、位置感知、生物特征信息等，这么大的数据量，在终端设备侧根本无法完成，因此需要将其卸载到边缘设备或者云端处理。在具体实现时哪些AR业务需要卸载，卸载到哪里，如何卸载，什么时候卸载，都是需要进行系统的分析的。本文从边缘计算卸载技术的视角，设计了设备管理、数据预处理、安全管

移动AR的实现上，本文主要立足于业务，根据业务特点设计移动AR的实现架构。移动AR业务属于计算密集型，涉及大量的数据处理，加之AR终端设备通常是便携可穿戴的产品形态，在设备实现上小巧轻量，因此需要将业务部分卸载到边缘侧或者云端进行处理。基于以上原则，我们将实现框架划分为三层，分别是AR终端，移动边缘端和云端。每一层根据计算能力，能量消耗，分别处理不同的业务，各层之间相互配合完成整个功能。各层详细的模块设计如下图所示。 AR终端是AR业务的载体，主要完成环境数据和用户位姿的采集，传输和最终的信息

AR属于计算密集型技术，其实现需要高带宽、低时延和比较强的计算能力支撑，为此之前的解决方案大多采用有线的方式将AR眼镜连接到本地计算机上，这限制了用户的使用场景。随着5G和边缘计算技术的兴起，AR的移动性大大提升，AR眼镜可以通过高带宽的无线方式接入到网络中，在就近的边缘计算设备上进行计算，这为移动AR的实现提供了新的方向。本文总结了基于边缘计算的移动AR解决方案，首先对AR的概念和业务进行了分析，然后在业务分析的基础上提出了基于边缘计算的移动AR架构，最后对其中的涉及的核心技术进行了介绍。...

前面的几篇文章都是在讨论边缘计算的基本概念、发展史和实现的知识地图。本节将从应用的视角去阐述边缘计算的价值，使读者能够更加直观地领略边缘计算带来的新机会和新挑战。为此笔者选择了智能家居、智慧商场和智慧消防三个典型垂直行业应用场景，以边缘通信网关为切入点，针对空天地一体化的三张网（有线光纤、无线5G和卫星通信）分别引入边缘计算，解决智能家居场景下不同业务的网络资源需求、智慧商场场景下的室内导航和智慧消防场景下的现场实时指挥控制的问题。 因为边缘计算的加持，将对用户的体验、实时性等方面带来质的提升。

边缘计算的实现，当前有很多的开源项目，比较著名的有kubeedge，EdgeX Foundry，EdgeGallery等，还有一些边缘计算组织如ECC也提出了边云系统的架构。笔者结合自己过往的行业经验和未来规划的垂直行业， 在上述多个边缘计算架构的基础上梳理出来不同视角下边缘计算实现的架构。本文的目的不是提出一种新的边缘计算框架，而是博取所长，创建一张边缘计算知识地图。本文的行文的思路则借鉴模型驱动设计[1]，从产品经理、架构师和软件工程师三个不同的视角去审视边缘计算实现。

在上一篇博客中《万物互联之边缘计算简述-背景》[1]，笔者解释了在万物互联时代，引入边缘计算的必要性。详细说明了在新的高带宽、低时延、海量连接和海量数据的场景下，边缘计算可以发挥的价值，并在文章的结尾给出了边缘计算的4个关键词：分布、就近、边缘侧和资源下沉。那在业界对于边缘计算是如何定义的呢？当前边缘计算有哪些类别和方向？边缘计算是怎么来的，发展历史是什么样的呢？带着这些疑问，开始我们今天的话题。

从今天开始笔者跟大家探讨一个万物互联领域最近几年比较火的概念-边缘计算，乍一看这个名字会让人感觉跟当年的刚出现云计算一样，老瓶新装的东西。那是不是这样的呢？在正式引入边缘计算这个概念之前，我们先暂且不去在意这个名字。先从现实的场景入手，分析一下现在依然红的发紫的云计算是否可以解决时下的万物互联的问题，有哪些问题是无法解决的，而这些无法解决的问题是否有解决的方案。