冲刺最后一公里——音视频场景下的边缘计算实践

Posted 2021-12-10 LiveVideoStack_

点击上方“LiveVideoStack”关注我们

近年来，边缘计算逐渐从未来风口变成了进行时，而内容分发这个天生与“下沉”密不可分的领域，在边缘计算实践中可谓一马当先。网心从2014年开始探索边缘传输网络的商业可行性，实现了传统CDN到边缘CDN的技术演进，也见证了边缘CDN从超前概念到行业标配的发展历程。当数据下沉到最后一公里时，在如此复杂的节点和网络环境下构建百万量级的边缘节点网络，同时服务好需求不断深化的音视频业务，是一个不小的挑战。在此次LiveVideoStackCon 2021 音视频技术大会 北京站，我们邀请到了网心科技首席架构师——曾伟纪，与大家分享一些实践历程和关键问题，以供参考。

文 | 曾伟纪

整理 | LiveVideoStack

大家好，我是曾伟纪，目前就职于网心科技，专注于边缘的音视频服务。2014年底，网心从共享计算做起，逐渐切入到边缘计算和音视频服务的赛道，这些年也见证了这两个领域的飞速发展。本次和大家分享一些网心的思考和实践。

分享大致为网心做边缘计算的原因、具体的工作及历程、对细分领域中的技术进行展开、未来的展望。

1. Why边缘计算

时下，边缘计算是非常热门的概念，其他老师的分享中对边缘计算的性能及意义做了精彩的论述。

首先从数据方面谈谈网心对边缘计算的理解。

根据IDC预测，未来几年新创建数据的复合年均增长率高达26%，大部分存储将从终端迁移到核心机房，还有部分存储向边缘转移，而在边缘本身的数据创建也在快速爬升。基于这点来看，这是边缘计算需求的来源。其次所有运营中产生的数据，大概56%被采集，剩下的44%都没有被采集，而采集的部分中只有一半多的数据被利用，产生此现象的原因主要是基于数据处理难度也就是成本方面的考量，导致大部分数据被丢弃。而边缘计算可以很好地填补这块空白，由此反映出边缘计算的意义非常重大。

这些是从研报中摘抄的要点。

第一点是未来的基础信息会大量视频化，音视频同行应该有切身体会，其他热门领域比如元宇宙、VR在这一点上也是如此，都需要建立更多的信息并聚合在一起，对应了上文提到的数据量暴涨，因为会有更多信息被记录下来。大量数据带来的问题是计算和处理更加本地化，单纯的数据搬运并不会产生价值，举个例子，当我们在吃饭时只会关心饭好不好吃而不是饭从多远的地方搬运过来，如果楼下就有好吃的饭馆，我们肯定希望能够堂食。往往搬运带来的成本会影响一定效果。其次是元宇宙这一热门的概念，Facebook都改名为Meta，元宇宙带来的海量数据及计算的增长也需要依赖于边缘计算技术的承载，可以说边缘计算是元宇宙的底座。最后是4%的数据，当前全球服务器的出货量显示每100台服务器中只有4台流向云服务领域，说明仅仅是云计算领域的渗透率都有很大提升空间，那么对于边缘计算来说提升空间会更大。

边缘计算的定义包括以下五条：

1、任何在数据源和云数据中心之间的计算和网络资源；

2、靠近最后一公里网络的服务器；

3、构筑在边缘基础设施之上的云计算平台；

4、在移动网络边缘提供IT服务环境和计算能力；

5、一种计算拓扑，信息处理、内容采集和分发均被置于距离信息更近的源头处完成。

能够总结出边缘计算其实是云计算的延伸，它将计算从云端下沉到距离数据源更近的位置。

上图是典型的从云端到数据源的路径实例，从端开始，最先到达的可能是企业内部承载网或是行业现场，再到移动端的接入，然后到互联网的边缘，最后到中心IDC。上图所示的延迟可以看到差异很明显，而且这里的延迟是相对理想情况比如有线网下的数据，如果切换为无线网，那么中间环节的延迟会更大。

通过将计算下沉到更接近数据源的位置，会带来一些好处。首先是低延时，更加及时的数据处理。其次，就近的数据处理能够减少中间的搬运环节，降低成本。

提到成本，就要提到边缘计算的潜在市场价值。（图中数据均来自研报，是2023-2024年边缘计算相关的细分行业市场规模，单位：人民币。）

可以看出前景非常广阔，但前景好还不够，更重要的是如何落地边缘计算。

个人认为，边缘计算最早落地的场景是音视频分发。

CDN天生有下沉特质，基于此特质将内容下沉到最接近用户的地方并结合缓存机制以达到对内容分发的提速和降本。在边缘计算的场景下可以将内容从地市级的IDC进一步下沉到距离用户的最后一公里内，这一块的潜在收益上文已提到，而它面临的技术难度也更高。

2. 网心与边缘计算

网心在2014年组建后首先改造了迅雷业务，可以说从最初就锚定了一个目标业务来实施落地。

大家对迅雷的直观印象是下载速度快，而做到快速下载不仅是通过用户之间的P2P，这是远远不够的，迅雷投入了很多服务器也就是自己做了很大的CDN，对线上热门资源进行主动缓存，这是会员下载和非会员下载速度相差甚远的主要原因。由于服务器成本很高，网心做边缘计算的第一单生意就是帮助迅雷降低成本。通过将迅雷会员的缓存下沉到更加经济的边缘节点，我们用了一年多的时间基本替换了所有服务器，降低的成本结果也非常可观。

有了这一能力后，网心自然想到了能不能对外售卖能力，于是我们进入了CDN行业。2015年从直播CDN开始做起，2016年从纯视频的方案开始做点播CDN，2017年和2018年挑战了更有难度的中等视频，短视频方案，2020年，网心的CDN的方案都相对成熟，于是开始探索新的边缘计算场景。

在发展的这些年中，行业外部环境也有所变化，CDN行业产生了很大的变迁，价格被斩去很多，云服务的需求端及供应侧更多向大厂集中，另外伴随着终端侧的提速降费。外界环境的变化对于网心来说是既有挑战，也有机遇，但我认为主要是机遇。

以下是网心积累的边缘计算能力：

首先是底层的边缘设备接入，最初是基于ARM的小盒子，现在的接入设备种类更多，从x86，ARM，到MIPS，还包括专有的计算加速硬件，从早期只有CPU，现在逐渐具备了边缘计算上的GPU，NPU能力。接入设备后，可以基于此做虚拟化组网的工作以实现在边缘节点的业务治理，能够在边缘上实际有效地跑相关业务。然后在边缘网络之上封装PaaS层面的服务，如边缘存储服务，开放算力提供计算服务。

目前边缘计算仍处于Gartner成熟度曲线过热的尖峰上，所以我们认为要抓住时机，静下心来寻找落地场景。

3. 边缘计算网络构建

目前网心边缘计算网络可以概括为“（带宽）很大，（节点）很多”，那么如何做到“很大很多”呢？

第一个问题是，节点的硬件架构及软件架构都不同，如何磨平差异，通过相对统一的抽象视角对其进行调度。

第二个问题是如何对节点下发指令并执行，节点本身的网络相当不稳定，有时在线有时不在线，即时在线，它的延时也极其不稳定，经常反复横跳。所以在这块要进行大量容错，柔性的处理。

第三个问题是如何整合节点网络，将零散节点包装成看起来面积很大很稳定可靠的网络，假设一个任务部署在1w个节点上运行，节点本身的上线下线容易掉，要针对性地做冗余、补点的策略。在补点过程中要保证业务分布，比如已经指定了全国的区域分布，华东需要多少点，华南需要多少点，那么需要保证分布在一定程度上的稳定。当出现局部区域网络故障时，是选择补点还是跨区调度等细分的业务问题，这都是我们遇到的问题。

第四个问题是如何在整合后的节点上开发应用，作为用户如何调度节点能力。换句话说就是需要通过虚拟化抽象简化节点上的应用开发，同时继续做封装抽象，尽可能透出一些底层的能力，如节点上不同的加速硬件。这里的工作很多很细，举个例子说我们需要标记节点，当一个程序在某个节点上跑出问题时，可以通过定位节点发现共性，或是在节点上获取日志和数据。那么如何标记节点呢，我们要赋予节点唯一的标志，但是大量节点在用户侧，对用户侧的节点进行唯一ID的标记涉及到隐私问题，在这块我们做了一些节点ID的脱敏处理。

核心要点大致如上，接下来介绍边缘计算的基础架构。

底层不同的硬件通过虚拟化抽象出“Pod”的概念，一个设备上可以运行一或多个Pod。客户侧的业务就部署在Pod中，Pod通过中心的调度编排引擎进行操控，同时提供自助控制台包括包管理、数据采集，方便用户监控应用在边缘的运行情况。客户侧的应用量部署在虚拟化Pod中，客户可以自己进行业务上层的调度。虚拟化方面提供多层级能力，我们提供了裸金属、VM到容器等多个层级，也在开发更加轻量级的虚拟化方案如WebAssembly。由于存在部分本身能力相对较差的边缘设备，所以虚拟化的开销也是需要考虑的问题。现在的函数计算场景很热门，函数的启动性能也是一项指标，而WebAssembly能够很大提升这方面的指标性能。

以上就是对组网的介绍，那么在下载、点播方面会遇到什么问题呢？

4. 下载/点播@边缘计算

实例是下载/点播的大致服务流程。

通常来说，边缘场景下的点播服务会以SDK的形式在客户端提供，最常见的接入形式是通过local的Http代理做低侵入式的接入改造。举个例子，下载一个视频时，视频的URL原先是向网络请求，现在改为向Local SDK请求，SDK在拿到URL后会做一系列策略，比如在起播阶段通过Range方式把头部或视频刚开始的数据向CDN请求以保证起播质量，由于边缘节点连接过程比较耗时，所以为了达到秒开就要进行此过程，拿到起播数据之后同时建立P2P连接，连续到边缘节点进行后续分片。切换的逻辑一方面是由SDK控制，另一方面是将其开放给客户，让客户做精确控制，客户本身的端之间的P2P做集成切换。

网心其实也有无SDK接入产品，但我们在SDK这块会进行很多精细化的策略控制，比如数据上报，感知，而无SDK就会相对欠缺，但其好处是接入门槛更低。

部署中我们也遇到了一些困难。

边缘节点最大的问题是回源质量不可控，因为它通常不像IDC会有网络SLA，它的稳定性很差。现网统计数据显示，在点播场景下一个边缘节点的命中与否（未命中要做实时回源）传输速率差3倍以上，首包耗时（拿到第一个字节的耗时）存在两个数量级的差异，显著大于IDC场景下命中与否造成的差异。基于此我们必须想办法提升边缘节点访问的命中率，而提升命中率时受到的最大限制是边缘节点存储容量有限，大概在1G到几百G不等，和IDC水平相差甚远，所以只能另辟蹊径，做到更精细化的部署。缓存的命中率很大程度上取决于数据热度，我们也是基于热度决定资源部署的相应节点。那么在这块我们部署得比较精细，基本可以计算市级覆盖范围内所有内容的热度，再选择最热的数据部署到此范围节点上。过程中的计算量很大，计算模型也很复杂，因为当内容热度拆分到市级时，样本数量很少，而基于少量样本做准确估计很有难度。此外，我们也在不断迭代计算模型，希望利用新进入用户的数据做结构分析，从而探索出更好的热度预测方法。

边缘节点不仅有限还多种多样，不同节点的网络类型差别很大，这也是基于它的异构性。同一种设备上的边缘节点可能存储能力相近，但网络带宽之间存在很大差异。所以要对不同类型的节点进行分类，建立不同的性能模型，模型本身也需要在某段时间中进行很多修正。起初我们将边缘节点分为三类，经过不同的修正，至今应该已有不低于十种类型，一方面要对节点做建模，还要针对不同模型使用不同的策略。举个例子，在长视频请求中，上文提到起播部分走了CDN，剩下的部分有十几种类型的节点，那么就要选择传输速率最高，在线率最好的节点请求剩下的数据，后面的数据关联性越弱可以相应地使用较弱的节点，这只是比较粗浅的例子，实际场景中的情况更加复杂。对应到短视频，因为没有多少空间可以腾挪，视频在1s之内就能下载完毕，这1s之内的下载速度变化对体验影响很大，没有更多时间进行切换。短视频相较于长视频的要求更高，所以我们最初选择从长视频入手。

节点不仅有不同的能力模型，甚至细粒度到单个节点的能力变化也非常剧烈，对节点的评估也并不容易。边缘节点不像IDC中的服务器带宽都是规定好的，边缘节点的能力不能被准确地预知。另外，边缘节点的能力变化非常显著，可以普遍观测到在晚高峰，基本一半以上的边缘编解码会明显出现RTT和丢包率的恶化，基于此特点就要采取自适应的控制策略，对节点的复杂调度其实类似于网络传输中的拥塞控制算法，是通过探测的方式观察节点在不同复杂水平下的表现，再根据对表现的反馈决定提升或降低调度复杂的水平，探测完成后还会对数据进行上报统计并进行能力画像，画像会精细到单个设备及时间维度，至少要将晚高峰几小时的细粒度表现记录下来。

以上的三个问题（节点的能力受限、节点能力的多样、节点能力的不确定性）的解决办法总结出来就是要精细化策略，那么随之数据也要精细化。所以我们做了细粒度（秒级粒度）数据上报，所有的边缘节点和SDK都进行非常细粒度的数据上报，这样带来的数据量就会非常大，面临的成本问题也更具挑战性。我们利用边缘节点做了一些offload，成本下降了大概一半。

5. 直播@边缘计算

直播的服务原理和点播差不多，也是起播走CDN，后续切换到边缘节点。

上文提到边缘节点的回源很差，但直播的所有内容都是实时生成的，必须回源。所以我们不得不用到一些复杂的策略对直播流做了编码和切分，切分为片后将其分配到不同的边缘节点上，SDK可以同时连接很多边缘节点，从一个节点中拿一部分片，这样即使一个边缘节点出现了问题，影响的也只是小部分数据。同时我们在编码上做了冗余，掉一或两个节点的影响并不大，依然可以通过冗余的分配恢复完整的流数据。通过这个机制可以在回源比较差的情况下保证较好的质量。

切换过程和点播一样，也可以通过SDK控制或开放给客户进行控制。

机制实现中我们也遇到了一些问题。

首先，虽然可以容忍一些掉点的情况，但持续掉点的情况下，我们还是需要尽快补点，这类似于给行驶的汽车换轮胎，对换轮胎的速度提出了很高的要求，所以连接成功率对最终质量影响显著。所以网心在2015年选择直播方向切入可以说是以Hard模式起手。

解决这个问题的方法首先还是精细化策略，尽量为SDK选择最适合的边缘节点，精细调度的方法无非就是如何更精确地识别SDK的网络位置，更精确地识别所有节点的网络位置，然后对两者进行匹配。网心的特别之处在于本身有大量的边缘节点，可以进行更多的拨测，得到更多数据，利用数据完善识别的精度。

另一个方法是节点预热，大家都知道，连上节点和连上之后节点是否有流是两回事，如果没有流就要发起回源，所以我们会做预推，而预推的本质是成本的牺牲兑换体验的提升。

再回到回源问题，实时音视频讲究的是全链路的质量。解决方法是规划更好的回源路径，这里最重要的是要理解所处的网络，网络是由运营商构建的，于是就需要更多运营商侧的信息，了解他们的网络拓扑，基于这些信息进行区域的调度及回源路径的规划策略。但很多时候我们能够获得的信息并不完全透明，实际运营商在执行中也会出现一些偏离规划的情况，这时就要依靠其他数据进行补充，就又回到了边缘网络拨测这一点，我们通过高频、高密度的拨测探测网络结构来做网络决策。但拨测是模拟的行为，并不代表真实业务跑起来的情况。上文提到的节点预热可以一定程度上提供数据支撑，因为它传输的可能是真实的视频流，基于其中的帧率等数据可以更好的衡量链路的真实质量。

6. 未来可期

未来网心会继续探索更多落地的边缘计算场景，更深度、更广度地挖掘场景。“更深度”：指对现有场景的深化，比如如何进一步提升边缘CDN的指标，做低延时直播。“更广度”：目前应用的场景还是边缘带宽，后续希望能深入挖掘算力及其他的场景如AR、VR、云游戏。

同时要完善基础设施以服务支撑上述场景，一方面增强节点能力。另一方面将更多关注融合及标准化的工作，如云边协同、边缘原生。因为之前网心完全是从自建架构出发、从特定场景出发构建系统，那么未来我们希望更向行业标准对齐。

以上是本次的分享，谢谢！

---

讲师招募

LiveVideoStackCon 2022 音视频技术大会 上海站，正在面向社会公开招募讲师，无论你所处的公司大小，title高低，老鸟还是菜鸟，只要你的内容对技术人有帮助，其他都是次要的。欢迎通过 [e-mail] 提交个人资料及议题描述，我们将会在24小时内给予反馈。

喜欢我们的内容就点个“在看”吧！