标签： 边缘计算

随着Kubernetes已经成为容器编排和调度的事实标准，各大公有云厂商都已经基于Kubernetes提供了完善的Kubernetes云上托管服务。同时也看到越来越多的企业、行业开始在生产中使用Kubernetes, 拥抱云原生。在各行各业数字化转型和上云过程中，公有云厂商也在主动拥抱传统线下环境，在思考各种各样的解决方案使云上能力向边缘(或线下)延伸。

而Kubernetes由于屏蔽了底层架构的差异性，可以帮助应用平滑地运行在不同的基础设施上的特性，云上的Kubernetes服务也在考虑拓展其服务边界，云原生和边缘计算结合的想法自然就呼之欲出了。

目前国内各个公有云厂商也都开源了各自基于Kubernetes的边缘计算云原生项目。如华为云的KubeEdge，阿里云的OpenYurt，腾讯云的SuperEdge。目前网上很少有从技术视角来介绍这几个项目优缺点的文章，本文试着从技术视角，从开源视角来分析这几个项目，希望可以给大家做项目选型时提供一些借鉴。

比较思路

这几个项目都是云边一体，云边协同的架构，走的是Kubernetes和边缘计算结合的路数，因此决定从以下几点比较:

（1） 各个项目的开源状况：比如开源项目的背景、开源的时间、是否进入了CNCF等；

（2）Kubernetes架构:

• 先对比与Kubernetees的架构差异：主要关注是否修改Kubernetes，和；Kubernetes一键式转换等
• 根据架构差异对比和Kubernetes的能力增强点；主要关注边缘自治，边缘单元化，轻量化等能力
• *后看一下架构差异可能带来的影响: 主要关注运维监控能力，云原生生态兼容性，系统稳定性等方面

（3）对边缘计算场景支持能力:

• 主要关注是否具备端设备的管理能力

接下来以项目的开源顺序，从上述几个方面来介绍各个项目。

边缘云原生开源项目对比

2.1 KubeEdge

（1）开源状况

KubeEdge是华为云于2018年11月份开源的，目前是CNCF孵化项目。其架构如下:

（2）与Kubernetes的架构差异

首先从架构图可以看到，云端(k8s master)增加了Cloud Hub组件和各类controller，而在边缘端(k8s worker)没有看到原生的kubelet和kube-proxy，而是一个对原生组件进行重写了EdgeCore组件。

从架构图看EdgeCore是基于kubelet重构的，为了保证轻量化，裁剪了原生kubelet的部分能力，同时也增加了很多适配边缘场景的能力。具体如下:

• Cloud Hub+EdgeHub模块: 抛弃了原生kubernetes 的组件间数据同步list/watch机制，改成基于websocket/quic协议从云端往边缘推送模式。
• 节点元数据缓存模块(MetaManager): 把节点维度的数据持久化在本机的SQLite数据库中，当云边网络不稳定时Edged模块将从本地数据库中获取数据用于业务的生命周期管控。
• DeviceController+设备管理模块(DeviceTwin): 把设备管理能力直接集成到EdgeCore中，为用户提供原生的设备管理能力。

上述的架构设计，对比Kubernetes的能力增强点主要有：

• 边缘自治：通过增加节点元数据缓存，可以规避云边断网状态下，边缘业务或者节点重启时，边缘组件可以利用本地缓存数据进行业务恢复，这就带来了边缘自治的好处。
• 轻量化: 削减了部分kubelet功能(如CSI，CNI等)，从而使边缘EdgeCore组件相比原生kubelet组件更加轻量。同时因为节点上增加了SQLite数据库，所以节点维度相比原生节点是否轻量待确认，欢迎熟悉的同学提供数据。

架构差异可能带来的影响：

• 云原生生态兼容性不足：

1. 跟随社区同步演进挑战大: 由于对Kubernetes系统的侵入式修改，后续跟随Kubernetes社区的演进将会遇到很大挑战。
2. 边缘节点无法运行Operator：因为云边通信机制的修改，Cloud Hub只能往边缘推送有限的几种资源(如Pod，ConfigMap等)。而Operator既需要自定义CRD资源，又需要list/watch云端获取关联资源，因此社区的Operator无法运行的KubeEdge的边缘节点上。
3. 边缘节点不适合运行需要list/watch云端的应用: 因为云边通信机制的修改，导致原来需要使用list/watch机制访问kube-apiserver的应用，都无法通过hub tunnel 通道访问kube-apiserver，导致云原生的能力在边缘侧大打折扣。

• 运维监控能力支持有限：

  因为目前云边通信链路是kube-apiserver –> controller –> Cloud Hub –>EdgeHub –>MetaManager等，而原生Kubernetes运维操作(如kubectl proxy/logs/exec/port-forward/attch等)是kube-apiserver直接请求kubelet。目前KubeEdge社区*新版本也仅支持kubectl logs/exec/metric，其他运维操作目前还不支持。

• 系统稳定性提升待确定:

1. 基于增量数据的云边推送模式：可以解决边缘watch失败时的重新全量list从而引发的kube-apiserver 压力问题，相比原生Kubernetes架构可以提升系统稳定性。
2. Infra管控数据和业务管控数据耦合：Kubernetes集群的管控数据(如Pod，ConfigMap数据)和边缘业务数据(设备管控数据)使用同一条websocket链路，如果边缘管理大量设备或者设备更新频率过高，大量的业务数据将可能影响到集群的正常管控，从而可能降低系统的稳定性。

边缘计算场景支持能力

• 设备管理能力: 这个能力直接集成在edged中，给iot用户提供了一定的原生设备管理能力。

2.2 OpenYurt

（1）开源状况

OpenYurt是阿里云于2020年5月份开源的，目前是CNCF沙箱项目。架构如下:

（2）与Kubernetes的架构差异

OpenYurt的架构设计比较简洁，采用的是无侵入式对Kubernetes进行增强。在云端(K8s Master)上增加Yurt Controller Manager, Yurt App Manager以及Tunnel Server组件。而在边缘端(K8s Worker)上增加了YurtHub和Tunnel Agent组件。从架构上看主要增加了如下能力来适配边缘场景：

• YurtHub: 代理各个边缘组件到K8s Master的通信请求，同时把请求返回的元数据持久化在节点磁盘。当云边网络不稳定时，则利用本地磁盘数据来用于边缘业务的生命周期管控。同时云端的Yurt Controller Manager会管控边缘业务Pod的驱逐策略。
• Tunnel Server/Tunnel Agent: 每个边缘节点上的Tunnel Agent将主动与云端Tunnel Server建立双向认证的加密的gRPC连接，同时云端将通过此连接访问到边缘节点及其资源。
• Yurt App Manager：引入的两个CRD资源: NodePool 和 UnitedDeployment. 前者为位于同一区域的节点提供批量管理方法。后者定义了一种新的边缘应用模型以节点池维度来管理工作负载。

上述的架构设计，对比Kubernetes的能力增强点主要有：

• 边缘单元化：通过Yurt App Manager组件，从单元化的视角，管理分散在不同地域的边缘资源，并对各地域单元内的业务提供独立的生命周期管理，升级，扩缩容，流量闭环等能力。且业务无需进行任何适配或改造。
• 边缘自治: 因为每个边缘节点增加了具备缓存能力的透明代理YurtHub，从而可以保障云边网络断开，如果节点或者业务重启时，可以利用本地缓存数据恢复业务。
• 云边协同(运维监控)：通过Tunnel Server/Tunnel Agent的配合，为位于防火墙内部的边缘节点提供安全的云边双向认证的加密通道，即使边到云网络单向连通的边缘计算场景下，用户仍可运行原生kubernetes运维命令(如kubectl proxy/logs/exec/port-forward/attach等)。同时中心式的运维监控系统(如prometheus, metrics-server等)也可以通过云边通道获取到边缘的监控数据。
• 云原生生态兼容:

1. 所有功能均是通过Addon或者controller形式来增强Kubernetes，因此保证来对Kubernetes以及云原生社区生态的100%兼容。
2. 另外值得一提的是：OpenYurt项目还提供了一个YurtCtl工具，可以用于原生Kubernetes和OpenYurt集群的一键式转换，

架构差异可能带来的影响：

• 原生Kubernetes带来的系统稳定性挑战：因为OpenYurt没有修改Kubernetes，所以这个问题也是原生Kubernetes在边缘场景下的问题。当云边长时间断网再次恢复时，边缘到云端会产生大量的全量List请求，从而对kube-apiserver造成比较大的压力。边缘节点过多时，将会给系统稳定性带来不小的挑战。
• 边缘无轻量化解决方案: 虽然OpenYurt没有修改Kubernets，但是在边缘节点上增加YurtHub和Tunnel Agent组件。目前在*小的1C1G的系统上运行成功，更小规格机器待验证。

边缘计算场景

• 无设备管理能力：OpenYurt目前没有提供设备管理的相关能力，需要用户以workload形式来运行自己的设备管理解决方案。虽然不算是架构设计的缺点，但是也算是一个边缘场景的不足点。

2.3 SuperEdge

（1）开源状况

SuperEdge是腾讯云于2020年12月底开源的，目前还是开源初期阶段。其架构如下：

（2）与Kubernetes的架构差异

SuperEdge的架构设计比较简洁，也是采用的无侵入式对Kubernetes进行增强。在云端(K8s Master)上增加Application-Grid Controller, Edge-Health Admission以及Tunnel Cloud组件。而在边缘端(K8s Worker)上增加了Lite-Apiserver和Tunnel Edge，Application-Grid Wrapper组件。从架构上看主要增加了如下能力来适配边缘场景：

• Lite-Apiserver: 代理各个边缘组件到K8s Master的通信请求，同时把请求返回的元数据持久化在节点磁盘。当云边网络不稳定时，则利用本地磁盘数据来用于边缘业务的生命周期管控。同时基于边缘Edge-Health上报信息，云端的Edge-Health Admission会管控边缘业务Pod的驱逐策略。
• Tunnel Cloud/Tunnel Edge: 每个边缘节点上的Tunnel Edge将主动与云端Tunnel Cloud建立双向认证的加密的gRPC连接，同时云端将通过此连接访问到边缘节点及其资源。
• Application-Grid Controller：引入的两个CRD资源: ServiceGrids和 DeploymentGrids. 前者为位于同一区域的业务流量提供闭环管理。后者定义了一种新的边缘应用模型以节点池为单位来管理工作负载。

与OpenYurt对比

• 从SuperEdge的架构以及功能分析下来，发现SuperEdge从架构到功能和OpenYurt基本一致。这也从侧面印证，边缘计算云原生这个领域，各大厂商都在如火如荼的投入。
• SuperEdge与Kubernetes的对比分析可以参照OpenYurt的分析，这里我们从代码角度分析SuperEdge和OpenYurt的差异：
• YurtHub和Lite-Apiserver: YurtHub采取了完善的证书管理机制和本地数据缓存设计，而Lite-Apiserver使用的是节点kubelet证书和数据简单缓存。
• Tunnel组件：OpenYurt的Tunnel组件是基于Kubernetes社区的开源项目ANP(github.com/kubernetes-s)，同时实现了完善的证书管理机制。而SuperEdge的Tunnel组件同样也是使用节点证书，同时请求转发是基于自行封装的gRPC连接。OpenYurt底层的ANP相比原生gRPC，会更好适配kube-apiserver的演进。
• 单元化管理组件: OpenYurt单元化管理支持Deployment和StatefulSet,而SuperEdge的单元化管理只支持Deployment。另外OpenYurt的NodePool和UnitedDeployment的API定义是标准云原生的设计思路，而SuperEdge的ServiceGrids和 DeploymentGrids的API定义显得随意一些。
• 边缘状态检测，这个能力OpenYurt未实现，SuperEdge的设计需要kubelet监听节点地址用于节点间互相访问，有一定安全风险。同时东西向流量也有不少消耗在健康检查上。期待这个部分后续的优化。

2.4 对比结果一览

根据上述的对比分析，结果整理如下表所示：

各个开源项目，整体比较下来的发现

KubeEdge和OpenYurt/SuperEdge的架构设计差异比较大，相比而言OpenYurt/SuperEdge的架构设计更优雅一些。而OpenYurt和SuperEdge架构设计相似，SuperEdge的开源时间晚于OpenYurt，项目成熟度稍差。

如果打算选择一个边缘计算云原生项目用于生产，我会从以下角度考虑：

• 如果需要内置设备管理能力，而对云原生生态兼容性不在意，建议选择KubeEdge
• 如果从云原生生态兼容和项目成熟度考虑，而不需要设备管理能力或者可以自建设备管理能力，建议选择OpenYurt

未来的世界将是一个万物互联的时代，随着物联网行业技术标准的完善以及关键技术上的不断突破，数据大爆炸时代将越走越近。

我们都知道，每台服务器都有自己的CPU、内存，但分配到这些服务器的应用往往不能充分地利用这些资源。再者，为了确保服务的可靠性往往还要预留冗余的服务器、存储器、网络设备等，而很多时候，这些硬件资源往往处于空置状态，并没有得到充分的利用。*后，正确预测不同应用对服务器的计算能力和存储器的存储能力的需求又是困难的。因此，2006年Google的CEO埃里克·施密特首次提出了云计算的概念，以及后来业界衍生出来雾计算、霾计算、边缘计算等等一系列的计算方式，接下来，让我们一起去辨析一下它们到底指的是什么。

云计算

云计算是一种利用互联网实现随时随地、按需、便捷地使用共享计算设施、存储设备、应用程序等资源的计算模式。

云计算系统由云平台、云存储、云终端、云安全四个基本部分组成。云平台作为提供云计算服务的基础，管理着数量巨大的CPU、存储器、交换机等大量硬件资源，以虚拟化的技术来来整合一个数据中心或多个数据中心的资源，屏蔽不同底层设备的差异性，以一种透明的方式向用户提供计算环境、开发平台、软件应用等在内的多种服务。

通常情况下，云平台从用户的角度可分为公有云、私有云、混合云等。

公有云：第三方提供商为用户提供服务的云平台，用户可通过互联网访问公有云。

私有云：为一个用户单独使用而组建的，对数据存储量、处理量、安全性要求高。

混合云：是结合了公有云和私有云的优点而组建的。

再者，通过从提供服务的层次可分为基础设施即服务（Iaas）、平台即服务（Paas）和软件即服务（Saas）。

雾计算

相比于云计算的高高在上和遥不可及，雾计算更为贴近地面，就在你我身边。我们知道，将数据从云端导入和导出实际上比人们想象的要更为复杂，由于接入设备越来越多，在传输数据、获取信息时，带宽就显得不够用了，这就为雾计算的产生提供了空间。

雾计算的概念在2011年被人提出，并非是些性能强大的服务器，而是由性能较弱、更为分散的各种功能计算机组成，渗入电器、工厂、汽车、街灯及人们生活中的各种物品。雾计算是介于云计算和个人计算之间的，是半虚拟化的服务计算架构模型，强调数量，不管单个计算节点能力多么弱都要发挥作用。

雾计算有几个明显特征：低延时、位置感知、广泛的地理分布、适应移动性的应用，支持更多的边缘节点。这些特征使得移动业务部署更加方便，满足更广泛的节点接入。

与云计算相比，雾计算所采用的架构更呈分布式，更接近网络边缘。雾计算将数据、数据处理和应用程序集中在网络边缘的设备中，而不像云计算那样将它们几乎全部保存在云中。数据的存储及处理更依赖本地设备，而非服务器。所以，云计算是新一代的集中式计算，而雾计算是新一代的分布式计算，符合互联网的“去中心化”特征。

霾计算

当然，无论是“云”还是“雾”，都不想成为“霾”，但是这个问题却事实存在着，如果得不到慎重的预防以及妥善的解决，那么“霾计算”就来了。

霾计算指的是什么呢？这里你可以理解为比较差劲的云计算或雾计算，因为这两者虽然概念先进，但也不是没有缺点。*，隐私与安全。现在的互联网世界，遭黑客攻击简直就是家常便饭的事，因此客户的隐私数据很容易泄漏。第二，网络延迟或者中断。云计算都是通过互联网远程访问的，虽然现在网速提高很快，但和局域网相比，速度还是有所延迟的，虽然在延时方面雾计算稍微好点，但如果网络中断，无论云计算或者是雾计算，服务都无法访问。第三，带宽会耗费预算，厂商按流量收费有时会超出预算、应用软件性能不够稳定，数据可能不值得放在云上，规模过大难以扩展，缺乏人力资本等都是造成霾计算的根源所在。

边缘计算

边缘计算指在靠近物或数据源头的网络边缘侧，融合网络、计算、存储、应用核心能力的开放平台，就近提供边缘智能服务，满足行业数字化在敏捷连接、实时业务、数据优化、应用智能、安全与隐私保护等方面的关键需求。到这里，您是否觉得边缘计算和雾计算有些相似呢？

一般而言，雾计算和边缘计算的区别在于，雾计算更具有层次性和平坦的架构，其中几个层次形成网络，而边缘计算依赖于不构成网络的单独节点。雾计算在节点之间具有广泛的对等互连能力，边缘计算在孤岛中运行其节点，需要通过云实现对等流量传输。

那么，边缘计算和云计算又有何区别？这两者都是处理大数据的计算运行方式。但不同的是，这一次，数据不用再传到遥远的云端，在边缘侧就能解决，更适合实时的数据分析和智能化处理，也更加高效而且安全。

如果说物联网的核心是让每个物体智能连接、运行，那么边缘计算就是通过数据分析处理，实现物与物之间传感、交互和控制。“边缘计算”作为一种将计算、网络、存储能力从云延伸到物联网网络边缘的架构，遵循“业务应用在边缘，管理在云端”的模式。

认知计算

认知计算包含了信息分析、自然语言处理和机器学习领域的大量技术创新，能够助力决策者从大量非结构化数据中揭示非凡的洞察。认知系统能够以对人类而言更加自然的方式与人类交互，专门获取海量的不同类型的数据，根据信息进行推论。

认知计算的一个目标是让计算机系统能够像人的大脑一样学习、思考，并做出正确的决策。人脑与电脑各有所长，认知计算系统可以成为一个很好的辅助性工具，配合人类进行工作，解决人脑所不擅长解决的一些问题。

传统的计算技术是定量的，并着重于精度和序列等级，而认知计算则试图解决生物系统中的不精确、不确定和部分真实的问题，以实现不同程度的感知、记忆、学习、语言、思维和问题解决等过程。

目前随着科学技术的发展以及大数据时代的到来，如何实现类似人脑的认知与判断，发现新的关联和模式，从而做出正确的决策，显得尤为重要，这给认知计算技术的发展带来了新的机遇和挑战。

就像“云”“雾”和“霾”的关系，物联网和大数据也是如影随形，相信通过业界人士的共同努力，定能找到更为先进的计算方式。在物联网时代来临时，我们定能合理、安全地让大数据技术为我们服务，因此不必太过恐慌，也不必杞人忧天。

​每天都有数百万台机器和对象首次连接到Internet上，公司也在通过边缘计算改变我们对云基础设施的看法，从而挑战传统架构。事实上，Gartner预计超过40%的企业IT组织将采用边缘计算策略，比去年增加了1%。

在当今世界，边缘计算继续引领行业讨论，由于越来越多的传感器、移动设备和强大的应用程序在网络的边缘驱动数据，所以越来越多的公司将计算资源放在网络边缘，以便靠近生成数据的设备。

随着组织开始关注边缘计算，各种错误的观念正在给他们蒙上阴影。下面是与边缘计算相关的三大误区。

误区1 – 边缘计算是资源密集型的

边缘计算需要的是典型的数据中心之外的本地资源，所需的资源可以是*小的。在边缘处的完整或甚至小型数据中心对于连接和处理网络边缘上的数据都是不必要的。

边缘计算是在网络边缘处的数据处理，在远程主数据中心或云的能力有限的情况下生成信息。通过将计算源放在收集数据的源旁边，我们可以显著地改进对网络安全漏洞等事件的响应，或利用市场和消费者行为的实时变化。

计算基础设施可以像物联网设备一样小，也可以像多个计算设备的微型数据中心那样大。想象一下，在远程办公或分支机构计算的环境中，通过边缘计算，资源可以与制造系统、医疗设备、销售点和物联网设备相邻。

误区2 – 边缘计算不需要改变

边缘计算可能需要多个网络提供商和连接点来支持边缘数据中心的全部负载。多样性和冗余至关重要，如果网络提供商出现故障或丢失，组织仍可提供相同的高质量服务。通过边缘计算，计算源可以在蜂窝基站或附近的城域网运行。

构建边缘网络意味着改变管理和运行数据中心的方式。组织的系统已不再位于有现场作业团队的大型、易于访问的建筑物中。由于硬件部署在远程站点上的模块化外壳中，需要时间才能到达，所以组织必须构建更像是蜂窝网络的东西。

由于标准的高可用性连接和电源系统，数据中心内部或附近的网络性能通常被认为是理所当然的。但在边缘，这是*对必要的。

误区3 – 边缘计算是适合所有人的

一些厂商会告诉您，他们可以为这种新型网络提供一条简单的路径，将计算和存储结合在一起，这并不奇怪。边缘数据中心不是万能的，安装可以是从单个服务器到自包含机架到20或30的任何设备。无论规模多大，它们都需要正确的设备。但是，不要将边缘数据中心视为廉价且小型的基础设施，而应将每个单独的节点视为必须经过设计和测试以支持业务需求的数据中心。

边缘计算环境足够小，无需专门的IT人员就可以操作。但是，为了以低维护的方式运营，基础设施需要易于实施和管理，并且可以根据需要轻松连接到主数据中心或云。大多数数据中心都需要现场工作人员轮班维护设备。在边缘计算中这是不可能的，因为您管理的是位于不同位置的多个小型数据中心，以及您的数据中心资产。

这种安排需要远程监控和大量自动化。可能需要冗余硬件来解决访问问题。边缘计算应用程序需要能够自我修复，或能够故障转移到附近的节点或数据中心来维护服务。到目前为止，行业还没有在这方面建立大量的实践。我们仍然处于试错模式中，但是一旦我们破解并完善了这种方法，计算环境将会变成一个完全不同的世界。

如今，人们听到很多关于云计算基础设施的大趋势是如何处理边缘计算的问题，但围绕这个概念存在一些困惑。许多人都认为它*终将取代传统的云计算架构。但肯定不是这种情况。但是，有些情况下，边缘计算架构比完全集中的云计算设计提供了优势，特别是从网络和数据存储的角度来看。以下将解释什么是边缘计算，它与传统云计算服务有何不同，以及边缘计算何时可能成为企业的正确选择。

边缘计算是云计算的一种形式，但与将计算和存储集中到单个数据中心的传统云计算架构不同，边缘计算将计算或数据处理能力推送到边缘设备进行处理。因此，只有数据处理的结果需要通过网络传输。在某些情况下，这会提供精确的结果，并消耗更少的网络带宽。

物联网是边缘计算*常见的用例。物联网是关于使用边缘传感器从地理上分散的地区收集数据的。这些传感器使用数据网络连接，通常利用WAN技术，如MPLS、蜂窝和*。在传统的物联网架构中，所有收集的传感器数据都将传输到中央存储库，并在其中进行整合处理。只有数据需要累积收集和分析时才能很好地工作。但是如果没有必要结合数据来获得理想的结果呢?如果每个物联网传感器只需处理收集到的数据，并在满足特定要求时发送结果，该怎么办?

人们开始看到边缘计算的好处。如果没有真正需要收集集中式云计算存储库中的所有数据，那么浪费昂贵的带宽来传输它是没有意义的。事实上，一个完全有效的物联网设计可能是传感器只有在需要报告重要信息时才连接到云端的设计。这种设计通过利用诸如基于蜂窝技术的技术来降低物联网的联网成本，这些技术使用成本更低的每千次付费的计费方式，而不是更昂贵的永远在线的连接方式。

边缘计算需要考虑的一点是，由于数据不是长期存储的，*终会被删除，这不利于大数据分析。请记住，边缘设备仅提供处理本地收集的数据的结果。在大多数情况下，收集的数据只能被丢弃。因此，如果企业的物联网项目要您存储所有收集的数据以进行累积分析决策，那么边缘计算并不适合。

也就是说，边缘计算非常适合采用本地化和批量处理的物联网部署。这方面的一个例子可能是统计远程零售商店的销售和库存，然后将计算结果按日计划发送回企业总部。企业可能不需要每笔交易的实时数据。相反，这些数据可以在本地处理，并在关闭时生成一个简单的报告。

这种方法还有助于显著减少许多企业使用传统云计算架构所面临的存储过剩问题。流入云存储的实时数据可能会迅速累积。通常，这些数据*终变得毫无用处。然而，组织往往担心数据一旦进入云端就会被删除，而且他们很容易浪费数千美元存储几乎肯定不会使用的数据。边缘计算可以通过仅向云计算发送有用的后处理信息来解决此问题。这样，企业只需要存储自己需要的东西即可。

随着商业数字化概念的进一步深入，边缘计算模型将成为许多物联网计划的关键组成部分。网络和存储成本都占分布式物联网项目的很大一部分，因此减少数据传输和存储需求在许多使用情况下都很有吸引力。如果做得好，边缘计算将允许以比传统云计算方法低得多的成本实现某些物联网项目。

1、背景

近年来，我国文化产业蓬勃发展，文化产业价值年均增速远高于同期 GDP 增速，尽管中 国演出市场在开放竞争中逐步规范有序，但目前仍处于起步和培育阶段，尚不够完善和成熟。尤其在演出场馆基础设施、管理运营等方面参差不齐。

一方面，国内大规模兴建剧场，但是却不重视开展剧场相关管理和服务标准的建立，造成目前中国的剧场硬件设施世界一流，管理与服务却远落后于发达国家。另一方面，随着现场演出形式的变化，兴起了许多独特的演出场地。当前，对场馆的精细化、分层运营已经成为促进现场服务升级的核心抓手。

2、痛点

演出场馆的基础设施、热门 IP 等诸多因素都可能导致演出现场出现无网或弱网问题，在这种情况下如何保障核验、摄像头监控等现场服务可用是技术首先要解决的问题。

面向 AI 与 IoT 结合为代表的未来发展方向，通过收集海量数据形成的消费者/用户画像可以使终端设备更加智能、更为“主动”地为消费者提供个性化服务。需要对现场类型众多、形态不一的智能设备形成通信互联、数据共享、能力互通的“联合体”，为用户提供智能场馆服务。如何保证海量数据处理的时效性和有效性，是面向业务发展要解决的问题。

目前，在无网和弱网的现场环境下提供现场服务是通过单机应用部署的方式，面临的问题 如下：

1. 为保障单机应用服务可用、可靠需要在本地搭建集群；
2. 同样的业务逻辑，本地和云端研发体系不统一，导致架构冗余、研发效率低、发布周期长，降低了业务的迭代效率。

   ①IDC 服务和本地服务代码级复用低；

   ②本地服务单机部署，无高可用性保障；

   ③本地服务依赖本地数据库，跟 IDC 数据库结构可能不一致。

    

   针对新型的场馆的智能服务需求，譬如 LIVEHOUSE，基于现场观演人群定向提供个性化服务，现有的计算架构在数据时效性和有效性方面不足以支撑。

   3、解决方案

   基于上述的痛点，现场的整体解决方案，从有效支持 12 个月内的业务和运营的发展，具有 6 个月内创造和技术*的可能性，及加速研发同学专业化能力的聚焦沉淀和创新孵化，降低体力劳动强度。

   1. 边缘计算

   边缘计算是网络中*靠近物或数据源头融合网络、计算、存储、应用核心能力的分布式开放平台，就近提供边缘智能服务。在更靠近终端的网络边缘上提供服务是边缘计算*大的特点。在数据处理的时效性与有效性方面成为云计算的有力补充。对于这样的设计，能满足大麦现场业务在智能核验、设备管控、业务监控等方面的关键需求。

   阿里云边缘云原生的产品化落地——ACK@Edge（云边一体的云原生标准 k8s 托管服务）， 支持海量边缘网关节点接入，深度融合 IoT 云端市场、云端 FaaS、消息、运维等服务，提供针 对边缘实例的 DevOps 能力，*大的提升边缘的应用分发及部署运维的效率。

   为了让现场更简单、业务更高效，需要将原来单机应用+ IDC 的集中式部署架构，演进到 云+边缘计算的统一架构，这就需要我们能够有一种方式来统一管理 IDC 应用服务器和现场众多的边缘节点。通过边缘 k8s 架构，统一管理云与边缘的节点，实现了应用发布和弹性扩缩容的统一。通过弹性能力节省机器成本；现场终端就近访问边缘节点，解决现场弱网/无网、现场 视频监控端到端的网络延迟等诸多问题。

   2. 云边端协同

   云计算与边缘计算是现场数字化转型的两大重要支持。云计算与边缘计算在技术定义上具 有差别，使他们所使用的场景有所差异。云计算适用非实时、长周期数据、业务决策场景，边缘计算在实时性、短周期数据、本地决策等场景方面表现更为优异。因而，娱乐现场数字化转 型需要云计算与边缘计算的支持。

   阿里云在两大边缘计算领域 CDN 和 IoT 深耕已久，边缘规模和业务复杂度的日益攀升带来了不小的效能问题。阿里云容器服务和 IoT 业务团队联合推出 Kubernetes Edge 定制版本，作为 云上 IoT 边缘托管服务底座，支持海量边缘网关节点接入，深度融合 IoT 云端市场、云端 FaaS、 消息、运维等服务。在这个过程中在这个过程中，云原生让 IoT 托管如虎添翼。在大麦现场业务中尝试使用，如图 2 所示云边端分层结构也日益显现。

   ①本地和云端应用统一容器化部署运行环境；

   ②适配不同的网络环境，终端灵活选择本地或云端服务；

   ③边缘节点优先处理过程数据计算，核心业务数据同步云端。

   

3. 4、未来随着 5G 技术的广泛应用、云计算与边缘计算在数字化转型的支持，加快了数字技术在文娱行业现场服务领域的应用。譬如无纸化、人脸识别等智能核验、智能泊车、客群识别等技术逐渐成为智慧娱乐现场新标配。在用户需求不断提升及产业服务不断完善的背景下，未来以安全可靠、优质体验和全链路服务建立的服务平台构筑大麦的行业壁垒。