编者按：面对海量数据新的应用形态对低时延和分布式架构的需求，边缘计算将成为新一代边缘计算云基础设施，火山引擎覆盖了全国海量边缘节点，储备了上百T带宽，承载了视频直播、游戏娱乐、智慧交通、影视特效等多场景客户服务， LiveVideoStackCon 2023上海站邀请到火山引擎边缘云边缘计算架构师——郭少巍，为大家分享《拥抱云原生——下一代边缘计算云基础设施》。

文/郭少巍

编辑/LiveVideoStack

大家好，我是郭少巍，目前在火山引擎担任边缘计算架构师，个人擅长的领域是云原生和IaaS相关技术研发，近年来一直从事边缘计算相关的架构设计和研发工作。

本次分享的主题是《拥抱云原生——下一代边缘计算云基础设施》。

演讲主要包括以下五方面：一、业务走向边缘；二、业务发展为边缘计算云基础设施带来的新挑战；三、应对挑战，边缘计算云基础设施逐步完善；四、火山引擎如何构建内外统一、边缘原生的云基础设施架构；五、未来展望。

-01-

业务走向边缘

云计算经过十几年的发展，对大家来说并不陌生。在使用云计算的过程中，我们享受到了云计算带来的诸多好处，例如云计算的弹性、可靠性。这十几年众多云厂商纷纷涌现，出现了基础设施即服务、平台即服务、软件即服务，云计算的形态上演变出了公有云、私有云和混合云等多种模式，当前“云”已经触达了企业应用的方方面面。

据Gartner预计，至2027年，将会有超过90%的企业会将“云”作为首选的基础设施。在如此大规模的应用之下，云计算下一阶段的发展方向又在何处？下面让我们带着这个问题一起来看下云计算演变的驱动力。

云计算演变有三个关键的驱动力：

①应用驱动：越来越多本地化应用的出现，包括云游戏、AR/VR、工业制造、网络直播、智慧园区、自动驾驶、辅助驾驶等，这些本地商业驱动多样化的应用部署在更靠近用户的地方。

②基础设施的演变：应用驱动基础设施的完善，基础设施正在从中心逐步向边缘演进，形成三种新型边缘基础设施形态：现场边缘、近场边缘和云边缘，它们分别提供不同的延时保证和计算能力，现场边缘的延时是1-5ms，近场边缘是5-20ms，云边缘是20-40ms。

③算力和网络的结合：有了应用和基础设施的驱动，用户更希望在边缘基础设施上拥有与云上一致的体验，于是我们将云上的功能放在边缘基础设施上。通过将算力和网络进行融合，为企业提供更好的云上服务。

接下来，我们来一起看业务架构的演进：

我们把资源分为三类：

①终端资源：为用户提供实时的服务响应，可能就是用户使用的手机、平板、车机系统。虽然终端资源最靠近用户，但是它的算力有限，于是便有了边缘资源。

②边缘资源：为用户提供就近的接入服务、广域的业务覆盖及精准的网络感知能力。虽然边缘能够为终端提供更强的算力，但它分布在全国各地，而单个边缘节点的规模有限，为了达成更强的弹性能力及算力，需要结合中心资源。

③中心资源：中心资源可以为用户提供更加弹性的系统容量，并且提供更加强大的数据聚合能力。

传统的中心式部署架构已无法满足新型资源下的部署模式，业务架构采取云边端配合的模式进行部署，才能够充分地发挥云边端的优势，未来会有越来越多的业务向着云边端混合部署的新架构方向发展。

边缘计算发展的历程可以追溯到1998年，Akamai首次提出CDN的概念，基于互联网的内容缓存网络CDN，就近缓存内容，降低网络拥塞，提高访问效率和命中率。CDN成为了APP、网站、客户端背后的基础服务。

2002年，微软、IBM与Akamai等公司进行合作，在CDN PoP节点部署.Net和J2EE服务，边缘计算的概念首次出现。

2009年，CMU提出Cloudlet的概念，将VM与边缘基础设施结合，出现了一个部署在网络边缘、且资源丰富的可信主机，这便是边缘 IaaS服务的雏形。

2012年在万物互联背景下，移动边缘计算MEC、雾计算等技术被提出，用于解决万物互联带来的海量数据增长问题。随后云计算和边缘结合，出现了边缘计算概念，在数据源和云中心路径之间提供轻量、弹性、智能、异构、低时延的边缘计算服务能力。

对此，我有两个观点：首先，边缘计算是对云计算最有力的补充，两者互相补充而非简单的替代概念；其次，云边协同放大了云计算和边缘计算的价值，只有更好地协同云和边，才能发挥两者最大的价值。

-02-

业务发展，为边缘计算云基础设施带来新的挑战

边缘计算的发展带来好处的同时，也在云基础设施架构方面带来许多挑战。

边缘计算的优势如下：

低延迟：边缘计算节点分布在全国各地，并且覆盖全链路运营商，为用户提供低延迟体验。

高带宽：边缘计算就近处理和传输，能够承载更大的带宽。

节约成本：边缘计算可以减少客户端与中心节点通信的数据量，从而帮助客户节约了较多的带宽成本。

数据安全：数据在边缘节点进行预处理和预聚合，无需在整个网络传输，从而降低数据在公网传输被窃取的风险。

边缘计算主要带来以下四点挑战：

资源限制：边缘计算节点规模通常较小，机器数量通常为几台到几十台的规模，甚至有些边缘节点只有一台服务器，因此必须考虑如何在小规模节点下管理资源，在有限的资源下尽可能提高资源售卖率。

分布式管理：边缘计算节点的数百个集群分布在全国各地，存在弱网管理及边缘自治问题。

需求多样：由于客户的业务是多种多样的，客户在边缘节点的需求也比较多，客户需要在边缘提供云主机/容器/裸金属等各种资源类型。此外，在网络层面客户希望我们提供VPC、PIP、EIP等能力，在存储层面客户希望我们提供云盘、本地盘、文件存储、对象存储等能力。

安全管理：需要在很小的节点之内实现租户隔离，并保证公网和边缘节点协同的公网传输的安全性。

-03-

应对挑战：边缘计算云基础设施逐步完善

为了应对以上挑战，边缘计算云基础设施正在逐步完善。

正如上文提到，边缘计算面临着小型化、分布式和安全隔离等挑战。

对此，我们首先想到的是云原生技术，它具有以下特点：

资源管理方面，云原生技术支持弹性伸缩和资源按需分配，为在边缘小型节点构建一个弹性伸缩的边缘节点提供可能性。

技术架构方面，云原生技术具有松耦合、可插拔和良好的扩展性。为边缘节点异构及按需部署提供可能性。

应用部署方面，云原生技术提供了标准部署、自动化运维和可观测性。为在边缘构建简单化运维及可自动恢复的能力提供可能性。

云原生是面向云应用设计的一种思想理念，有助于构建弹性可靠、松耦合、易管理、可观测的系统。

边缘计算的架构演进与业务架构演进相契合，经历了三个阶段：

面向资源阶段：业务初期基本都是直接运行在虚拟机或物理机上的，这时的业务直接面向资源，并没有解决应用如何编排、如何快速部署、如何运维，如何观测等面向应用云上使用的能力。

面向应用：随着容器技术的兴起，2014年出现kubernetes，2018年出现Cloud Native的概念，与此同时，边缘也演进到了以云原生为主流架构的时期。

然而，云原生并没有解决所有边缘的问题，边缘场景其自身特点：

在资源层面，边缘有着广泛的节点覆盖，单个节点资源十分有限，这对海量节点管控和单节点资源优化提出了非常高的要求。

在网络层面，存在云边弱网环境的问题，这对边缘自治提出了要求。

由此，迎来了边缘云技术架构的第三个阶段，将云原生与边缘特性结合，形成边缘独有的技术方案，即边缘原生。

接下来，我将分阶段为大家介绍边缘计算架构演进。

第一个阶段是传统虚拟化阶段，此阶段将虚拟化技术和边缘结合，提供将大粒度资源拆分成小粒度资源，以及资源间的隔离能力，其主要着力点是面向资源。客户需要自行解决部署，运维，监控等一系列问题，这种管控模式对客户基础运维能力要求极高，要求客户有非常专业的运维和管控系统。

随着容器技术和云原生技术的成熟，云原生应用越来越多，此时出现了在虚拟机中部署容器，容器和虚拟机相互嵌套。这一方案中，虚拟化仍然是主要技术，容器是辅助，是传统超融合应对云原生趋势的“过渡”方案。此阶段虽然解决了部分编排能力，但容器的弹性能力受限于虚拟机的弹性能力。

基于边缘计算的特色，最终演变出了云原生超融合的架构。在同一套资源池上既实现了虚拟机也实现了容器和裸金属的管控和部署，具有以下两点优势：

第一，资源共池。三种资源形态共享一个资源池，可以灵活调配不同的资源池，提升整体的资源售卖率。

第二，满足更多业务形态，通过不同容器为云原生应用提供服务。用虚拟机为有基础运维能力的客户提供服务，用虚拟机解决Windows生态问题，在边缘的大流量场景下，用裸金属为用户提供更高性能的资源。

边缘原生结合了边缘和云原生技术的特点和优势，因此它具有云原生的应用和服务的可移植性，可观测性，易管理、统一编排的能力，同时也具有云边协同、边边协同、中心管控和边缘自治能力。在全局调度方面，具有全局资源调度和局部资源优化能力，在边缘节点具有异构能力。结合云原生和边缘的特性，使得应用和服务能够充分发挥边缘的能力。

-04-

内外统一、边缘原生的云基础设施架构

接着我为大家介绍火山引擎如何构建边缘原生的云基础设施。

图示为整体的技术方案，从底层开始介绍：

火山引擎边缘计算节点分布在全国各省市、各个运营商、具有优质的网络线路。同时，结合丰富的边缘硬件设备，如定制X86服务器、ARM服务器、GPU异构服务器资源、高性能NVMe存储、100G带宽的智能网卡设备。

基于这些高质量的基础设施，我们设计出了边缘云原生操作系统的能力，包含边缘自治管理、系统组件管理、以及面向边缘的镜像服务能力。自治管理包含集群管理、应用生命周期管理。系统组件包含网络组件、服务发现、消息队列。镜像组件包含公共镜像、自定义镜像、镜像预热及镜像加速。

云边管理提供云边通道、集群管理、智能调度等子系统，优化了云边协同。

数据管理提供数据采集、监控告警、数据大屏及数据仓库。将边缘数据进行预处理后发送到中心进行分析告警。

最终在产品形态层面为客户提供边缘计算服务，包含边缘虚拟机、裸金属、容器等多种形态，同时提供云上一致的边缘网络、边缘存储等多种云服务能力。此外，我们还构建了FaaS和SaaS等边缘服务。

场景应用层面能够支撑CDN、视频直播、实时音视频、云游戏、动态加速、边缘智能等各个业务场景的需求。

架构设计的整体理念为云边协同，边缘自治，分层治理。

边缘原生操作系统融合了云原生和边缘特点，提供以下四点关键能力：

①统一编排：通过云原生操作系统，可以实现对算力资源、存储资源、网络资源、以及自身云服务资源的统一编排。

②协同管控：支持中心和边缘协同管控，实现中心与边缘的高效融合。

③按需部署：通过算力混合部署和服务混合部署及组件可插拔，能够在不同资源场景下的提供异构算力和异构产品能力。

④云边协同：实现了云边通道、边边协同等能力。

边缘节点对资源编排的需求可以归纳为小型化和多样化：

小型化：通常节点规模较小，只有数台机器，甚至有的节点只有1台机器。

计算需求：由于业务的诉求多样，需要在边缘节点同时支持虚拟机、容器和裸金属等多种产品形态。

存储层面：需要块存储，文件存储和对象存储等能力。

网络方面：需要自定义VPC网络、负载均衡、弹性公网IP等能力。

对此，我们采用的方案是统一资源编排。

最底层是Kubernetes，在此之上通过CRD统一抽象，比如需要虚拟机，定一个Virtual Machine的CRD，通过CRD实现控制器逻辑，从而实现对资源的管控。生态方面，可以直接复用在Kubernetes之上现有的网络、存储、GPU等资源类型，实现容器和虚拟机存储和网络资源的统一。

统一服务编排的需求是组件统一管理。包括两点诉求：

轻量化：边缘集群通常较小，因此管控服务需要实现轻量化。

服务运行依赖：由于服务种类繁多，因此底层依赖的组件库也多种多样，部分服务对OS也有特定场景诉求。

对此的方案是统一服务编排，将所有的组件进行微服务化设计，将组件统一容器化打包和发布，使得组件运行时不依赖特定宿主机的OS和组件库版本。

右图最底层是引擎层，通过复用Kubernetes的基础管理能力，直接接入Kubernetes提供的网络、存储等基本能力。在引擎层之上自研了日志、监控、报警等能力，使用并强化了云原生的扩缩容、健康探测、故障迁移及自动恢复能力。在此之上，对外统一提供虚拟机、容器实例、裸金属等外部能力。

协同管控的需求是统一管控和调度，包括云边联动管控和统一资源调度。方案是自研的云边协同管控系统，包括三个关键点：

全局感知：在中心基于Watch机制，实现了对边缘资源的实时感知，更快感知到资源和库存变化。

边缘自治：利用多Master机制保障边缘的可用性，即使与中心失联，边缘仍可以独立工作。

统一调度：实现了虚拟机、容器统一库存管理。

右图是创建虚机调度的过程，首先用户发起创建虚机实例请求，虚机管控收到后再向库存服务发起请求，调度系统经过全局最优的调度策略，返回结果，管控系统将资源下发至对应的边缘节点，通过边缘管控及边缘调度器执行轻量化调度，最终将实例运行到具体节点之上。

按需部署的需求是能力多样性，主要包括以下几点：

规模异构：有的节点会比较小，有的节点规模会比较大

资源异构：不同节点提供的服务器类型包括X86、ARM、GPU

存储资源：不同节点提供的存储能力包括云盘、本地盘、文件存储等

产品能力：不同节点会提供X86虚拟机或ARM虚拟机

对此的方案是组件标准化和按需部署。

首先是标准化节点规格，我们对节点类型及组件进行标准化，前者分为小规格节点、通用型节点、大规格节点等，后者分为虚拟机、容器、网络等。

同时在部署方案针对不同节点类型和产品需求做了固定编排，在节点建设时，根据节点类型和产品需求，选择不同的部署方案。右图可以看到，在小规格节点为用户提供标准的虚拟机、容器和LB能力，在通用节点还额外提供裸金属能力，只需在通用节点基础上部署裸金属插件即可。在大规格节点之上为用户提供更多能力如GPU和文件存储产品能力，同样只需在大规格节点基础上部署对应插件即可。

云边协同解决了云边弱网问题，包括网络和安全层面。前者包括网络丢包、链路不稳定、网络链路中断等问题。后者主要是公网链路传输安全问题。

相应方案是自研的云边通道。

首先，通过边缘与中心建立长链接的方式，复用边缘与中心的链路，在中心实现了各个边缘节点的数据缓存，保障中心更快地感知到边缘变化，中心组件在操作边缘时能够对读请求加速。

其次，在安全性保障方面，通过身份认证、双向证书等机制保证客户端和服务端双向认证的安全性。在传输安全方面，通过全链路SSL加解密，保障传输数据的安全性。在SSL、ACL访问控制方面，保证只有白名单的边缘节点才可以注册到中心，增强了云边通信的安全性。

最后在网络容灾方面，采用多机房、多副本、负载均衡和故障自动迁移等技术，确保云边通道的高可用性。

以下是边缘节点的几个最佳技术实践。

第一个是实例创建加速，其问题是边缘节点创建实例慢，包括两方面原因：一是镜像下载慢，由于边缘节点从中心下载镜像较慢，由于镜像下载需要走公网进行传输，因此镜像下载的时间是不可控的。二是实例创建需要从基础镜像完整拷贝一份，如果镜像较大，拷贝也会较耗时

对此采用的方案是预热及快照。

首先，将虚拟机镜像和用户自定义镜像提前预热到边缘节点。再对边缘的镜像预创建快照，当需要创建虚拟机时直接基于快照进行创建，虚拟机底层共享同一快照层，快照采用Copy On Write 机制，虚拟机创建时并不会完全拷贝镜像数据，而是当真正要写入数据时才对需要变动的数据进行拷贝，通过快照机制，可以做到虚拟机的秒级创建。

我们在性能优化层面进行了虚拟化性能优化。顾名思义，虚拟机是由软件虚拟而来，因此虚拟机在一定程度上存在性能损耗，体现在以下三点：

•第一，vCPU在操作系统上是被当做普通用户态进程进行调度的，因此vCPU之间可能会存在性能争抢。

•第二，由于虚拟机是大颗粒内存拆分为小颗粒内存，存在内存转化性能开销。

•第三，VMM Exit可能影响CPU性能。

为了更加深入地了解以上问题，现为大家介绍一下虚拟机的基本原理：

CPU的运行级别分为Ring0~3这4个运行状态等级，Linux只使用了其中的Ring0和Ring3，分别表示内核态和用户态。

虚拟机主要由VMM(Hypervisor)和Guest组成，X86服务器为了支持虚拟化提供了两种运行模式，root模式和non-root模式。CPU的虚拟机运行过程实际上就是CPU受控制地在root和non-root两个操作模式之间进行切换。

VMM与Guest的操作模式切换主要分为两个部分。假设当前运行的代码在VMM层，如果想要运行客户的代码，就需要进入到Guest层，可以手动调用VMLAUNCH或VMRESUME指令将当前运行的代码切换到客户侧，这个过程我们叫做 VM Entry。假设在客户侧运行过程中需要响应外部中断或缺页异常（page fault），此时 CPU 运行会切换到 VMM，我们将这个过程叫做 VM Exit。

为了减少虚拟机的性能损耗，我们做了以下几件事：

•vCPU绑定：通过将vCPU和物理机CPU一对一绑定，减少了CPU的频繁切换，从而减低了CPU的上下文切换损耗；

•Hugepage：通过利用内存大页，减少内存页表，降低了TLB的miss，提升虚机的访存性能；

•Exit优化：通过将Timer/IPI等Exit透传，消除了大部分的VM Exit，使虚拟化损耗降至5%以下。