以泛在算力挖掘泛在价值 —— 网心科技音视频边缘计算实践

编者按： 内容视频化已是当下行业公认的趋势。飞速增长的音视频数据量对计算带来了巨大挑战，而当下云、端算力的局限性，也制约了音视频数据的价值挖掘。本次分享将围绕上述问题，介绍依托 5G 等基础建设兴起的边缘计算如何为音视频应用松绑，以及网心科技在这一方向上的实践历程。

文 / 曾伟纪

整理 / LiveVideoStack

大家下午好，非常高兴能够再次来到 LiveVideoStack 和大家进行一个交流。我们借助云端的算力可以让终端得到一个炫酷的体验，这是我认为过去十多年以来技术发展非常重要的一点，今天我的分享也和这个问题有关。

首先做个简单的自我介绍，我早年在成立不久的腾讯云做过云端后台的服务，后来在 2015-2016 年左右，我才开始做现在的这些事情，再后来我才知道，这叫边缘计算，从那时候开始，我和音视频结下了不解之缘，一直持续到今天。所以今天，我想给大家分享 “以泛在算力挖掘泛在价值”。

1、流失的泛在价值

首先，我们来看价值流失的问题。内容视频化是一个大趋势，人是视觉动物，我们对视频的接受程度和我们对视频的喜爱程度是毫无疑问的。无处不在的视频也就代表了无处不在的价值，这也是我们题目中所说的泛在价值。这个潜力有多大呢？我们来看一个数据。

来自 IDC 的统计数据显示，到 2025 年创建的数据会达到 175ZB，这相当于 2022 年的两倍，而当中以视频为主的非结构化数据占到 80%，视频蕴含的价值将是巨大的，这也是我们今天所提到的泛在价值。这些价值又是怎么挖掘出来的？我们可以看一下数据的生命周期。

从上图显示，我们数据的创建正在更多的趋向于边缘，同样的数据的存储也会向中心和边缘转变，而终端的占比会下降。但是我们整个数据的处理一直是偏中心，我们的消费又一直在端侧，这样就出现了算力的错位。

我们知道视频处理的数据量是非常大的，算力的需求也非常高，那么这样的一个错位就会导致在实际应用中，数据追着算力跑，这就会产生大量的算力搬运成本。除了成本之外，其中产生的延时也限制了更多的实时的场景体验；既然终端算力是有限的，为什么没法放到云端呢？就是因为延迟。我们可以看到这么一组数据，所有生产的数据中，有 44% 根本没有被采集，而被采集的数据中也只有 57% 的数据得到利用，也就是总共也只有四分之一多一点的数据最后能被挖掘，这显然是一个巨大的价值流失。那么这个问题的原因是什么？

目前，云计算是现在计算的一个主流，那这个锅是云计算的吗？云计算实际上是开创了云端算力的模式，把云端算力投射到终端上，这是一个技术上的巨大飞跃。它的问题在于现在的云计算更多基于中心的超大规模的 IDC，所以这种中心化的布局现在遇到了瓶颈，需要进一步的发展，所以就产生了下沉的需求。比如 CDN 技术，就是将传输下沉到离端更近的地方，改善传输质量。现在我们做的多数据中心接入架构，其实也是在做计算方面的下沉，但是就仅仅到这一步吗？为什么我们不能再进一步？是因为没有算力吗？

根据 2022 年的 AWS Invent 大会上发布的数据，每一百台出货的服务器中，只有四台是流向云计算厂商。另外，我们终端处理器的性能在这些年飙升的非常快，而且，我们终端的出货量也维持了很高的水平，在不断上涨。所以 IDC 以外的算力应该是普遍存在的，量也非常充足，因此这个端和边的设备也是不背锅的。

那么还有什么原因？会是网络连接吗？我们知道运营商的网络非常复杂，而其实我们互联网做的事情非常简单，就是把所有电脑都连起来。在把所有电脑都连起来的方法中，做 Mesh 显然最直接，也就是每两台电脑之间都拉根线，但是，为了不被网线淹死，我们的网络更多会做成树状的结构，底层做一个树状的收敛。

再具体到每个省会对应到它附近的一个核心节点，全国的核心节点也就这几个，在核心节点以下，其实都是层层的树状汇聚的，在核心节点之间，鉴于核心节点也不多，所以我们为了效率，就可以把它做成 Mesh 的结构。基于这个结构，我们就知道网络里任意两点之间大概率不是直联，基本上只有核心点之间有 Mesh 的才是直联。所以，实际上在城域网，同城的两个节点互联，只要上升到城域网，再下降回去就可以了，这个延迟大概是在 7 毫秒以内。而如果是同省的话，就要上升到省级核心交换机，大概是 10 毫秒的延迟水平。跨省了以后，就不确定了，因为需要去经过这些省，两个省之间，如果挂在同一个核心节点下，那还稍微好一点，只要上升到省核心节点，再下沉就行了。

鉴于运营商的省公司是独立运作的，互相之间的互联经常有不确定性。如果两个省挂接在不同的全国核心下方，路径显然会更长，跨区实际上是长途跋涉。我们做 CDN 就是应对这种网络情况，在一个复杂的网络拓扑中寻找一条相对靠谱、质量好一点的路去把数据传输过去。我们一般是认为资源下沉到同省是一个从成本和质量上比较平衡的做法，因为同省内的互联是比较有保障的，那么跨中心就已经不太靠谱。如果进一步，我们想要跨运营商呢？

这是国内运营商互联的情况，比如电信和联通两个点想要互联，只有这几条路可以走，首先路肯定是变长了；其次，由于三大运营商之间的关系，互联基本上质量难以保证，成功率基本看天。我们去做传输，走到跨运营商的步骤，基本上属于死马当活马医，除非我们去采购一些比较昂贵的互联资源，比如三线机房，BGP 机房，这样去找一条稳妥的路去做互联，当然成功率就非常的高。讲到这，我们就破案了。

其实我们算力接入门槛主要的问题是跨运营商乃至跨省的连接质量都难以保障，因此我们去做云计算基础设施的构建时，显然我们的首选是把算力接入核心节点和互联节点，围绕着这几点转，它想下沉就很困难，需要克服很多网络连接的问题。另一方面，如果想要把资源下沉，算力就很分散，分散的算力对业务开发也提出了更高要求。为了解决算力分割问题，边缘计算就闪亮登场了。

2、边缘计算与泛在算力

我们前面提到过，算力分布是不太合理的，这导致了很多价值的流失。那么现在为什么边缘计算能够兴起？

边缘计算兴起的先决条件是网络。我们网络资源其实是在不断下沉的，在固网这块相对还是比较容易，然后现在的问题是我们比重越来越大的移动网络。移动网络在过去 3G、4G 时代，我们手机上发出一个数据包进入互联网，需要上传到省网才能接入，与公网还不一样，固网加宽是可以接入手机网的，这个情况在 5G 时代才有所改变。5G 有了 UPF 和 MEC 技术，使得手机发出的数据包可以在城域网就接入互联网，这就使得更短路径连接成为可能。此外，5G 的空口改进，把带宽的延迟水平大大地拉进到了和固网接近的水平，因此，我们在一个更靠近边缘的地方去部署算力，去接入算力得到了一些必备的条件。

接下来就是边缘的算力条件，这个我们之前讲到过，边缘不缺算力。

再下一步就是我们的应用开发能力。你底层有了这些资源，那你怎么去用它呢？近年来，分布式技术的发展使管理大量边缘节点成为可能。然后就像我们刚才提及的边缘的复杂网络条件随着传输技术的发展，比如新的传输协议等等，使得边缘的复杂网络不再会是一个很难跨越的障碍。最后就是云原生等技术使分布式应用开发难度降低，我们可以用起来大量异构且分散的资源，所以就有了边缘计算。

这是很多权威机构对于边缘计算的定义，其实就是把算力下沉，但它带来的效果确实是实打实的。我们可以把算力部署到更多的位置，它可以覆盖本身所处位置上的数据，同时它也可以以更低的延迟去覆盖其他位置的数据。

那么再具体一点，根据 Linux 基金会对边缘计算的概括，边缘计算类似于基于 5G、AI 一些硬件能力，以及云原生一些开发能力，边缘计算可以运用到什么场景？互联网沉浸式体验，边缘自治是典型的 Use case。

概括一下，云计算突破了终端对算力的限制，边缘计算则填补了端与中心之间的算力真空，实现了算力泛在化，使得我们可以更好地去挖掘泛在价值。

3、网心科技边缘计算实践

在边缘计算实践上，网心 2014 年底就开始从迅雷业务改造入手，然后，我们的业务从直播切入，去做一些 TO B 的服务，从长视频到中视频再到短视频的视频点播，难度也是越来越大。除了音视频，我们也在开始去拓展更多的边缘计算场景。大家知道，边缘计算的概念在 2016 年左右成型，在这两年成为了风口，而网心实际上已经在这个方向做了快八年，中间也经历了云计算的大发展，整个行业加剧了竞争，同时也经历了技术变革。

接下来，看一下我们积累下来的整体服务架构。我们在上层提供的产品服务，包括像云计算里的 CDN，以及函数计算、安全、存储等服务。其实接入和在传统云里的服务并没有太大的区别，感知是很小的，但是它在特定的场景下，会比传统的云服务效率更高。这些效率来自于底层，我们底层去覆盖云边端一系列的计算资源，云端自然不用说，在边缘侧我们会有更下沉的数据中心，我们还有来自运营商的一些边缘机房，以及一些企业现场的机房，这都会被纳入到计算网络里。

在端侧我们有一些自研的边缘硬件资源，同时，我们也可以把很多生态的硬件纳入到基层网络中来，比如说家里很常见的 NAS，路由器，甚至于电视机，机顶盒还有个人 PC，我们有非常多这样的生态节点。那么如何去把这些能力、形态、位置各异的底层资源包装成一个通用的云服务，让上层接入没有太多感知？这其实就是靠中间边缘计算平台的这一层。

回顾网心边缘计算落地的路线，是从边缘 CDN 切入，基于边缘 CDN 再去把底层的 IaaS 层开放出来，初期是面向边缘传输的 IaaS。接下来，我们会在此之上构建一个边缘容器平台，能够去做更多更广泛的计算场景，不再仅仅是传输，最后是边缘云原生，能够让上层的业务应用更方便地接入到边缘计算的网络层。

首先，我们来看一下。第一步，我们做的边缘 CDN 的事情。前面其实也提及过，CDN 做的事情实际上就是下沉，用户的内容更多是在中心的云机房，CDN 就是会把它进一步下沉，比如说下沉到省网的级别，来获得一个更好的传输体验。边缘 CDN 原理是一样的，只是我会把内容去做更加进一步的下沉，下沉到城域网，甚至于下沉到接入网的边缘设备上去。别看只是多了一两层，但其实它的复杂度是成倍上升的。

我们来看一下，做这个事情需要突破的关键技术点。第一个是智能调度 / 部署，调度和部署关系非常大，部署是如何把要分发的资源去分布到这些设备上去，如果请求的时候，你能够命中一台附近的设备，显然你的传输效果是比较理想的，这样就不需要去做一个回源，去回到中心机房，产生很高昂的成本以及很高的延迟。既然我们把这个内容进一步下沉到城域网，甚至接入网，我们网络的深度、复杂度自然是一个指数级的提升。所以，在这块，我们就需要更加细粒度的调度和部署的策略。

此外，就是全联通网络。边缘的网络是非常复杂的，不仅是刚才所说的延迟等问题，还存在大量的内网穿透、防火墙穿透等问题，这块也是需要花非常多的精力去解决的。

接下来是，HARQ 加上多路径传输。这其实也是为了应对在 IDC 以外，无 SLA 网络，我们必须采取更激进的策略才能保证传输的稳定性。

最后，就是节点自适应和链路自适应。我们在 IDC 里做应用的时候，我们的设备往往都相对比较标准，它有多少能力，它的算力有多少，以及它的带宽有多少，这些都是事先能够确定的。但是在边缘网络里，这些设备是多种多样的，甚至有很多设备是无法预先得知的，我能给你多少算力，我能具备多少带宽，这些东西都需要我们自己有一套探测和自适应的机制去保证既能够把设备能力充分利用，又避免把它用的太狠了，出现质量问题。

在解决了这些问题之后，我们才构建起来一个可用的边缘 CDN 网络，在我们的服务场景下，质量可以和传统 CDN 不相上下，这在我们客户的 QoE 数据中也得到了验证。但是只做一个 CDN 可能是不够的，它更多的意义是什么呢？

我们知道，CDN 已经很卷了。如果我们只是千辛万苦做出来一个边缘 CDN，我们把质量稍微提高一点，价格稍微降低一点，这显然不是我们的星辰大海。在 2018 至 2019 年，我们的边缘 CDN 基本上成型了，下一步的着力点是平台，一个新的复杂技术体系的落地往往会是一个上面应用、下面平台的关系，也就是说往往需要先有一个可行的应用场景，然后去打开切入点，等应用场景不断发展成熟之后，沉淀出一些平台的产品来，其实我们的路线也正是这样的。边缘 CDN 作为一个比较好落地的应用积累了我们对底层平台的需求认知，我们从场景中沉淀出通用能力下沉到底层平台。回过头来，我们以不断完善的底层能力去提升上层应用的表现，同时，我们组合底层积累的不同能力就可以去创新出新的应用场景。

接下来，我们来看一下我们的边缘计算平台。这其实和云计算的 IaaS 层面非常相像。因为边缘资源的特殊性，它也有一些自己的技术特点。

前面也提及过，平台是一个联通上下两层的东西，这里面会有一个中间层。计算机科学中有一个很经典的中间层定律，计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。我觉得这还有点不太完整，如果一层不够，那就两层。

接下来，我们在这个层里面到底做了什么事。其实刚才也提到，我们做 CDN 很重要的一个目标是通过一些具体的应用去了解底层的需求，去沉淀能力，其实可以看到我们在底层的边缘计算平台上去做这样的一些事情，很多也是和刚才 CDN 做的事情比较类似，就是沉淀下来通用的一些需求。

第一点是异构资源适配抽象，我们其实接入的资源非常多，操作系统就不用说了，包括 CPU 的架构就有很多种比如 X86、ARM、MIPS、RISC-V 等各种设备。我们需要去把这些设备一个个接入进来，我们要能够有一些在上面运行的像 Agent 这样的程序，通常我们会开发相应设备的固件，或者说我们对固件比较成熟的设备去开发一些插件来把它们接入到算力网络中来，同时我们还需要去做一些虚拟化或者是容器化的事情，去抽象这些资源，使得应用开发不要太痛苦。

第二点是边缘自治。边缘自治针对的是什么问题呢？边缘的设备和中心中控的机群连接是不太稳定的，所以我们边缘需要做一些自治逻辑，好让这些设备在和中心连接不上的情况下，不要轻举妄动。

第三点是 SLA 分级保障。前面也提及过，我们的资源是多种多样的，它们的能力以及它们的质量稳定性也是千差万别的。我们为了能够去简化，我们应用上去做调度、去分配任务的逻辑，我们会把不同能力、不同质量的资源去做分级的运营，同时我们也会有一些针对不同类型资源的激励运营手段，去提升每一类资源内的自身能力和质量。

第四点是大规模异构资源管理。这其实主要是针对节点数量，之前也提及过我们目前的节点是百万级别的，这个管理起来也是颇具难度的。

第五点是调度装箱。我们希望最大化利用我们的资源，这其实和各大云厂做的虚拟机的调度装箱没有本质的区别，当然它的场景会更加复杂一些，因为我们的节点是分开在边缘里的。首先，它的能力差异就很大，调度面临的情况就非常复杂，其次，你想要去做一些应用迁移之类的事情，它也不像传统云计算技术，在 IDC 里迁移是非常方便的，在边缘就没有那么方便，甚至两个点中间可能间隔的是整个城域网或者是整个省网，这自然是需要去定制一些策略，做一些取舍。

第六点是安全，这也是一个非常大的挑战。传统云计算，在 IDC 里面能保证一个物理隔离，闲杂人等不能随随便便进入 IDC。在边缘的话，这种保障就没有那么强，物理接触的可能性会非常高。所以，这块我们也需要做更多的封装需要更加全面的一些安全措施。

我们看完中间这一层，再来看底层的资源。这些年，我们在底层资源做了非常多的探索，底层资源也有了非常多演变。最开始，我们基于自研的硬件去构建边缘计算网络。随着平台能力的不断发展，我们不断地把更多资源纳入进来，包括之前提及的一些家庭端的其他设备以及一些在端和云中间这一侧的企业机房设备等等。

经过这些年的积累，我们已经积累出了一个相对来说全覆盖的边缘计算网络，无论它的节点位置，还是节点能力都是非常丰富的。

既然我们在中间层和底层资源做了很多工作，在上层我们是希望将来我们边缘应用开发能够越来越方便。我们会向上发展去做 iPaaS 层的探索，把云原生带到边缘计算的场景里来。具体的话，是去做一些与行业标准接轨的边缘服务治理，包括更好地容器化和编排，以及通过 Sidecar 等多种方式封装跨云边端通信能力。我们希望通过边缘云原生能力去降低边缘计算应用的全生命周期成本。相关的系统已经开始支撑自有业务。将来，如果成熟的话，我们也希望能够将它开放出来，希望在不久的将来，我们能够在这方面给大家带来更多的分享。

4、未来可期

基于我们对边缘计算的探索和现在整个边缘计算行业的发展，我们认为接下来的这些场景可能会在短时间内成为现实。

第一个场景是边缘上的人工智能。边缘 AI 也是现在边缘落地很火的一个场景。前阵子，非常多的硬件厂商针对这样的 AI 场景推出了很多边缘计算盒子。从具体的场景来说，一个是边缘推断，比如我们可以将一些复杂的算法模型，比如之前提及的一些复杂的特效，如果我们可以在低延迟的边缘上去运行这样的一些特效，其实就能够把这些体验投射到终端上。

另一个是联邦学习，我们通过在边缘上去进行数据的处理，来去确保原始数据既不被中心收集，去保护用户隐私，又能够很好地去完成学习的过程。所有的像这样的一些场景，它都能很好地运用边缘计算的特点。这些场景落地所需要的工作如下：首先是解决服务治理的问题，我们怎么把这些应用，把这些算法去部署到边缘上，去管理它；其次是数据的传输，云边端之间如何很好地去传输源数据和结果数据，特别是在一些实时场景中，传输技术要求还是非常高的；最后是需要有对应的算力，而且算力的成本也是要比较合理。

第二个场景是视频处理。这是离我们非常近的，整个行业里已经有很多这样的落地应用了，比如云端转码、云端视频剪辑和实时特效。云端视频剪辑很火，各大视频平台都有云剪辑的工具。实时特效其实是视频处理和 AI 交界的东西。这块需要的能力也主要是边端需要有相应的算力，例如转码的算力、针对视频运算需要的计算能力等。其次，也是传输，实时的超低延迟的视频传输现在也是非常火的一个赛道，RTC 技术发展的也非常快。

第三个场景是实时演算，比如云渲染、现在大家都看到的云游戏和未来的元宇宙。元宇宙，我们可以把它理解成一个大号版的游戏。元宇宙里有更加复杂的场景、模型，甚至说需要大量的 AI 处理。这对运算显然提出了更高的要求，同时，只要了解过 VR 的都知道，我们需要一个比较好的 VR 体验效果，延迟需要降低到一定的水平。显然，边缘计算在这一块是不可或缺的，所以行业也普遍认为元宇宙将来的技术底座就是边缘计算。我们和做边缘 CDN 一样，我们也会结合自身的优势去深耕这样的场景，并且将这些能力进一步沉淀到底层平台，去更好地服务我们整个行业。

最后，我们来总结一下。当我们的泛在算力类似于水电是随时可获取的，那就没有一个 T 的算力解决不了的问题，如果有，那就两个 T。

我今天的分享就到这里，谢谢！