边缘计算节点，位于靠近物或数据源头的网络边缘侧，是行业数字化智能系统的核心部分。它负责对物理世界进行感知，通过边缘与中心云的协同，实现对物理世界的数字化建模、认知、决策，再由边缘将决策结果以应用交互的方式反馈到物理世界，实现整个业务流程的闭环和持续迭代演进。
边缘场景相对于中心云的 ICT 场景有着许多非常不同的特征，是以边缘为核心的原生应用架构（简称 Edge Native）所需要考虑的：
»去中心化的，地理分布的体系架构
»数据主要在边缘实时处理，即计算和智能将跟随数据，动态地进行部署和处理
»以事件驱动（event-driven）、流式数据（streaming）、推理、异步和实时数据处理为主
»边缘与边缘的交互，边缘局部闭环自治
»多样化、异构形态的资源配置，计算 / 网络 / 存储资源深度融合按场景定制，并高度离散的设备，资源利用率低
»产品生命周期长，多厂商和多代（multi generation）
技术并存
历史上形成的单计算节点 OS 生态已收敛，如 Windows、Linux、Android、iOS 等，简称“端 -OS”。过去十年风起云涌的以 DC 为中心的云生态高速发展又形成了“云 -OS”如 AWS、Azure、GCP、阿里云、华为云等。面向行业数字化转型场景的边缘计算的再次兴起正在深深影响下一代的 IT 基础设施的体系架构。仅依靠现有的中心云架构的简单延伸是远远不够的，必须从架构角度引入新型跨域分布式的边云协同中间层（也可以称之为“边云协同 -OS”），一方面兼容广泛且多样化的边缘硬件，一方面将中心云所拥有的云服务和云生态能力适配后用于对边缘业务的赋能，以实现端、边、云之间能够紧密结合并互相协作，加速边缘原生的数字化转型解决方案的构建，并提供有效的资源配置和用户体验。
关于边云协同的能力内涵，在《边缘计算与云计算协同白皮书 (2018 年 )》中总结了资源协同、数据协同、智能协同、服务协同、应用管理协同、业务管理协同等六个协同。
为了更好的理顺各个协同之间的层次关系，方便读者理解，在本次白皮书中将六大协同合并到三大协同，具体来说资源协同保持不变；将原版本的数据协同、智能协同、服务协同合并到新版本的服务协同中；将原版本中的应用管理协同、业务管理协同合并到新版本的应用协同中。合并后三大协同的关键能力描述如下：
应用协同
应用协同实现边缘应用的统一注册接入，体验一致的分布式部署，集中化的全生命周期管理。对于边缘计算的落地实践来说，应用协同是整个系统的核心，涉及云、边、管、端各个方面。
服务协同
服务协同为边缘应用的构建，提供了所需的关键能力组件以及快速灵活的对接机制，从而有效提升边缘应用的构建速度。服务协同包括两个层面：一个层面是平台服务的协同，在平台服务协同中又包括两个方面，一方面是来源于中心云的云服务与云生态伙伴所提供的能力，包括数据类、智能类、应用使能类的能力。另一方面是通过云原生架构，提供基于 Operator 架构的服务接入框架，为边缘服务的分发订阅、接入、发现、使用、运维提供一整套流程。
另外一个层面，对于云原生架构中的微服务，提供跨越边和云的服务发现和协同机制，使得位置感知的数据传输转变为位置透明的、基于服务化的业务协同。
资源协同
从单节点的角度，资源协同提供了底层硬件的抽象，简化上层应用的开发难度。从全局的角度，资源协同还提供了全局视角的资源调度和全域的 Overlay 网络动态加速能力，使得边缘的资源能否有效率的使用，边缘与边缘、边缘与中心的互动能够更实时。
边缘与中心云间的三大类协同
应用协同
综述
应用协同是指用户通过边缘计算平台在云上的管理面将开发的应用通过网络远程部署到用户希望的边缘节点上运行，为终端设备提供服务，并且可以在云上进行边缘应用生命周期管理。应用协同还规定了边缘计算平台向应用开发者和管理者开放的应用管理北向接口。对于边缘计算的落地实践来说，应用协同是整个系统的核心，涉及云、边、管、端各个方面。
相比集中在数据中心的云计算，边缘计算的边缘节点分布较为分散，在很多边缘场景中，如智能巡检、智慧交通、智能安防、智能煤矿等，边缘节点采用现场人工的方式对应用进行部署和运维非常不方便，效率低成本高。边缘计算的应用协同能力，可以让用户很方便地从云上对边缘应用进行灵活部署，大大提高边缘应用的部署效率，降低运维管理成本，为用户边缘场景实现数字化、智能化提供了基础。这也是应用协同对于边缘计算场景的价值所在。
关键挑战
»传统边缘应用部署的物理节点分布可能较为分散，部署过程中存在大量需要人工现场操作的步骤，部署方式不够灵活方便，效率低下。边缘应用缺少边云协同管理方案，边缘计算平台也缺少统一的应用管理北向接口。
»边缘计算复杂场景下应用分发比较困难。用户应用部署到海量的边缘节点上，需要大规模分发应用的镜像。边缘和中心云之间一般跨网络连接，网络的稳定性相对较差。中心镜像仓库高并发下载带来高昂的带宽成本也是一个非常严重的问题。另外，用户应用日益复杂化，跨越边云的分布式应用场景越来越多，但是对应的跨边云应用分发机制还比较缺乏。
»边云计算场景下边缘应用管理困难。边缘节点与云端通过城域网互联，漫长的网络链路使得二者连接不够稳定，且易因各种不确定因素导致边缘节点整体断连。在断连后，边缘节点及其上的应用实例将处于离线状态，并且缺乏 IT 维护人员及时的管理恢复。此时边缘应用会出现不可用的问题，边缘侧的业务连续性及可靠性都将受到极大的挑战。
整体架构
面对上述挑战，边缘计算应用协同系统整合边缘节点资源，通过边缘管理模块与云上控制模块合作，共同完成应用协同。目前边缘计算领域多种技术架构并存，其中基于云原生技术的边缘计算架构发展迅速，并逐渐成为主流。这里以基于云原生技术的边缘计算为例给出系统参考架构，同时该架构对于边缘计算领域其他技术也有一定参考价值。边缘计算边云应用协同系统参考架构如下图所示，整个系统分为云上和边缘两个部分，云上部分包含云上控制面和云端镜像仓库，云上控制面主要用于接收用户提交的应用部署请求信息并对边缘应用进行生命周期管理，云端镜像仓库主要用于对用户提交的应用镜像进行分级转发缓存；边缘部分主要为边缘节点和边缘镜像仓库，边缘节点用于为边缘应用提供运行环境和资源，边缘镜像仓库为边缘应用提供具体的镜像加载服务。
用户将其开发的应用通过边缘计算平台下发部署到边缘节点上运行，因此需要边缘计算平台提供清晰明确的应用部署接口。应用部署接口定义了用户与边缘计算平台之间的交互方式与功能边界。
边缘计算平台为用户提供标准化的北向接口，开放各种应用部署和调度能力，用户的所有应用部署需求，都以服务请求的形式向边缘计算平台提交，边缘计算平台将执行结果以服务响应的形式返回给用户。用户使用边缘计算平台进行应用部署，应该对应用的目标形态提出需求，以部署配置文件的形式进行描述，并提交给边缘计算平台。
边缘计算平台会根据用户提交的需求以及既定的调度策略，选择最能满足用户需求的节点进行调度，获取相关节点资源，创建应用实例，创建相关资源如中间件、网络、消息路由等，完成应用在边缘节点上的下发部署。用户通过北向接口提交的应用的部署需求，通常会涉及如下方面：
»工作负载信息：包括应用的镜像地址、应用实例数量、应用标签信息、应用环境变量配置等等。
»调度策略：应用调度策略是边缘计算平台调度能力的外在呈现方式，用户只能在平台既定的框架下选择、制定符合自己需求的调度策略。更精细、更高效、更灵活的调度策略需要边缘计算平台自身更强大的调度能力作为内在支持。从用户的角度来讲，应用调度策略可能会包括如下类型：将应用部署到指定边缘节点或边缘区域；将应用自动部署到用户访问最密集的地区；保证一定百分比的应用实例所处地区的网络延迟低于给定值；在给定的节点组上部署并保证各个节点负载均衡；在达到指定服务效果的前提下资源费用最低等等。
边云协同应用协同系统架构
资源需求：资源需求代表每个应用实例在边缘节点上运行所需要的资源数量下限值和上限值，当一个节点无法提供满足下限值的资源时，表示边缘节点资源不足，应用实例不会被平台调度到该节点上执行，当一个应用实例运行所占用的资源超过上限值时，表示应用程序可能发生了异常，需要紧急停止。常用资源类型包括 CPU、内存、存储、网络带宽、GPU、NPU 等。
»网络需求：应用对于网络 QoS 和 QoE 有一定需求，包括网络抖动、网络时延、吞吐率等等
»部署模式：应用在边缘的部署模式，可以分为两类，一类为根据部署策略和调度结果直接将应用实例部署到对应节点，一类为收到客户端访问请求后触发应用实例的部署。
»中间件需求：未来如数据库、5GC 等能力会以中间件的形式提供给应用进行使用，用户可以向平台提出应用对中间件的需求，由平台来将相关中间件进行实例化，为用户应用提供服务，避免用户自己管理中间件的风险。
关键技术
1、应用分发
»应用亲和性分发
利用应用亲和性特性，可以将有关联的应用部署到同一个节点以提升应用间交互效率。一个 Pod 里的多个容器可以共享存储和网络，可以看作一个逻辑的主机，共享如 namespace，cgroups 或者其他的隔离资源。一个Pod 里的多个容器共享 Pod 的 IP 和端口 namespace，这些容器之间可以通过 localhost 来进行通信，所需要注意的是不同容器要注意不要有端口冲突即可。不同的Pod 有不同的 IP，不同 Pod 内的多个容器之间不可以使用 IPC（如果没有特殊指定的话）通信，通常情况下使用Pod 的 IP 进行通信。一个 Pod 里的多个容器可以共享存储卷，这个存储卷会被定义为 Pod 的一部分，并且可以挂载到该 Pod 里的所有容器的文件系统上。
»应用大规模分发技术
边缘计算场景中，用户应用需要部署到海量的边缘节点上，需要大规模分发应用的镜像。这种应用大规模分发场景的部署速度、部署成功略等性能受制于短时间高并发读取、网络稳定性、网络带宽等问题。容器应用部署过程中需要下载容器镜像文件，如果在大规模边缘集群环境中，比如 100K 台边缘节点，每个应用镜像按照500MB 计算，如果直接从中心镜像仓库下载，数据量是50000GB，这对于镜像仓库的冲击是致命的。边缘和中心云之间一般跨互联网连接，网络的稳定性相对较差，比如煤矿矿井边缘、工厂车间边缘、公路边缘场景，很难保证边缘与中心云网络连接的稳定性。中心镜像仓库下载带来高昂的带宽成本也是一个非常严重的问题，这对于提供镜像仓库的云服务提供商来说是不可接受的。边缘计算平台可以采用镜像分级缓存、边缘镜像站点加速、P2P 分发等方法来提高应用大规模分发性能。
»跨边云统一部署技术
用户应用日益复杂化，跨越边云的分布式应用场景越来越多。与云计算环境相比，应用在边缘侧部署和运行受本地环境的影响非常大，而本地环境自身又是非常不稳定的，充满了不可预知性和动态性，因此边缘计算平台需要根据环境资源信息动态调整业务部署。当边缘侧环境发生重大变故时，包括边缘节点故障、边缘侧用户请求飙升等等，边缘侧的资源无法满足用户应用的计算需求，此时需要将业务负载迁移回云上运行，以保障用户应用的可用性。因此边缘计算平台需要提供应用跨边云统一部署能力，以实现用户应用的边云协同，并且能够向应用开发者屏蔽这种因部署位置的差异性带来的特殊设计和开发工作量。
»serverless 技术
边缘应用的开发者希望能够专注于应用开发工作，而应 用 的 构 建、 部 署 和 运 行 问 题 则 交 给 平 台 来 自 动 完成。serverless 技术的出现使得用户只需要编写函数代码（function）和包含函数构建部署信息的配置文件（config），将代码文件和配置文件提交给平台就可以自动将代码构建成应用，并将应用实例部署到边缘侧或云端集群，无需关注具体构建和部署细节。serverless 技术提供标准化的应用开发流程，为边缘应用的开发人员节约了大量的时间和精力，大大提升了边缘应用开发、运维和迭代的效率。以云原生的 serverless 技术为例，整个系统分为构建系统（Build）、服务系统（Serving）和事件系统（Eventing）。构建系统可以将用户代码进行编译，并且自动化构建应用容器镜像。服务系统可以将构建好的应用实例下发部署，按需对边缘应用负载规模进行自动化伸缩，并且为边缘应用配置好相应的流量路由规则和服务访问通路。事件系统可以将事件源进行抽象，并对生产、消费等事件通过消息通道进行有效传递，同过订阅机制进行事件处理。
2、应用管理
»应用离线自治技术
相较于传统的以云数据中心为核心的云服务，边缘计算所服务的业务领域有着自己的独有的特点。在边缘节点与云端正常连接时，边缘节点及其上的应用的生命周期管理都由云上的管理组件负责。然而，边缘节点与云端通过城域网互联，漫长的网络链路使得二者连接不够稳定，且易因各种不确定因素导致断连。在断连后，边缘节点及其上的应用实例将处于离线状态，并且缺乏 IT 维护人员及时的管理恢复。此时，边缘侧的业务连续性及可靠性都将受到极大的挑战。因此，边缘节点在离线场景下的管控是边缘计算服务必不可少的功能之一。边缘应用离线自治技术通过维护边缘节点监控关系列表、调度优先级列表及边缘信息同步机制，能够保障边缘节点在云端管理面断开的场景下进行离线自治，维持系统正常运行，直到边云连接恢复正常。
»多设备多副本互备
边缘节点运行状态和网络状态不稳定，可能会出现单个节点运行故障或者网络断开，这些问题都会导致该节点上运行的应用实例不可用。对于无状态应用，可以创建多个副本，同时添加应用部署的反亲和性特性，维持预设副本数的同一应用的不同实例在不同节点上分散部署运行，可以避免单节点故障导致所有应用实例全部不可用的问题，提升应用的可用性。
服务协同
综述
服务是指具备明确的业务特征，由一个或多个关联紧密的微服务组成，可直接面向客户 / 用户进行打包、发布、部署、运维的软件单元。
服务协同是指通过在边缘计算平台提供用户需要的关键组件能力，以及快速灵活的服务对接机制，从而提升用户边缘应用的构建速度，在边缘侧帮助用户服务快速接入边缘计算平台。服务协同主要包括两个方面，一方面是来源于中心云的云服务和云生态伙伴所提供的服务能力，包括智能类、数据类、应用使能类能力。另一方面是通过云原生架构，提供一套标准的服务接入框架，为边缘服务的接入、发现、使用、运维提供一套完整流程。智能类服务是在人工智能场景下，通过使用人工智能服务对海量数据进行预处理及半自动化标注、大规模分布式训练，生成自动化模型，并支持部署到云上和边缘。
利用边缘服务将其推送到边缘节点，提供边缘传输通道，联动边缘和云端数据；边缘 AI 服务实时获取数据，通过推理进行瑕疵检测，根据结果调整生产设备参数，并将数据和结果周期上传回云端，用于持续模型训练和生产分析。
数据类服务按照距离用户的远近可以分为云端数据库和边缘数据库。云端数据库即是部署在云端，负责对云上服务处理的数据进行存储，并提供高效的查询等，云端数据库存储数据量大，查询响应快，但是边缘计算场景下，由于和用户设备过远，数据传输慢，导致无法实时响应用户数据请求，无法很好满足用户实际述求。因此边缘场景下延伸出了边缘数据库概念，顾名思义边缘数据库是部署在边缘侧的，它的好处是离终端设备近，终端设备进行采集数据后上报到边缘端的服务非常快，而边缘端的服务经过分析计算后可以持久化存储在边缘设备中，这样即保证了数据的实时处理，也使得当边缘网络端开时，边缘数据库储存的数据可以支持边缘自治。在边缘场景下，数据采集频繁，上报数据量大，会产生大量冗余以及不符合规范的数据，对数据的分析挖掘造成了很大的麻烦，需要边缘侧进行数据清洗和数据分析整合使用边缘时序数据库等保证数据的时序，当实时处理后，可以根据数据的具体类型和场景，协同上报到云端数据库中进行进一步处理，或者在本地存储待后续使用。
应用服务主要是对一般中间件等有状态的服务部署场景中，如何部署在边缘场景进行分布式运行。由于中间件等有状态服务架构复杂，涉及很多复杂化处理，因此应用服务主要提供的是边云分布式开发框架和运行框架，通过提供标准的接入规范和开发框架，可以帮助这类服务快速集成开发，并且能够方便的部署集成到边缘计算环境中，同时这种统一的开发框架，可以方便应用服务的改造，帮助不同形态服务的迁移，满足快速上云诉求。而运行框架，则提供了规范的运维规范、运行中通信规范等，另外还提供了开箱即用的微服务注册、发现和访问机制，可以帮助服务进行全生命周期的管理，并且满足跨边云应用协同，在边缘计算场景中，不同的设备、不同的边缘云设施中，都可以快速无缝协同工作，从而提高服务协同能力，降低用户使用难度，部署难度以及运维难度。
关键挑战
边缘计算场景下，服务协同面临着几个较为严峻的挑战：
»数据存储困难，性能可靠性无法保证。随着越来越多的业务连接到物联网，与 IoT 关联产生的数据量和时序数据越来越多，而边缘侧资源紧张，对数据存储的成本、响应的性能和可靠性产生了极大的挑战，随着业务种类不同，数据的上报结构各不相同，对数据的存储也带来了极大的不便。
»数据量大，实时性无法得到保证。边缘智能场景下，大量设备接入边缘云，上报数据量大，采样类型种类多，导致数据存在大量冗余情况，对于智能化场景产生极大挑战，而边缘侧场景的高实时要求又是一大难题。
»应用接入不规范，难以统一管控。边缘服务涉及多种类型服务接入，其中数据服务、智能服务、应用服务等开发框架、语言以及使用方式都不一样，导致服务协同部署运维难度增大，跨云场景也因为接入方式不一致而无法统一管理。
»服务协同下服务运维困难。由于服务大部分需要部署在边缘侧，而边缘处的设备大多数都处于机房、基站等偏远地点，站点维护人员技能低，导致设备数据收集困难甚至无法收集，一旦服务出现问题存在无法自愈或者修复复杂等情况。
微服务的流行，解决了单体式应用不能快速迭代、限制技术栈的选择、技术债务不断堆积等问题，但同时也引入了新的问题，那就是微服务化应用之间的交互。
随着业务的发展，部分云上能力需要下沉到边缘以提供更低的时延、更少的带宽占用、更高的网络安全和更好的隐私保护。但边缘的资源往往是有限的，应用需要利用云的海量资源和弹性。微服务需要根据业务需求智能地部署在边和云的任何位置。边边、边云微服务交互中出现的边云应用访问困难、缺少服务发现和流量治理机制等问题亟待解决。
整体架构
服务协同架构是为边缘应用的构建，提供所需的关键能力组件以及快速灵活的对接机制，从而提升边缘应用构建速度而设计。其主要可以分为两个模块：服务开发框架和服务市场。
服务开发框架提供了灵活的接入机制，方便用户服务可以快速接入边缘计算平台，为边缘服务的接入、发现、使用、运维提供一套整体流程。
服务市场则对接生态，借力合作伙伴的能力，将不同的智能类、数据类以及应用使能类服务接入到服务市场集成使用，达到快速构建边缘服务的能力。
边缘计算服务协同框架
如图所示，服务协同分为两个主体角色：服务开发者和服务使用者，开发者作为服务提供者，根据自身业务需要进行代码开发，然后根据服务接入规范以及服务协同框架中提供的开发框架进行集成打包，封装出可以部署在边缘计算平台中的服务，然后上传到服务市场中对外提供服务；服务使用者则订购服务市场中的服务，并根据使用场景进行订购下发部署请求。服务协同框架通过利用应用协同框架能力，将服务下发到对应的云端或者边缘节点中去，边缘节点按照云端策略实现对应服务，通过边缘与云端的协同实现面向客户的按需的边缘服务；而云端则负责其本身需要的服务能力和对边缘节点的分布策略的控制。
服务开发框架主要包括两个方面：
1、统一标准的接入规范，由于服务开发的框架、语言使用习惯等的千差万别，接入规范可以保证在兼容用户的服务并统一服务部署运行运维等能力，保证服务可以无缝接入边缘计算平台；
2、接入开发框架，提供符合业界标准的开发框架，为边缘服务的接入、发现、使用、运维提供一整套流程，帮助用户只需要专注业务的开发。
服务市场则是对接不同生态服务，发展云生态伙伴包括智能类、数据类应用使能类服务的接入，并对接开源Operator 框架，将有状态中间件服务接入提供给用户使用，帮助用户边缘服务的快速构建接入。
关键技术
1、边云协同数据使能
随着越来越多的事物连接到物联网，与 IoT 设备相关联的数据量及其生成的时序数据量（包括设备状态、元数据和传感器读数）呈指数级增长。然而，边缘侧计算资源紧张，对数据库性能、数据存储成本、可靠性等都提出了新的挑战。同时，随着数据源的多样化和业务发展，要求边缘数据库要能灵活存取多种数据模型，降低业务变更难度和运维成本。
时序数据是指带有时间标签，按时间顺序变化的数据。
通常时序数据有如下几个特点：
»数据量大，每秒上千、上万甚至于上亿条数据
»时间特性强，数据通常按照时间顺序抵达
»主要是写入和读取操作，没有更新操作
»大量的统计查询要求
时序数据库作为一种针对时序数据进行高度优化的垂直型数据库 , 可以很好的解决前面的问题，它提供时序数据的大并发，低时延，高性能，高压缩，低成本，schemaless 数据存储，还能提供多种维度的聚合分析和趋势洞察。
传统的关系型数据库并不适用于时序业务的场景，到目前为止，关系型数据库处理大数据集的效果依旧不理想，且占用存储空间大，缺少一些共通的对时间序数据分析的功能和操作，比如数据保留策略、连续查询、灵活的时间聚合等。
下面介绍下时序数据库的一些基本概念
Metric: 度量，相当于关系型数据库中的 table。
Point: 数据点，相当于关系型数据库中的 row。
Timestamp：时间戳，代表数据点产生的时间。
Field: 度量下的不同字段。比如位置这个度量具有经度和纬度两个 field。一般情况下存放的是会随着时间戳的变化而变化的数据。
Tag: 标签，或者附加信息。一般存放的是并不随着时间戳变化的属性信息。
Series: 时间线，一个数据源采集的一个指标随着时间的流逝而源源不断地吐出数据这样形成的一条数据线称之为时间线。
边云协同的时序数据库的关键技术主要包括：
»轻量级
边缘节点计算资源有限，相比云端数据库而言，边缘时序数据库作为云端数据库的延伸，保留数据库的基本功能，去掉了一些不必要的功能，比如分布式，备份恢复等。轻量级数据库具有对环境的依赖小，占用内存空间少的特点。
»数据协同与可靠性
根据图所示，数据协同由端 - 边 - 云共同完成，数采的数据直接接入边缘中心节点，一般会经过实时分析、资产分析后，再存入边缘时序数据库，供边缘开放 API做时序分析查询。此时数据库中的数据会定期与云端进行汇总。由于数据在存储时进行了压缩，为了节省传输带宽和性能，我们常常以数据文件的方式与云端进行同步。此外，由于边缘时序数据库是一个轻量级数据库，为保证数据库的可靠性，中心节点采用双合主备模式，数采网关采取双写。当边缘主中心节点出现问题时，备中心节点可以马上接管业务，不会造成数据丢失和业务中断。
»LSM Tree
传统数据库或现在一些 NoSQL 数据库存储采用的都是 Btree，这是由于其在查询和顺序插入时有利于减少寻道次数，对于 90% 以上场景都是写入的时序数据库，B tree很明显是不合适的。边缘时序数据库采用 LSM Tree，通过将大量的随机写转换为顺序写，从而极大地提升了数据写入的性能。
»列式存储与向量化
针对时序数据普遍的分析统计查询场景来看，需要对所有 Filed 进行统计的情况并不多，列式存储引擎将数据按照基于列的方式进行集中存储，查询过程中可以定位到指定列，可有效降低数据库系统负载，提高整个查询的吞吐量。同时，列式存储可以使用一些基于列数据压缩算法，由于数据类型相同，数据集中，压缩算法的性能会更好，可以大大的减少数据的存储成本。
向量化查询是一种基于列式存储设计的高效查询算法，现在已成为构建高效分析查询引擎流行做法，相比经典的火山模型，向量化查询大大减少了查询的迭代次数，能有效提升整个查询的性能。
»查询结果缓存（rollup cache）
在数据的分析统计中，我们常常需要计算 Filed 的值在指定时间窗内的和或者平均值等，设置查询结果缓存可以记录下每次查询的时间窗和返回值，如果需要在更大时间窗内进行统计，则可以依赖已缓存的时间窗和值进行计算就可以快速得到结果，从而省掉再次查询的时间和资源消耗，能有效提升用户体验。
»内存分配与回收
在计算资源有限的情况下，合理分配程序使用内存尤为重要，边缘时序数据库可以根据实际情况配置程序运行中各种 cache 使用的内存大小以及总内存大小。内存分配对应是内存回收，当 cache 使用已达到配置上限时，边缘时序数据库需要有高效的 cache 回收算法，将过期的或者最近未使用的内存进行回收置换，同时还要保证较高的 cache 命中率。
2、边云协同 AI 使能
随着 AI 技术在边缘越来越多的广泛应用，同时也带了巨大的挑战，包括：
»AR、VR、互动直播、视频监控等场景下非结构化数据为主 , 主要采用深度学习方法，主要挑战在数据量大 ,资源用量大，实时要求高，标注困难等。
»工业场景下 IoT 结构化数据为主，主要使用传统机器学习算法，方法多样，与业务相关性高，主要挑战是样本少、冷启动和要求模型可解释和可靠性。面对上述问题，通过边云协同 AI 的相关技术可以很好解决这些问题。在边缘计算场景下，AI 类应用占据主流。
由于边侧计算资源紧缺、网络环境复杂，以及数据量样本量少、数据样本分布不均、数据隐私等原因，AI 类应用在边缘的训练和推理还存在着训练收敛时间长、训练效果差、推理精度低、推理时延高等问题。通过边云协同 AI 技术以很好的解决在边缘训练和推理的精度、时延、通信量、数据隐私等问题。边云协同 AI 框架将会在算法、接口、部署、性能几个方面带来了好处：
»算法：集成多种适合边缘的训练推理算法，适用场景广。
»接口：提供边云协同的 lib 库代码，兼容主流框架，tensorflow，pytorch，mindspore；开发简单，原生框架的训练代码经过很少改动可以实现其边云协同的。
»性能：针对边云协同进行了通讯、存储的优化，使得边云协同的训练推理更高效。边云协同 AI 框架的关键技术包括：增量学习、联邦学习、联合推理。
1）增量学习：
增量学习真对单个租户从时间的维度帮助提升模型效果。数据在边缘侧持续产生，传统的方式是人工定期的收集这些数据，定期的在云上或边上的机器进行重新训练以改进模型效果。这种方式浪费较多的人力，并且模型更新的频率较慢，不能及时用上最新更优的模型。通过增量学习，可以持续监控这些新产生的数据，并通过配置一些触发规则来决定是否要启动训练、评估、部署，以自动化的持续改进模型效果。
2）联邦学习：
联邦学习跨多个租户从空间的维度帮助提升模型效果。数据天然是在边侧产生的，边云协同联邦学习通过边缘侧的数据联合训练得到一个模型，目的是基于不上传原始数据的前提下，能充分利用分散在不同边侧的数据。
单租户场景，基于数据不愿意上云的假设下，租户希望直接利用在边缘产生的数据就近在边缘节点进行训练得到模型，但数据在租户内部是分散在不同节点的，在租户内部集中训练需要另外采购集中训练的机器会带来额外的采购成本，因此可以采用边云协同联邦学习，直接使用边缘节点的计算能力进行训练，使用云上的聚合器进行聚合，在保证数据隐私和高效传输的前提下，提供更快的收敛速度，精度更高、场景更丰富的聚合算法，以完成模型的联合训练。
3）协同推理：
协同推理利用推理性能较强的云作为推理后端来提升推理效果。
对于推理来说，直接在边侧推理可以有更小的时延和更大的吞吐，而直接在云侧推理可以带来更好的推理精度。如何在边侧推理资源有限的情况下，使得时延和吞吐不明显降低的情况下，使得推理精度提高是个问题。协同推理技术通过把把边侧较难的推理样本检测出来，将其发送到云端进行推理。这样，较简单的样本在边侧推理保证了时延和吞吐，而较复杂的样本在云上推理使得整体精度得到提升。
Workers:
»执行训练或推理任务，训练 / 推理程序，基于现有 AI框架开发。为了使用边云协同的能力，worker 中通常会包含 lib 库。
»按需启动，docker 容器或 function。
»不同特性对应不同的 worker 组合，可部署在边上或云上，进行协同。比如协同推理特性可以是云上的一个 worker 运行大模型、边上的一个 worker 运行小模型，协同完成推理任务。
»Worker 可以是用户基于一个基础镜像开发的，或者系统内置一些固定功能的 worker 模板，比如联邦学习的聚合器。
Lib:
»面向 AI 开发者和应用开发者 , 暴露边云协同 AI 功能给应用
»Lib 库不是一个新的、也不会取代现有的机器学习框架，更多的是配合主流框架（TensorFlow、Pytorch、Mindspore）以完成边云协同能力的扩展。用户使用此 lib 库不会对现有的训练推理代码带来较大的改动。
GlobalCoordinator：
»统一边缘 AI 服务 API，这是用户使用边云协同 AI 的入口，在此创建边云协同训练或协同推理任务。
边云协同 AI 架构
»跨边缘管理：管理 LocalController 的生命周期。
»跨边缘协同：协调在云上或边上的 worker 以共同完成协同训练或者协同推理任务。
LocalController：
»特性本地流程控制，本地 worker 生命周期的管理。
»本地通用管理 : 模型 , 数据集等
»状态监控和上报：协同推理和训练的任务状态监控，上报到 GlobalCoordinator。
3、平台服务接入
当前云计算场景下，衍生了非常多的开发语言，Java、Go、C/C++、nodejs 等等，相关的开发框架也有非常多，因此导致了不同的服务平台中接入的方式互不相同，这也导致了如果一套服务在一个平台运行后需要迁移到另一套云平台中，必须进行代码版本的改造，从而加大了迁移成本，导致大量人力物力都耗费在无价值的事情中。
随着边缘计算逐渐兴起，用户的应用服务日益复杂化，跨边云的分布式应用场景越来越多，跨云部署、治理以及管理运维的述求越来越多，而不同平台之间的架构模型差异，接入差异导致了用户服务的接入困难，因此需
要一套统一的服务接入标准，通过定义出行业认可的服务接入规范，规范不同平台的接入规则，从而使得一套服务可以无障碍部署在不同平台，保证跨云管理变得简单，无需在花费时间在考虑服务迁移改造等问题。接入平台服务需要满足一下几个方面：
»支持不同的开发语言、开发框架
»支持当前通用的通信协议
»具有成熟的部署、运维能力
当前服务协同使用了如下技术作为接入规范的参考基准：
1、基于 Operator 概念的 Operator-Framework 框架技术从概念上讲，Operator 会收集人类操作知识，并将其编码成更容易分享给消费者的软件。
Operator 是一组软件，可用于降低运行其他软件的操作复杂程度。它可以被看作是软件厂商的工程团队的扩展，可以在 Kubernetes 环境中监控软件的运行情况，并根据软件的当前状态实时做出决策。
从技术上讲，Operator 是一种打包、部署和管理 Kubernetes应用程序的方法。
使用 Operator 可以：
»重复安装和升级。
»持续对每个系统组件执行运行状况检查。
»汇总现场工程师了解的情况并传输给所有用户，而非一两个用户。
Service Broker 也是朝着实现应用程序的编程式发现和部署的目标前进了一步，但是它并非一个长时间运行的进程，无法执行第二天的操作，比如升级、故障转移或扩展。而 Operator 可以持续监控集群的当前状态，这对于边缘云服务场景下的集群形态则更加合适。
开源的 Operator-Framework 则是基于 Operator 概念衍生的一个新技术，其本质是一个开源工具包，用以有效、自动化和可伸缩的方式管理 Kubernetes 原生应用程序。
该框架由 Operator SDK 和 Operator Lifecycle Manager（OLM）两个部分组成。
OLM 扩展了 Kubernetes，提供了一种声明式方法来安装、管理和升级集群中的 Operator 服务以及其依赖。
它使得 Kubernetes 管理员能够从目录中发现并安全安装Operaotr，并根据用户需要进行自动或手动式更新。
Operator SDK 提供了高级 API、有用的抽象和用于构建Kubernetes 应用程序的项目脚手架，并使用 controller-runtime（控制器运行时）库简化操作器的编写。
Operator-Framework 是当前业界比较成熟且广泛接受的技术，服务协同框架基于该技术，同时根据不同场景定义统一规范接入标准，形成用户界面的统一管控，提高服务的接入、运维等成本，极大的提供用户体验。
2、Open Service Broker API
服务代理者（Service Broker）是用来管理服务的生命周期，平台与服务代理者交互以提供、访问和管理他们的服务。OSBAPI（Open Service Broker API）则在此基础上提出了一种规范，可以允许软件供应商、SaaS 提供商和开发者轻松运行在 Cloud Foundry、Kubernetes 等云原生平台上，并为其工作负载提供后备服务。这种规范已经被许多平台和数千个服务提供者采用，用于描述一组简单的 API endpoints，而这些 endpoints 可用于设置、访问和管理服务产品。OSBA 定义了这些交互，允许软件提供商向任何人提供服务，而不管这些软件提供商希望使用什么技术或基础设施。基于 OSBA 规范构建的 Service Broker 服务都有相同直观的生命周期命令集。这些命令集具有以下操作：
»获取服务代理提供的后续服务
»发放新业务实例
»销毁服务实例
采用此模型带来的好处是：1、开发人员可以将自己的应用程序和容器连接到他们需要的后台服务，无论后台服务如何，操作都是一致的；2、不再需要人工发放和委托服务，只需要进行配置服务和计划市场，减少许多管理开销。
4、跨边云服务发现和流量治理
»局域网内边边服务发现和流量治理在该场景下要求相互访问的边缘节点之间网络能够互通，具体见下图。
局域网内边边服务发现和流量治理
»API Gateway
所有的应用程序都不会运行在一个封闭的环境中，当有用户或者第三方应用程序接入时，一定会在系统的某个边界开放部分微服务，这正是 API Gateway 要解决的问题——将微服务在集群边界特定端口暴露，供集群外部应用访问。一个边缘集群会被切割为多个边缘现场，形成多个网络域，同一现场内的边缘节点可以相互通信，不同现场间的边缘节点不能相互通信。具体见下图。
API Gateway
»跨边云的服务发现和流量治理
边缘计算的初期阶段人们会说“我需要把 A 应用部署在边缘”；随着业务的发展，人们会说：“我边上的 B 应用需要访问云上的 C 应用，云上的 D 应用需要访问边缘的 E应用”；最后，人们会说：“我的 F 应用需要访问 G 应用，F 和 G 智能的运行在最适合它的地方”。见下图所示。
应用智能运行在合适位置
跨边云服务发现和流量治理是应用智能运行在合适位置的基础，逻辑模型见下图所示。
跨边云应用的服务发现和流量治理
资源协同
综述
边缘基础设施通常由多个边缘节点设备（边）组成，包括部署在城域网络侧的近场边缘云、5G MEC、工厂的现场边缘节点、工厂的智能设备如机器人等，提供边缘计算所需的算力，存储，网路资源。
为了降低上层应用适配底层硬件的难度，就需要通过一个中间层次来对底层硬件进行抽象，使得上层应用可以用一点接入、一次适配、一致体验的方式来使用边缘的资源。从单节点的角度，资源协同提供了底层硬件的抽象，简化上层应用的开发难度。从全局的角度，资源协同还提供了全局视角的资源调度和全域的 Overlay 网络动态加速能力，使得边缘的资源能否有效率的使用，边缘与边缘、边缘与中心的互动能够更实时。
挑战
»设备异构挑战：边缘硬件的计算 / 网络 / 存储资源和容量，往往会深度按业务场景进行定制。边缘硬件的计算架构也呈现出多样化的趋势。同时，产品生命周期长，多厂商和多代技术并存。因而在构建边缘解决方案时，就需要考虑如何能够更好的对异构和多样化的边缘设备进行抽象、管理和运用。
»资源受限挑战：单个边缘节点的资源是受限的，如果应用需要实现弹性伸缩或故障切换，需要由多个边缘节点组成某种形式的边缘节点组或集群，应用在此集群内进行部署、伸缩和治理。
»边边 / 边云通信挑战：典型的实时互动类场景如在线教育、云游戏等，对于多个边缘节点之间、边缘节点到中心云之间的通信链路，都有比较明确的业务要求。
如何能够实时构建和维护，低时延、高质量、低成本的边边 / 边云通信链路，是一个关键的技术挑战。
整体架构
资源协同具体来说包括三个方面：
»硬件抽象：通过插件框架的形式，对边缘硬件的计算、存储、网络等资源进行模型抽象，使得不同的硬件厂家可以为自己的产品提供插件化的定义和描述，向应用开发者和运维人员提供了一个统一的资源能力描述、部署、运维管理方式。
边缘计算资源协协同框架
»全局调度：对于是需要实现广域化、多节点部署的边缘业务，实现基于策略的全局资源调度，使得应用可以灵活的按照自定义的策略实现应用实例的多节点部署和动态切换。
»全域加速：实现从中心云到边缘、边缘到边缘之间的互联互通、高效的消息路由，进一步还可以构建全局的 Overlay 网络实现各节点的优化寻址和动态加速，为基于服务质量和确定性时延的策略调度打下坚实基础。
关键技术
1、基础设施服务化
结合场景和应用部署需求的多样化，边缘计算节点在资源层面，往往需要提供多类型的计算方案，包括基于裸机、虚拟机、容器甚至函数计算等。其中基于 Docker 和Kubernetes 的容器计算，由于结合了轻量化、易管理、开放性、丰富的能力等多个特点，是面向未来最有潜力的边缘计算模式。
Docker 叠加 Kubernetes 构建了一个可移植的、可扩展的边缘计算平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。Kubernetes 拥有一个庞大且快速增长的软硬件生态系统。基于 Kubernetes 与基 础 设 施 分 离， 支 持 可 在 Ubuntu、RHEL、CentOS、CoreOS 等主流的 OS，因此可以支持多样化的硬件部署。
因而，基于 Kubernetes 构建的边缘计算平台也可以继承类似的异构多样化硬件的能力，用来实现对于异构边缘硬件的发现、监控和调度。
边缘计算平台，通过提供一个硬件设备抽象的设备插件框架（Device Plugin Framework），建立了 Kubernetes和设备插件模块之间的桥梁。它一方面负责设备信息的上报到 Kubernetes，另一方面负责设备的调度选择。
硬件厂商可以为自己的硬件定制实现对应的设备插件，用来将系统硬件资源和监控信息发布到边缘平台。目标设备包括 GPU、高性能 NIC、FPGA、InfiniBand 适配器以及其他类似的、可能需要特定于供应商的初始化和设置的计算资源。设备插件可通过手动部署或作为DaemonSet 来部署。如下图所示。
边缘硬件设备抽象框架
边缘硬件设备抽象框架包括以下几个关键能力：
»设备插件的注册：设备插件需要以客户端的身份向边缘节点代理上报以下几个信息：1）设备插件所管理的设备名称；2）设备插件所监听的端口；3）交互的API 版本。
»服务启动：设备插件会启动一个后台服务并以这个服务对外提供信息。
»持续监听：当设备插件所关联的服务启动之后，边缘节点代理会建立一个到设备插件的监听长连接，用来获取设备的分配情况及设备的健康状态。
»更新信息到管控节点：边缘节点代理会将这些设备及相关信息，上报到边云协同 OS 管控平台中，以便后续调度器可以根据这些信息进行调度。
2、全域调度
很多边缘应用场景都涉及到区域化多点分布的边缘基础设施的使用。比如以热门的直播应用为例，直播应用的最终用户是海量的 C 端用户，而且直播应用的体验也逐步向实时互动场景延伸，比如在线连麦、互动游戏直播等。
这就要求直播应用的提供商能够在靠近用户的多个省市的城域边缘分别部署边缘业务，满足业务互动所需的低时延要求。
单个边缘节点的资源是受限的，且边缘资源的定价也可能在不同的位置不同时段上有差异，因而边缘解决方案需要提供一套调度机制，能够在时延、性能、价格等约束下，获取最有效的资源分配策略。如何根据任务和资源的特性进行合理的全域调度。在保证服务质量的前提下，将用户从服务器的管理中解放出来，同时从全局角度优化资源的利用率，是一个非常有挑战力的课题。
全域调度的调度对象为亿级的终端和百万级的主机（边缘云和中心云），这些设备以分布式的形态存在，在保证服务质量的前提下，如何高效的打通端、边、云的界限，成为全域调度的核心关键。全域调度系统的设计会面临以下挑战：
»大规模：终端和主机规模庞大，增加管理面的控制难度和算法设计难度。
»异构性：每个设备的数据存储和处理能力，网络时延各不相同。对接口的统一性、传输协议和时钟的同步问题，都提出了巨大的挑战。
»动态性：网络质量随着时间变化而变化，同时任务的请求也有随机性，对系统和调度算法的鲁棒性提出了挑战。
全域调度主要涉及两个维度的资源调度，一类是计算资源、另一类是流量资源。资源调度器根据全局资源的状态和网络 QoS 统计信息，为每个租户推荐资源分布决策建议。流量调度器根据资源的分布情况，在流量级进行精细化调度。
全域调度方案示意图
（1）全域资源调度
用户在使用边缘计算服务时，由于无法掌握全局的动态资源信息，当前只能靠人工经验指定位置要求固定的资源容量。这样对于租户，没有办法获取到最优质的资源改进业务服务质量，同时也缺乏应对业务突发的弹性手段。全域资源调度器，可以帮助用户即时掌控全域资源状态信息，包括动态的边缘站点可用资源、临近公有云资源以及优质的 5G MEC 资源，满足用户对服务 ( 例如网络时延 ) 的要求，同时在保证整体 QoS 最优下，可以针对成本、服务质量、业务波动做针对性优化。典型的应用场景包括：
故障切换场景：边缘站点故障时，快速向周边边缘节点或公有云申请弹性计算资源，完成故障业务的快速恢复。
»业务弹性场景：区域过载场景，局部业务突发时，可以快速调度周边可用资源，实现业务弹性扩展，平滑度过业务峰值。
»资源调度的关键点是全局资源视图和资源调度算法。资源视图包括用户的位置，资源的成本，网络的 QoS,接入的地理位置等。全域调度的策略可以支持预置策略或可定义策略，典型的预置策略包括时延优先、成本优先、可靠性优先策略等。
（2）全域流量调度
在给定业务节点已完成部署分配的情况下，流量调度为用户的每一位客户流量访问请求的分配处理节点。流量调度具有与业务高度相关的特点，针对不同业务的类型，流量调度的方法各不相同。例如，CDN 业务中，流量调度要同时支持接入调度和回源调度，且调度算法的设计需要考虑到内容缓存策略的影响。云游戏业务中，流量调度只需要支持接入调度即可。
流量调度基于历史数据完成流量粗粒度的流量规划以保障基础水位均衡，并基于分钟级的流量特征学习，决策控制周期和分配策略，对流量进行全局性的优化。实时调度器负责针对每个区域租户请求的实时响应，执行、切换调度策略，并当发生故障时，及时完成故障转移。
3、全域加速
边缘节点分布比较广泛，因成本的原因边缘到中心、边缘到边缘之间无法构建专线连接。而传统 Internet 通过OSPF、BGP 等标准路由协议进行物理网络传输（Underlay方式），它通过链路 Cost 进行路由选路转发，路径拥堵发生丢包率、时延等 QoS 故障，不会流量感知切换，导致无法满足业务应用 QoS 质量诉求。
在线教育，云游戏、云桌面、云 VR 等边缘应用场景都涉及边缘到中心、边缘到边缘之间低延时高质量互联通信的需求。可以在基于传统 Internet Underlay 网络的基础上，构建多点分布的边缘云 Overlay 网络平面，同时实时测量 Overlay Link 的 QoS（时延、丢包率），选择最佳 QoS Overlay 路径流量转发。为上层业务应用屏蔽复杂的网络环境，提供低时延、低丢包率、价格合适的选路方案。
全域加速的方案包括以下几点关键能力：
»拓扑构建：根据预先定义结合自动发现机制，创建边缘节点之间 Full-Mesh 邻居关系，通过探测报文实时测量两两邻居之间时延 / 丢包率。进一步，对于时变路由可预测未来一段时间（如 5~10 分钟）隧道 QoS质量。
»路径优化：基于 AI 训练预测未来时刻流量 QOS 进行路径选路，结合策略定义的约束，推荐最优化路径建议；
»Overlay 转发：基于最优隧道路径，向源设备压入转发包路径列表，中间节点根据包路径层层逐跳快速转发；转发过程中实现丢包重传和 FEC 自适应纠错转发优化。
»故障切换：实时探测边缘节点和网络路径的状态，并实时计算各路径 QoS。边缘节点故障或者隧道断开故障，可以实时上报更改转发路径。隧道拥塞 QOS 质差，则需要通过定期（如 5~10 分钟）全量路径计算切换。
全域加速方案示意图
【来源：边缘计算产业联盟 、工业互联网产业联盟 《边缘计算与云计算协同
白皮书2.0》】