點(diǎn)擊上方“LiveVideoStack”關(guān)注我們

近年來，邊緣計(jì)算逐漸從未來風(fēng)口變成了進(jìn)行時(shí)，而內(nèi)容分發(fā)這個(gè)天生與“下沉”密不可分的領(lǐng)域，在邊緣計(jì)算實(shí)踐中可謂一馬當(dāng)先。網(wǎng)心從2014年開始探索邊緣傳輸網(wǎng)絡(luò)的商業(yè)可行性，實(shí)現(xiàn)了傳統(tǒng)CDN到邊緣CDN的技術(shù)演進(jìn)，也見證了邊緣CDN從超前概念到行業(yè)標(biāo)配的發(fā)展歷程。當(dāng)數(shù)據(jù)下沉到最后一公里時(shí)，在如此復(fù)雜的節(jié)點(diǎn)和網(wǎng)絡(luò)環(huán)境下構(gòu)建百萬量級(jí)的邊緣節(jié)點(diǎn)網(wǎng)絡(luò)，同時(shí)服務(wù)好需求不斷深化的音視頻業(yè)務(wù)，是一個(gè)不小的挑戰(zhàn)。在此次LiveVideoStackCon 2021 音視頻技術(shù)大會(huì) 北京站，我們邀請(qǐng)到了網(wǎng)心科技首席架構(gòu)師——曾偉紀(jì)，與大家分享一些實(shí)踐歷程和關(guān)鍵問題，以供參考。

文 | 曾偉紀(jì)

整理 | LiveVideoStack

大家好，我是曾偉紀(jì)，目前就職于網(wǎng)心科技，專注于邊緣的音視頻服務(wù)。2014年底，網(wǎng)心從共享計(jì)算做起，逐漸切入到邊緣計(jì)算和音視頻服務(wù)的賽道，這些年也見證了這兩個(gè)領(lǐng)域的飛速發(fā)展。本次和大家分享一些網(wǎng)心的思考和實(shí)踐。

分享大致為網(wǎng)心做邊緣計(jì)算的原因、具體的工作及歷程、對(duì)細(xì)分領(lǐng)域中的技術(shù)進(jìn)行展開、未來的展望。

1. Why邊緣計(jì)算

時(shí)下，邊緣計(jì)算是非常熱門的概念，其他老師的分享中對(duì)邊緣計(jì)算的性能及意義做了精彩的論述。

首先從數(shù)據(jù)方面談?wù)劸W(wǎng)心對(duì)邊緣計(jì)算的理解。

根據(jù)IDC預(yù)測，未來幾年新創(chuàng)建數(shù)據(jù)的復(fù)合年均增長率高達(dá)26%，大部分存儲(chǔ)將從終端遷移到核心機(jī)房，還有部分存儲(chǔ)向邊緣轉(zhuǎn)移，而在邊緣本身的數(shù)據(jù)創(chuàng)建也在快速爬升。基于這點(diǎn)來看，這是邊緣計(jì)算需求的來源。其次所有運(yùn)營中產(chǎn)生的數(shù)據(jù)，大概56%被采集，剩下的44%都沒有被采集，而采集的部分中只有一半多的數(shù)據(jù)被利用，產(chǎn)生此現(xiàn)象的原因主要是基于數(shù)據(jù)處理難度也就是成本方面的考量，導(dǎo)致大部分?jǐn)?shù)據(jù)被丟棄。而邊緣計(jì)算可以很好地填補(bǔ)這塊空白，由此反映出邊緣計(jì)算的意義非常重大。

這些是從研報(bào)中摘抄的要點(diǎn)。

第一點(diǎn)是未來的基礎(chǔ)信息會(huì)大量視頻化，音視頻同行應(yīng)該有切身體會(huì)，其他熱門領(lǐng)域比如元宇宙、VR在這一點(diǎn)上也是如此，都需要建立更多的信息并聚合在一起，對(duì)應(yīng)了上文提到的數(shù)據(jù)量暴漲，因?yàn)闀?huì)有更多信息被記錄下來。大量數(shù)據(jù)帶來的問題是計(jì)算和處理更加本地化，單純的數(shù)據(jù)搬運(yùn)并不會(huì)產(chǎn)生價(jià)值，舉個(gè)例子，當(dāng)我們?cè)诔燥垥r(shí)只會(huì)關(guān)心飯好不好吃而不是飯從多遠(yuǎn)的地方搬運(yùn)過來，如果樓下就有好吃的飯館，我們肯定希望能夠堂食。往往搬運(yùn)帶來的成本會(huì)影響一定效果。其次是元宇宙這一熱門的概念，Facebook都改名為Meta，元宇宙帶來的海量數(shù)據(jù)及計(jì)算的增長也需要依賴于邊緣計(jì)算技術(shù)的承載，可以說邊緣計(jì)算是元宇宙的底座。最后是4%的數(shù)據(jù)，當(dāng)前全球服務(wù)器的出貨量顯示每100臺(tái)服務(wù)器中只有4臺(tái)流向云服務(wù)領(lǐng)域，說明僅僅是云計(jì)算領(lǐng)域的滲透率都有很大提升空間，那么對(duì)于邊緣計(jì)算來說提升空間會(huì)更大。

邊緣計(jì)算的定義包括以下五條：

1、任何在數(shù)據(jù)源和云數(shù)據(jù)中心之間的計(jì)算和網(wǎng)絡(luò)資源；

2、靠近最后一公里網(wǎng)絡(luò)的服務(wù)器；

3、構(gòu)筑在邊緣基礎(chǔ)設(shè)施之上的云計(jì)算平臺(tái)；

4、在移動(dòng)網(wǎng)絡(luò)邊緣提供IT服務(wù)環(huán)境和計(jì)算能力；

5、一種計(jì)算拓?fù)?#xff0c;信息處理、內(nèi)容采集和分發(fā)均被置于距離信息更近的源頭處完成。

能夠總結(jié)出邊緣計(jì)算其實(shí)是云計(jì)算的延伸，它將計(jì)算從云端下沉到距離數(shù)據(jù)源更近的位置。

上圖是典型的從云端到數(shù)據(jù)源的路徑實(shí)例，從端開始，最先到達(dá)的可能是企業(yè)內(nèi)部承載網(wǎng)或是行業(yè)現(xiàn)場，再到移動(dòng)端的接入，然后到互聯(lián)網(wǎng)的邊緣，最后到中心IDC。上圖所示的延遲可以看到差異很明顯，而且這里的延遲是相對(duì)理想情況比如有線網(wǎng)下的數(shù)據(jù)，如果切換為無線網(wǎng)，那么中間環(huán)節(jié)的延遲會(huì)更大。

通過將計(jì)算下沉到更接近數(shù)據(jù)源的位置，會(huì)帶來一些好處。首先是低延時(shí)，更加及時(shí)的數(shù)據(jù)處理。其次，就近的數(shù)據(jù)處理能夠減少中間的搬運(yùn)環(huán)節(jié)，降低成本。

提到成本，就要提到邊緣計(jì)算的潛在市場價(jià)值。（圖中數(shù)據(jù)均來自研報(bào)，是2023-2024年邊緣計(jì)算相關(guān)的細(xì)分行業(yè)市場規(guī)模，單位：人民幣。）

可以看出前景非常廣闊，但前景好還不夠，更重要的是如何落地邊緣計(jì)算。

個(gè)人認(rèn)為，邊緣計(jì)算最早落地的場景是音視頻分發(fā)。

CDN天生有下沉特質(zhì)，基于此特質(zhì)將內(nèi)容下沉到最接近用戶的地方并結(jié)合緩存機(jī)制以達(dá)到對(duì)內(nèi)容分發(fā)的提速和降本。在邊緣計(jì)算的場景下可以將內(nèi)容從地市級(jí)的IDC進(jìn)一步下沉到距離用戶的最后一公里內(nèi)，這一塊的潛在收益上文已提到，而它面臨的技術(shù)難度也更高。

2. 網(wǎng)心與邊緣計(jì)算

網(wǎng)心在2014年組建后首先改造了迅雷業(yè)務(wù)，可以說從最初就錨定了一個(gè)目標(biāo)業(yè)務(wù)來實(shí)施落地。

大家對(duì)迅雷的直觀印象是下載速度快，而做到快速下載不僅是通過用戶之間的P2P，這是遠(yuǎn)遠(yuǎn)不夠的，迅雷投入了很多服務(wù)器也就是自己做了很大的CDN，對(duì)線上熱門資源進(jìn)行主動(dòng)緩存，這是會(huì)員下載和非會(huì)員下載速度相差甚遠(yuǎn)的主要原因。由于服務(wù)器成本很高，網(wǎng)心做邊緣計(jì)算的第一單生意就是幫助迅雷降低成本。通過將迅雷會(huì)員的緩存下沉到更加經(jīng)濟(jì)的邊緣節(jié)點(diǎn)，我們用了一年多的時(shí)間基本替換了所有服務(wù)器，降低的成本結(jié)果也非常可觀。

有了這一能力后，網(wǎng)心自然想到了能不能對(duì)外售賣能力，于是我們進(jìn)入了CDN行業(yè)。2015年從直播CDN開始做起，2016年從純視頻的方案開始做點(diǎn)播CDN，2017年和2018年挑戰(zhàn)了更有難度的中等視頻，短視頻方案，2020年，網(wǎng)心的CDN的方案都相對(duì)成熟，于是開始探索新的邊緣計(jì)算場景。

在發(fā)展的這些年中，行業(yè)外部環(huán)境也有所變化，CDN行業(yè)產(chǎn)生了很大的變遷，價(jià)格被斬去很多，云服務(wù)的需求端及供應(yīng)側(cè)更多向大廠集中，另外伴隨著終端側(cè)的提速降費(fèi)。外界環(huán)境的變化對(duì)于網(wǎng)心來說是既有挑戰(zhàn)，也有機(jī)遇，但我認(rèn)為主要是機(jī)遇。

以下是網(wǎng)心積累的邊緣計(jì)算能力：

首先是底層的邊緣設(shè)備接入，最初是基于ARM的小盒子，現(xiàn)在的接入設(shè)備種類更多，從x86，ARM，到MIPS，還包括專有的計(jì)算加速硬件，從早期只有CPU，現(xiàn)在逐漸具備了邊緣計(jì)算上的GPU，NPU能力。接入設(shè)備后，可以基于此做虛擬化組網(wǎng)的工作以實(shí)現(xiàn)在邊緣節(jié)點(diǎn)的業(yè)務(wù)治理，能夠在邊緣上實(shí)際有效地跑相關(guān)業(yè)務(wù)。然后在邊緣網(wǎng)絡(luò)之上封裝PaaS層面的服務(wù)，如邊緣存儲(chǔ)服務(wù)，開放算力提供計(jì)算服務(wù)。

目前邊緣計(jì)算仍處于Gartner成熟度曲線過熱的尖峰上，所以我們認(rèn)為要抓住時(shí)機(jī)，靜下心來尋找落地場景。

3. 邊緣計(jì)算網(wǎng)絡(luò)構(gòu)建

目前網(wǎng)心邊緣計(jì)算網(wǎng)絡(luò)可以概括為“（帶寬）很大，（節(jié)點(diǎn)）很多”，那么如何做到“很大很多”呢？

第一個(gè)問題是，節(jié)點(diǎn)的硬件架構(gòu)及軟件架構(gòu)都不同，如何磨平差異，通過相對(duì)統(tǒng)一的抽象視角對(duì)其進(jìn)行調(diào)度。

第二個(gè)問題是如何對(duì)節(jié)點(diǎn)下發(fā)指令并執(zhí)行，節(jié)點(diǎn)本身的網(wǎng)絡(luò)相當(dāng)不穩(wěn)定，有時(shí)在線有時(shí)不在線，即時(shí)在線，它的延時(shí)也極其不穩(wěn)定，經(jīng)常反復(fù)橫跳。所以在這塊要進(jìn)行大量容錯(cuò)，柔性的處理。

第三個(gè)問題是如何整合節(jié)點(diǎn)網(wǎng)絡(luò)，將零散節(jié)點(diǎn)包裝成看起來面積很大很穩(wěn)定可靠的網(wǎng)絡(luò)，假設(shè)一個(gè)任務(wù)部署在1w個(gè)節(jié)點(diǎn)上運(yùn)行，節(jié)點(diǎn)本身的上線下線容易掉，要針對(duì)性地做冗余、補(bǔ)點(diǎn)的策略。在補(bǔ)點(diǎn)過程中要保證業(yè)務(wù)分布，比如已經(jīng)指定了全國的區(qū)域分布，華東需要多少點(diǎn)，華南需要多少點(diǎn)，那么需要保證分布在一定程度上的穩(wěn)定。當(dāng)出現(xiàn)局部區(qū)域網(wǎng)絡(luò)故障時(shí)，是選擇補(bǔ)點(diǎn)還是跨區(qū)調(diào)度等細(xì)分的業(yè)務(wù)問題，這都是我們遇到的問題。

第四個(gè)問題是如何在整合后的節(jié)點(diǎn)上開發(fā)應(yīng)用，作為用戶如何調(diào)度節(jié)點(diǎn)能力。換句話說就是需要通過虛擬化抽象簡化節(jié)點(diǎn)上的應(yīng)用開發(fā)，同時(shí)繼續(xù)做封裝抽象，盡可能透出一些底層的能力，如節(jié)點(diǎn)上不同的加速硬件。這里的工作很多很細(xì)，舉個(gè)例子說我們需要標(biāo)記節(jié)點(diǎn)，當(dāng)一個(gè)程序在某個(gè)節(jié)點(diǎn)上跑出問題時(shí)，可以通過定位節(jié)點(diǎn)發(fā)現(xiàn)共性，或是在節(jié)點(diǎn)上獲取日志和數(shù)據(jù)。那么如何標(biāo)記節(jié)點(diǎn)呢，我們要賦予節(jié)點(diǎn)唯一的標(biāo)志，但是大量節(jié)點(diǎn)在用戶側(cè)，對(duì)用戶側(cè)的節(jié)點(diǎn)進(jìn)行唯一ID的標(biāo)記涉及到隱私問題，在這塊我們做了一些節(jié)點(diǎn)ID的脫敏處理。

核心要點(diǎn)大致如上，接下來介紹邊緣計(jì)算的基礎(chǔ)架構(gòu)。

底層不同的硬件通過虛擬化抽象出“Pod”的概念，一個(gè)設(shè)備上可以運(yùn)行一或多個(gè)Pod。客戶側(cè)的業(yè)務(wù)就部署在Pod中，Pod通過中心的調(diào)度編排引擎進(jìn)行操控，同時(shí)提供自助控制臺(tái)包括包管理、數(shù)據(jù)采集，方便用戶監(jiān)控應(yīng)用在邊緣的運(yùn)行情況。客戶側(cè)的應(yīng)用量部署在虛擬化Pod中，客戶可以自己進(jìn)行業(yè)務(wù)上層的調(diào)度。虛擬化方面提供多層級(jí)能力，我們提供了裸金屬、VM到容器等多個(gè)層級(jí)，也在開發(fā)更加輕量級(jí)的虛擬化方案如WebAssembly。由于存在部分本身能力相對(duì)較差的邊緣設(shè)備，所以虛擬化的開銷也是需要考慮的問題。現(xiàn)在的函數(shù)計(jì)算場景很熱門，函數(shù)的啟動(dòng)性能也是一項(xiàng)指標(biāo)，而WebAssembly能夠很大提升這方面的指標(biāo)性能。

以上就是對(duì)組網(wǎng)的介紹，那么在下載、點(diǎn)播方面會(huì)遇到什么問題呢？

4. 下載/點(diǎn)播@邊緣計(jì)算

實(shí)例是下載/點(diǎn)播的大致服務(wù)流程。

通常來說，邊緣場景下的點(diǎn)播服務(wù)會(huì)以SDK的形式在客戶端提供，最常見的接入形式是通過local的Http代理做低侵入式的接入改造。舉個(gè)例子，下載一個(gè)視頻時(shí)，視頻的URL原先是向網(wǎng)絡(luò)請(qǐng)求，現(xiàn)在改為向Local SDK請(qǐng)求，SDK在拿到URL后會(huì)做一系列策略，比如在起播階段通過Range方式把頭部或視頻剛開始的數(shù)據(jù)向CDN請(qǐng)求以保證起播質(zhì)量，由于邊緣節(jié)點(diǎn)連接過程比較耗時(shí)，所以為了達(dá)到秒開就要進(jìn)行此過程，拿到起播數(shù)據(jù)之后同時(shí)建立P2P連接，連續(xù)到邊緣節(jié)點(diǎn)進(jìn)行后續(xù)分片。切換的邏輯一方面是由SDK控制，另一方面是將其開放給客戶，讓客戶做精確控制，客戶本身的端之間的P2P做集成切換。

網(wǎng)心其實(shí)也有無SDK接入產(chǎn)品，但我們?cè)赟DK這塊會(huì)進(jìn)行很多精細(xì)化的策略控制，比如數(shù)據(jù)上報(bào)，感知，而無SDK就會(huì)相對(duì)欠缺，但其好處是接入門檻更低。

部署中我們也遇到了一些困難。

邊緣節(jié)點(diǎn)最大的問題是回源質(zhì)量不可控，因?yàn)樗ǔ２幌馡DC會(huì)有網(wǎng)絡(luò)SLA，它的穩(wěn)定性很差。現(xiàn)網(wǎng)統(tǒng)計(jì)數(shù)據(jù)顯示，在點(diǎn)播場景下一個(gè)邊緣節(jié)點(diǎn)的命中與否（未命中要做實(shí)時(shí)回源）傳輸速率差3倍以上，首包耗時(shí)（拿到第一個(gè)字節(jié)的耗時(shí)）存在兩個(gè)數(shù)量級(jí)的差異，顯著大于IDC場景下命中與否造成的差異。基于此我們必須想辦法提升邊緣節(jié)點(diǎn)訪問的命中率，而提升命中率時(shí)受到的最大限制是邊緣節(jié)點(diǎn)存儲(chǔ)容量有限，大概在1G到幾百G不等，和IDC水平相差甚遠(yuǎn)，所以只能另辟蹊徑，做到更精細(xì)化的部署。緩存的命中率很大程度上取決于數(shù)據(jù)熱度，我們也是基于熱度決定資源部署的相應(yīng)節(jié)點(diǎn)。那么在這塊我們部署得比較精細(xì)，基本可以計(jì)算市級(jí)覆蓋范圍內(nèi)所有內(nèi)容的熱度，再選擇最熱的數(shù)據(jù)部署到此范圍節(jié)點(diǎn)上。過程中的計(jì)算量很大，計(jì)算模型也很復(fù)雜，因?yàn)楫?dāng)內(nèi)容熱度拆分到市級(jí)時(shí)，樣本數(shù)量很少，而基于少量樣本做準(zhǔn)確估計(jì)很有難度。此外，我們也在不斷迭代計(jì)算模型，希望利用新進(jìn)入用戶的數(shù)據(jù)做結(jié)構(gòu)分析，從而探索出更好的熱度預(yù)測方法。

邊緣節(jié)點(diǎn)不僅有限還多種多樣，不同節(jié)點(diǎn)的網(wǎng)絡(luò)類型差別很大，這也是基于它的異構(gòu)性。同一種設(shè)備上的邊緣節(jié)點(diǎn)可能存儲(chǔ)能力相近，但網(wǎng)絡(luò)帶寬之間存在很大差異。所以要對(duì)不同類型的節(jié)點(diǎn)進(jìn)行分類，建立不同的性能模型，模型本身也需要在某段時(shí)間中進(jìn)行很多修正。起初我們將邊緣節(jié)點(diǎn)分為三類，經(jīng)過不同的修正，至今應(yīng)該已有不低于十種類型，一方面要對(duì)節(jié)點(diǎn)做建模，還要針對(duì)不同模型使用不同的策略。舉個(gè)例子，在長視頻請(qǐng)求中，上文提到起播部分走了CDN，剩下的部分有十幾種類型的節(jié)點(diǎn)，那么就要選擇傳輸速率最高，在線率最好的節(jié)點(diǎn)請(qǐng)求剩下的數(shù)據(jù)，后面的數(shù)據(jù)關(guān)聯(lián)性越弱可以相應(yīng)地使用較弱的節(jié)點(diǎn)，這只是比較粗淺的例子，實(shí)際場景中的情況更加復(fù)雜。對(duì)應(yīng)到短視頻，因?yàn)闆]有多少空間可以騰挪，視頻在1s之內(nèi)就能下載完畢，這1s之內(nèi)的下載速度變化對(duì)體驗(yàn)影響很大，沒有更多時(shí)間進(jìn)行切換。短視頻相較于長視頻的要求更高，所以我們最初選擇從長視頻入手。

節(jié)點(diǎn)不僅有不同的能力模型，甚至細(xì)粒度到單個(gè)節(jié)點(diǎn)的能力變化也非常劇烈，對(duì)節(jié)點(diǎn)的評(píng)估也并不容易。邊緣節(jié)點(diǎn)不像IDC中的服務(wù)器帶寬都是規(guī)定好的，邊緣節(jié)點(diǎn)的能力不能被準(zhǔn)確地預(yù)知。另外，邊緣節(jié)點(diǎn)的能力變化非常顯著，可以普遍觀測到在晚高峰，基本一半以上的邊緣編解碼會(huì)明顯出現(xiàn)RTT和丟包率的惡化，基于此特點(diǎn)就要采取自適應(yīng)的控制策略，對(duì)節(jié)點(diǎn)的復(fù)雜調(diào)度其實(shí)類似于網(wǎng)絡(luò)傳輸中的擁塞控制算法，是通過探測的方式觀察節(jié)點(diǎn)在不同復(fù)雜水平下的表現(xiàn)，再根據(jù)對(duì)表現(xiàn)的反饋決定提升或降低調(diào)度復(fù)雜的水平，探測完成后還會(huì)對(duì)數(shù)據(jù)進(jìn)行上報(bào)統(tǒng)計(jì)并進(jìn)行能力畫像，畫像會(huì)精細(xì)到單個(gè)設(shè)備及時(shí)間維度，至少要將晚高峰幾小時(shí)的細(xì)粒度表現(xiàn)記錄下來。

以上的三個(gè)問題（節(jié)點(diǎn)的能力受限、節(jié)點(diǎn)能力的多樣、節(jié)點(diǎn)能力的不確定性）的解決辦法總結(jié)出來就是要精細(xì)化策略，那么隨之?dāng)?shù)據(jù)也要精細(xì)化。所以我們做了細(xì)粒度（秒級(jí)粒度）數(shù)據(jù)上報(bào)，所有的邊緣節(jié)點(diǎn)和SDK都進(jìn)行非常細(xì)粒度的數(shù)據(jù)上報(bào)，這樣帶來的數(shù)據(jù)量就會(huì)非常大，面臨的成本問題也更具挑戰(zhàn)性。我們利用邊緣節(jié)點(diǎn)做了一些offload，成本下降了大概一半。

5. 直播@邊緣計(jì)算

直播的服務(wù)原理和點(diǎn)播差不多，也是起播走CDN，后續(xù)切換到邊緣節(jié)點(diǎn)。

上文提到邊緣節(jié)點(diǎn)的回源很差，但直播的所有內(nèi)容都是實(shí)時(shí)生成的，必須回源。所以我們不得不用到一些復(fù)雜的策略對(duì)直播流做了編碼和切分，切分為片后將其分配到不同的邊緣節(jié)點(diǎn)上，SDK可以同時(shí)連接很多邊緣節(jié)點(diǎn)，從一個(gè)節(jié)點(diǎn)中拿一部分片，這樣即使一個(gè)邊緣節(jié)點(diǎn)出現(xiàn)了問題，影響的也只是小部分?jǐn)?shù)據(jù)。同時(shí)我們?cè)诰幋a上做了冗余，掉一或兩個(gè)節(jié)點(diǎn)的影響并不大，依然可以通過冗余的分配恢復(fù)完整的流數(shù)據(jù)。通過這個(gè)機(jī)制可以在回源比較差的情況下保證較好的質(zhì)量。

切換過程和點(diǎn)播一樣，也可以通過SDK控制或開放給客戶進(jìn)行控制。

機(jī)制實(shí)現(xiàn)中我們也遇到了一些問題。

首先，雖然可以容忍一些掉點(diǎn)的情況，但持續(xù)掉點(diǎn)的情況下，我們還是需要盡快補(bǔ)點(diǎn)，這類似于給行駛的汽車換輪胎，對(duì)換輪胎的速度提出了很高的要求，所以連接成功率對(duì)最終質(zhì)量影響顯著。所以網(wǎng)心在2015年選擇直播方向切入可以說是以Hard模式起手。

解決這個(gè)問題的方法首先還是精細(xì)化策略，盡量為SDK選擇最適合的邊緣節(jié)點(diǎn)，精細(xì)調(diào)度的方法無非就是如何更精確地識(shí)別SDK的網(wǎng)絡(luò)位置，更精確地識(shí)別所有節(jié)點(diǎn)的網(wǎng)絡(luò)位置，然后對(duì)兩者進(jìn)行匹配。網(wǎng)心的特別之處在于本身有大量的邊緣節(jié)點(diǎn)，可以進(jìn)行更多的撥測，得到更多數(shù)據(jù)，利用數(shù)據(jù)完善識(shí)別的精度。

另一個(gè)方法是節(jié)點(diǎn)預(yù)熱，大家都知道，連上節(jié)點(diǎn)和連上之后節(jié)點(diǎn)是否有流是兩回事，如果沒有流就要發(fā)起回源，所以我們會(huì)做預(yù)推，而預(yù)推的本質(zhì)是成本的犧牲兌換體驗(yàn)的提升。

再回到回源問題，實(shí)時(shí)音視頻講究的是全鏈路的質(zhì)量。解決方法是規(guī)劃更好的回源路徑，這里最重要的是要理解所處的網(wǎng)絡(luò)，網(wǎng)絡(luò)是由運(yùn)營商構(gòu)建的，于是就需要更多運(yùn)營商側(cè)的信息，了解他們的網(wǎng)絡(luò)拓?fù)?#xff0c;基于這些信息進(jìn)行區(qū)域的調(diào)度及回源路徑的規(guī)劃策略。但很多時(shí)候我們能夠獲得的信息并不完全透明，實(shí)際運(yùn)營商在執(zhí)行中也會(huì)出現(xiàn)一些偏離規(guī)劃的情況，這時(shí)就要依靠其他數(shù)據(jù)進(jìn)行補(bǔ)充，就又回到了邊緣網(wǎng)絡(luò)撥測這一點(diǎn)，我們通過高頻、高密度的撥測探測網(wǎng)絡(luò)結(jié)構(gòu)來做網(wǎng)絡(luò)決策。但撥測是模擬的行為，并不代表真實(shí)業(yè)務(wù)跑起來的情況。上文提到的節(jié)點(diǎn)預(yù)熱可以一定程度上提供數(shù)據(jù)支撐，因?yàn)樗鼈鬏數(shù)目赡苁钦鎸?shí)的視頻流，基于其中的幀率等數(shù)據(jù)可以更好的衡量鏈路的真實(shí)質(zhì)量。

6.?未來可期

未來網(wǎng)心會(huì)繼續(xù)探索更多落地的邊緣計(jì)算場景，更深度、更廣度地挖掘場景。“更深度”：指對(duì)現(xiàn)有場景的深化，比如如何進(jìn)一步提升邊緣CDN的指標(biāo)，做低延時(shí)直播。“更廣度”：目前應(yīng)用的場景還是邊緣帶寬，后續(xù)希望能深入挖掘算力及其他的場景如AR、VR、云游戲。

同時(shí)要完善基礎(chǔ)設(shè)施以服務(wù)支撐上述場景，一方面增強(qiáng)節(jié)點(diǎn)能力。另一方面將更多關(guān)注融合及標(biāo)準(zhǔn)化的工作，如云邊協(xié)同、邊緣原生。因?yàn)橹熬W(wǎng)心完全是從自建架構(gòu)出發(fā)、從特定場景出發(fā)構(gòu)建系統(tǒng)，那么未來我們希望更向行業(yè)標(biāo)準(zhǔn)對(duì)齊。

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

---

講師招募

LiveVideoStackCon 2022 音視頻技術(shù)大會(huì) 上海站，正在面向社會(huì)公開招募講師，無論你所處的公司大小，title高低，老鳥還是菜鳥，只要你的內(nèi)容對(duì)技術(shù)人有幫助，其他都是次要的。歡迎通過?speaker@livevideostack.com?提交個(gè)人資料及議題描述，我們將會(huì)在24小時(shí)內(nèi)給予反饋。

喜歡我們的內(nèi)容就點(diǎn)個(gè)“在看”吧！

超強(qiáng)干貨來襲 云風(fēng)專訪：近40年碼齡，通宵達(dá)旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的​冲刺最后一公里——音视频场景下的边缘计算实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。