編者按： 內(nèi)容視頻化已是當(dāng)下行業(yè)公認(rèn)的趨勢(shì)。飛速增長(zhǎng)的音視頻數(shù)據(jù)量對(duì)計(jì)算帶來(lái)了巨大挑戰(zhàn)，而當(dāng)下云、端算力的局限性，也制約了音視頻數(shù)據(jù)的價(jià)值挖掘。本次分享將圍繞上述問(wèn)題，介紹依托 5G 等基礎(chǔ)建設(shè)興起的邊緣計(jì)算如何為音視頻應(yīng)用松綁，以及網(wǎng)心科技在這一方向上的實(shí)踐歷程。

文 / 曾偉紀(jì)

整理 / LiveVideoStack

大家下午好，非常高興能夠再次來(lái)到 LiveVideoStack 和大家進(jìn)行一個(gè)交流。我們借助云端的算力可以讓終端得到一個(gè)炫酷的體驗(yàn)，這是我認(rèn)為過(guò)去十多年以來(lái)技術(shù)發(fā)展非常重要的一點(diǎn)，今天我的分享也和這個(gè)問(wèn)題有關(guān)。

首先做個(gè)簡(jiǎn)單的自我介紹，我早年在成立不久的騰訊云做過(guò)云端后臺(tái)的服務(wù)，后來(lái)在 2015-2016 年左右，我才開始做現(xiàn)在的這些事情，再后來(lái)我才知道，這叫邊緣計(jì)算，從那時(shí)候開始，我和音視頻結(jié)下了不解之緣，一直持續(xù)到今天。所以今天，我想給大家分享 “以泛在算力挖掘泛在價(jià)值”。

1、流失的泛在價(jià)值

首先，我們來(lái)看價(jià)值流失的問(wèn)題。內(nèi)容視頻化是一個(gè)大趨勢(shì)，人是視覺(jué)動(dòng)物，我們對(duì)視頻的接受程度和我們對(duì)視頻的喜愛(ài)程度是毫無(wú)疑問(wèn)的。無(wú)處不在的視頻也就代表了無(wú)處不在的價(jià)值，這也是我們題目中所說(shuō)的泛在價(jià)值。這個(gè)潛力有多大呢？我們來(lái)看一個(gè)數(shù)據(jù)。

來(lái)自 IDC 的統(tǒng)計(jì)數(shù)據(jù)顯示，到 2025 年創(chuàng)建的數(shù)據(jù)會(huì)達(dá)到 175ZB，這相當(dāng)于 2022 年的兩倍，而當(dāng)中以視頻為主的非結(jié)構(gòu)化數(shù)據(jù)占到 80%，視頻蘊(yùn)含的價(jià)值將是巨大的，這也是我們今天所提到的泛在價(jià)值。這些價(jià)值又是怎么挖掘出來(lái)的？我們可以看一下數(shù)據(jù)的生命周期。

從上圖顯示，我們數(shù)據(jù)的創(chuàng)建正在更多的趨向于邊緣，同樣的數(shù)據(jù)的存儲(chǔ)也會(huì)向中心和邊緣轉(zhuǎn)變，而終端的占比會(huì)下降。但是我們整個(gè)數(shù)據(jù)的處理一直是偏中心，我們的消費(fèi)又一直在端側(cè)，這樣就出現(xiàn)了算力的錯(cuò)位。

我們知道視頻處理的數(shù)據(jù)量是非常大的，算力的需求也非常高，那么這樣的一個(gè)錯(cuò)位就會(huì)導(dǎo)致在實(shí)際應(yīng)用中，數(shù)據(jù)追著算力跑，這就會(huì)產(chǎn)生大量的算力搬運(yùn)成本。除了成本之外，其中產(chǎn)生的延時(shí)也限制了更多的實(shí)時(shí)的場(chǎng)景體驗(yàn)；既然終端算力是有限的，為什么沒(méi)法放到云端呢？就是因?yàn)檠舆t。我們可以看到這么一組數(shù)據(jù)，所有生產(chǎn)的數(shù)據(jù)中，有 44% 根本沒(méi)有被采集，而被采集的數(shù)據(jù)中也只有 57% 的數(shù)據(jù)得到利用，也就是總共也只有四分之一多一點(diǎn)的數(shù)據(jù)最后能被挖掘，這顯然是一個(gè)巨大的價(jià)值流失。那么這個(gè)問(wèn)題的原因是什么？

目前，云計(jì)算是現(xiàn)在計(jì)算的一個(gè)主流，那這個(gè)鍋是云計(jì)算的嗎？云計(jì)算實(shí)際上是開創(chuàng)了云端算力的模式，把云端算力投射到終端上，這是一個(gè)技術(shù)上的巨大飛躍。它的問(wèn)題在于現(xiàn)在的云計(jì)算更多基于中心的超大規(guī)模的 IDC，所以這種中心化的布局現(xiàn)在遇到了瓶頸，需要進(jìn)一步的發(fā)展，所以就產(chǎn)生了下沉的需求。比如 CDN 技術(shù)，就是將傳輸下沉到離端更近的地方，改善傳輸質(zhì)量?，F(xiàn)在我們做的多數(shù)據(jù)中心接入架構(gòu)，其實(shí)也是在做計(jì)算方面的下沉，但是就僅僅到這一步嗎？為什么我們不能再進(jìn)一步？是因?yàn)闆](méi)有算力嗎？

根據(jù) 2022 年的 AWS Invent 大會(huì)上發(fā)布的數(shù)據(jù)，每一百臺(tái)出貨的服務(wù)器中，只有四臺(tái)是流向云計(jì)算廠商。另外，我們終端處理器的性能在這些年飆升的非?？?，而且，我們終端的出貨量也維持了很高的水平，在不斷上漲。所以 IDC 以外的算力應(yīng)該是普遍存在的，量也非常充足，因此這個(gè)端和邊的設(shè)備也是不背鍋的。

那么還有什么原因？會(huì)是網(wǎng)絡(luò)連接嗎？我們知道運(yùn)營(yíng)商的網(wǎng)絡(luò)非常復(fù)雜，而其實(shí)我們互聯(lián)網(wǎng)做的事情非常簡(jiǎn)單，就是把所有電腦都連起來(lái)。在把所有電腦都連起來(lái)的方法中，做 Mesh 顯然最直接，也就是每?jī)膳_(tái)電腦之間都拉根線，但是，為了不被網(wǎng)線淹死，我們的網(wǎng)絡(luò)更多會(huì)做成樹狀的結(jié)構(gòu)，底層做一個(gè)樹狀的收斂。

再具體到每個(gè)省會(huì)對(duì)應(yīng)到它附近的一個(gè)核心節(jié)點(diǎn)，全國(guó)的核心節(jié)點(diǎn)也就這幾個(gè)，在核心節(jié)點(diǎn)以下，其實(shí)都是層層的樹狀匯聚的，在核心節(jié)點(diǎn)之間，鑒于核心節(jié)點(diǎn)也不多，所以我們?yōu)榱诵?，就可以把它做?Mesh 的結(jié)構(gòu)?；谶@個(gè)結(jié)構(gòu)，我們就知道網(wǎng)絡(luò)里任意兩點(diǎn)之間大概率不是直聯(lián)，基本上只有核心點(diǎn)之間有 Mesh 的才是直聯(lián)。所以，實(shí)際上在城域網(wǎng)，同城的兩個(gè)節(jié)點(diǎn)互聯(lián)，只要上升到城域網(wǎng)，再下降回去就可以了，這個(gè)延遲大概是在 7 毫秒以內(nèi)。而如果是同省的話，就要上升到省級(jí)核心交換機(jī)，大概是 10 毫秒的延遲水平。跨省了以后，就不確定了，因?yàn)樾枰ソ?jīng)過(guò)這些省，兩個(gè)省之間，如果掛在同一個(gè)核心節(jié)點(diǎn)下，那還稍微好一點(diǎn)，只要上升到省核心節(jié)點(diǎn)，再下沉就行了。

鑒于運(yùn)營(yíng)商的省公司是獨(dú)立運(yùn)作的，互相之間的互聯(lián)經(jīng)常有不確定性。如果兩個(gè)省掛接在不同的全國(guó)核心下方，路徑顯然會(huì)更長(zhǎng)，跨區(qū)實(shí)際上是長(zhǎng)途跋涉。我們做 CDN 就是應(yīng)對(duì)這種網(wǎng)絡(luò)情況，在一個(gè)復(fù)雜的網(wǎng)絡(luò)拓?fù)渲袑ふ乙粭l相對(duì)靠譜、質(zhì)量好一點(diǎn)的路去把數(shù)據(jù)傳輸過(guò)去。我們一般是認(rèn)為資源下沉到同省是一個(gè)從成本和質(zhì)量上比較平衡的做法，因?yàn)橥?nèi)的互聯(lián)是比較有保障的，那么跨中心就已經(jīng)不太靠譜。如果進(jìn)一步，我們想要跨運(yùn)營(yíng)商呢？

這是國(guó)內(nèi)運(yùn)營(yíng)商互聯(lián)的情況，比如電信和聯(lián)通兩個(gè)點(diǎn)想要互聯(lián)，只有這幾條路可以走，首先路肯定是變長(zhǎng)了；其次，由于三大運(yùn)營(yíng)商之間的關(guān)系，互聯(lián)基本上質(zhì)量難以保證，成功率基本看天。我們?nèi)プ鰝鬏?，走到跨運(yùn)營(yíng)商的步驟，基本上屬于死馬當(dāng)活馬醫(yī)，除非我們?nèi)ゲ少?gòu)一些比較昂貴的互聯(lián)資源，比如三線機(jī)房，BGP 機(jī)房，這樣去找一條穩(wěn)妥的路去做互聯(lián)，當(dāng)然成功率就非常的高。講到這，我們就破案了。

其實(shí)我們算力接入門檻主要的問(wèn)題是跨運(yùn)營(yíng)商乃至跨省的連接質(zhì)量都難以保障，因此我們?nèi)プ鲈朴?jì)算基礎(chǔ)設(shè)施的構(gòu)建時(shí)，顯然我們的首選是把算力接入核心節(jié)點(diǎn)和互聯(lián)節(jié)點(diǎn)，圍繞著這幾點(diǎn)轉(zhuǎn)，它想下沉就很困難，需要克服很多網(wǎng)絡(luò)連接的問(wèn)題。另一方面，如果想要把資源下沉，算力就很分散，分散的算力對(duì)業(yè)務(wù)開發(fā)也提出了更高要求。為了解決算力分割問(wèn)題，邊緣計(jì)算就閃亮登場(chǎng)了。

2、邊緣計(jì)算與泛在算力

我們前面提到過(guò)，算力分布是不太合理的，這導(dǎo)致了很多價(jià)值的流失。那么現(xiàn)在為什么邊緣計(jì)算能夠興起？

邊緣計(jì)算興起的先決條件是網(wǎng)絡(luò)。我們網(wǎng)絡(luò)資源其實(shí)是在不斷下沉的，在固網(wǎng)這塊相對(duì)還是比較容易，然后現(xiàn)在的問(wèn)題是我們比重越來(lái)越大的移動(dòng)網(wǎng)絡(luò)。移動(dòng)網(wǎng)絡(luò)在過(guò)去 3G、4G 時(shí)代，我們手機(jī)上發(fā)出一個(gè)數(shù)據(jù)包進(jìn)入互聯(lián)網(wǎng)，需要上傳到省網(wǎng)才能接入，與公網(wǎng)還不一樣，固網(wǎng)加寬是可以接入手機(jī)網(wǎng)的，這個(gè)情況在 5G 時(shí)代才有所改變。5G 有了 UPF 和 MEC 技術(shù)，使得手機(jī)發(fā)出的數(shù)據(jù)包可以在城域網(wǎng)就接入互聯(lián)網(wǎng)，這就使得更短路徑連接成為可能。此外，5G 的空口改進(jìn)，把帶寬的延遲水平大大地拉進(jìn)到了和固網(wǎng)接近的水平，因此，我們?cè)谝粋€(gè)更靠近邊緣的地方去部署算力，去接入算力得到了一些必備的條件。

接下來(lái)就是邊緣的算力條件，這個(gè)我們之前講到過(guò)，邊緣不缺算力。

再下一步就是我們的應(yīng)用開發(fā)能力。你底層有了這些資源，那你怎么去用它呢？近年來(lái)，分布式技術(shù)的發(fā)展使管理大量邊緣節(jié)點(diǎn)成為可能。然后就像我們剛才提及的邊緣的復(fù)雜網(wǎng)絡(luò)條件隨著傳輸技術(shù)的發(fā)展，比如新的傳輸協(xié)議等等，使得邊緣的復(fù)雜網(wǎng)絡(luò)不再會(huì)是一個(gè)很難跨越的障礙。最后就是云原生等技術(shù)使分布式應(yīng)用開發(fā)難度降低，我們可以用起來(lái)大量異構(gòu)且分散的資源，所以就有了邊緣計(jì)算。

這是很多權(quán)威機(jī)構(gòu)對(duì)于邊緣計(jì)算的定義，其實(shí)就是把算力下沉，但它帶來(lái)的效果確實(shí)是實(shí)打?qū)嵉?。我們可以把算力部署到更多的位置，它可以覆蓋本身所處位置上的數(shù)據(jù)，同時(shí)它也可以以更低的延遲去覆蓋其他位置的數(shù)據(jù)。

那么再具體一點(diǎn)，根據(jù) Linux 基金會(huì)對(duì)邊緣計(jì)算的概括，邊緣計(jì)算類似于基于 5G、AI 一些硬件能力，以及云原生一些開發(fā)能力，邊緣計(jì)算可以運(yùn)用到什么場(chǎng)景？互聯(lián)網(wǎng)沉浸式體驗(yàn)，邊緣自治是典型的 Use case。

概括一下，云計(jì)算突破了終端對(duì)算力的限制，邊緣計(jì)算則填補(bǔ)了端與中心之間的算力真空，實(shí)現(xiàn)了算力泛在化，使得我們可以更好地去挖掘泛在價(jià)值。

3、網(wǎng)心科技邊緣計(jì)算實(shí)踐

在邊緣計(jì)算實(shí)踐上，網(wǎng)心 2014 年底就開始從迅雷業(yè)務(wù)改造入手，然后，我們的業(yè)務(wù)從直播切入，去做一些 TO B 的服務(wù)，從長(zhǎng)視頻到中視頻再到短視頻的視頻點(diǎn)播，難度也是越來(lái)越大。除了音視頻，我們也在開始去拓展更多的邊緣計(jì)算場(chǎng)景。大家知道，邊緣計(jì)算的概念在 2016 年左右成型，在這兩年成為了風(fēng)口，而網(wǎng)心實(shí)際上已經(jīng)在這個(gè)方向做了快八年，中間也經(jīng)歷了云計(jì)算的大發(fā)展，整個(gè)行業(yè)加劇了競(jìng)爭(zhēng)，同時(shí)也經(jīng)歷了技術(shù)變革。

接下來(lái)，看一下我們積累下來(lái)的整體服務(wù)架構(gòu)。我們?cè)谏蠈犹峁┑漠a(chǎn)品服務(wù)，包括像云計(jì)算里的 CDN，以及函數(shù)計(jì)算、安全、存儲(chǔ)等服務(wù)。其實(shí)接入和在傳統(tǒng)云里的服務(wù)并沒(méi)有太大的區(qū)別，感知是很小的，但是它在特定的場(chǎng)景下，會(huì)比傳統(tǒng)的云服務(wù)效率更高。這些效率來(lái)自于底層，我們底層去覆蓋云邊端一系列的計(jì)算資源，云端自然不用說(shuō)，在邊緣側(cè)我們會(huì)有更下沉的數(shù)據(jù)中心，我們還有來(lái)自運(yùn)營(yíng)商的一些邊緣機(jī)房，以及一些企業(yè)現(xiàn)場(chǎng)的機(jī)房，這都會(huì)被納入到計(jì)算網(wǎng)絡(luò)里。

在端側(cè)我們有一些自研的邊緣硬件資源，同時(shí)，我們也可以把很多生態(tài)的硬件納入到基層網(wǎng)絡(luò)中來(lái)，比如說(shuō)家里很常見的 NAS，路由器，甚至于電視機(jī)，機(jī)頂盒還有個(gè)人 PC，我們有非常多這樣的生態(tài)節(jié)點(diǎn)。那么如何去把這些能力、形態(tài)、位置各異的底層資源包裝成一個(gè)通用的云服務(wù)，讓上層接入沒(méi)有太多感知？這其實(shí)就是靠中間邊緣計(jì)算平臺(tái)的這一層。

回顧網(wǎng)心邊緣計(jì)算落地的路線，是從邊緣 CDN 切入，基于邊緣 CDN 再去把底層的 IaaS 層開放出來(lái)，初期是面向邊緣傳輸?shù)?IaaS。接下來(lái)，我們會(huì)在此之上構(gòu)建一個(gè)邊緣容器平臺(tái)，能夠去做更多更廣泛的計(jì)算場(chǎng)景，不再僅僅是傳輸，最后是邊緣云原生，能夠讓上層的業(yè)務(wù)應(yīng)用更方便地接入到邊緣計(jì)算的網(wǎng)絡(luò)層。

首先，我們來(lái)看一下。第一步，我們做的邊緣 CDN 的事情。前面其實(shí)也提及過(guò)，CDN 做的事情實(shí)際上就是下沉，用戶的內(nèi)容更多是在中心的云機(jī)房，CDN 就是會(huì)把它進(jìn)一步下沉，比如說(shuō)下沉到省網(wǎng)的級(jí)別，來(lái)獲得一個(gè)更好的傳輸體驗(yàn)。邊緣 CDN 原理是一樣的，只是我會(huì)把內(nèi)容去做更加進(jìn)一步的下沉，下沉到城域網(wǎng)，甚至于下沉到接入網(wǎng)的邊緣設(shè)備上去。別看只是多了一兩層，但其實(shí)它的復(fù)雜度是成倍上升的。

我們來(lái)看一下，做這個(gè)事情需要突破的關(guān)鍵技術(shù)點(diǎn)。第一個(gè)是智能調(diào)度 / 部署，調(diào)度和部署關(guān)系非常大，部署是如何把要分發(fā)的資源去分布到這些設(shè)備上去，如果請(qǐng)求的時(shí)候，你能夠命中一臺(tái)附近的設(shè)備，顯然你的傳輸效果是比較理想的，這樣就不需要去做一個(gè)回源，去回到中心機(jī)房，產(chǎn)生很高昂的成本以及很高的延遲。既然我們把這個(gè)內(nèi)容進(jìn)一步下沉到城域網(wǎng)，甚至接入網(wǎng)，我們網(wǎng)絡(luò)的深度、復(fù)雜度自然是一個(gè)指數(shù)級(jí)的提升。所以，在這塊，我們就需要更加細(xì)粒度的調(diào)度和部署的策略。

此外，就是全聯(lián)通網(wǎng)絡(luò)。邊緣的網(wǎng)絡(luò)是非常復(fù)雜的，不僅是剛才所說(shuō)的延遲等問(wèn)題，還存在大量的內(nèi)網(wǎng)穿透、防火墻穿透等問(wèn)題，這塊也是需要花非常多的精力去解決的。

接下來(lái)是，HARQ 加上多路徑傳輸。這其實(shí)也是為了應(yīng)對(duì)在 IDC 以外，無(wú) SLA 網(wǎng)絡(luò)，我們必須采取更激進(jìn)的策略才能保證傳輸?shù)姆€(wěn)定性。

最后，就是節(jié)點(diǎn)自適應(yīng)和鏈路自適應(yīng)。我們?cè)?IDC 里做應(yīng)用的時(shí)候，我們的設(shè)備往往都相對(duì)比較標(biāo)準(zhǔn)，它有多少能力，它的算力有多少，以及它的帶寬有多少，這些都是事先能夠確定的。但是在邊緣網(wǎng)絡(luò)里，這些設(shè)備是多種多樣的，甚至有很多設(shè)備是無(wú)法預(yù)先得知的，我能給你多少算力，我能具備多少帶寬，這些東西都需要我們自己有一套探測(cè)和自適應(yīng)的機(jī)制去保證既能夠把設(shè)備能力充分利用，又避免把它用的太狠了，出現(xiàn)質(zhì)量問(wèn)題。

在解決了這些問(wèn)題之后，我們才構(gòu)建起來(lái)一個(gè)可用的邊緣 CDN 網(wǎng)絡(luò)，在我們的服務(wù)場(chǎng)景下，質(zhì)量可以和傳統(tǒng) CDN 不相上下，這在我們客戶的 QoE 數(shù)據(jù)中也得到了驗(yàn)證。但是只做一個(gè) CDN 可能是不夠的，它更多的意義是什么呢？

我們知道，CDN 已經(jīng)很卷了。如果我們只是千辛萬(wàn)苦做出來(lái)一個(gè)邊緣 CDN，我們把質(zhì)量稍微提高一點(diǎn)，價(jià)格稍微降低一點(diǎn)，這顯然不是我們的星辰大海。在 2018 至 2019 年，我們的邊緣 CDN 基本上成型了，下一步的著力點(diǎn)是平臺(tái)，一個(gè)新的復(fù)雜技術(shù)體系的落地往往會(huì)是一個(gè)上面應(yīng)用、下面平臺(tái)的關(guān)系，也就是說(shuō)往往需要先有一個(gè)可行的應(yīng)用場(chǎng)景，然后去打開切入點(diǎn)，等應(yīng)用場(chǎng)景不斷發(fā)展成熟之后，沉淀出一些平臺(tái)的產(chǎn)品來(lái)，其實(shí)我們的路線也正是這樣的。邊緣 CDN 作為一個(gè)比較好落地的應(yīng)用積累了我們對(duì)底層平臺(tái)的需求認(rèn)知，我們從場(chǎng)景中沉淀出通用能力下沉到底層平臺(tái)?；剡^(guò)頭來(lái)，我們以不斷完善的底層能力去提升上層應(yīng)用的表現(xiàn)，同時(shí)，我們組合底層積累的不同能力就可以去創(chuàng)新出新的應(yīng)用場(chǎng)景。

接下來(lái)，我們來(lái)看一下我們的邊緣計(jì)算平臺(tái)。這其實(shí)和云計(jì)算的 IaaS 層面非常相像。因?yàn)檫吘壻Y源的特殊性，它也有一些自己的技術(shù)特點(diǎn)。

前面也提及過(guò)，平臺(tái)是一個(gè)聯(lián)通上下兩層的東西，這里面會(huì)有一個(gè)中間層。計(jì)算機(jī)科學(xué)中有一個(gè)很經(jīng)典的中間層定律，計(jì)算機(jī)科學(xué)領(lǐng)域的任何問(wèn)題都可以通過(guò)增加一個(gè)間接的中間層來(lái)解決。我覺(jué)得這還有點(diǎn)不太完整，如果一層不夠，那就兩層。

接下來(lái)，我們?cè)谶@個(gè)層里面到底做了什么事。其實(shí)剛才也提到，我們做 CDN 很重要的一個(gè)目標(biāo)是通過(guò)一些具體的應(yīng)用去了解底層的需求，去沉淀能力，其實(shí)可以看到我們?cè)诘讓拥倪吘売?jì)算平臺(tái)上去做這樣的一些事情，很多也是和剛才 CDN 做的事情比較類似，就是沉淀下來(lái)通用的一些需求。

第一點(diǎn)是異構(gòu)資源適配抽象，我們其實(shí)接入的資源非常多，操作系統(tǒng)就不用說(shuō)了，包括 CPU 的架構(gòu)就有很多種比如 X86、ARM、MIPS、RISC-V 等各種設(shè)備。我們需要去把這些設(shè)備一個(gè)個(gè)接入進(jìn)來(lái)，我們要能夠有一些在上面運(yùn)行的像 Agent 這樣的程序，通常我們會(huì)開發(fā)相應(yīng)設(shè)備的固件，或者說(shuō)我們對(duì)固件比較成熟的設(shè)備去開發(fā)一些插件來(lái)把它們接入到算力網(wǎng)絡(luò)中來(lái)，同時(shí)我們還需要去做一些虛擬化或者是容器化的事情，去抽象這些資源，使得應(yīng)用開發(fā)不要太痛苦。

第二點(diǎn)是邊緣自治。邊緣自治針對(duì)的是什么問(wèn)題呢？邊緣的設(shè)備和中心中控的機(jī)群連接是不太穩(wěn)定的，所以我們邊緣需要做一些自治邏輯，好讓這些設(shè)備在和中心連接不上的情況下，不要輕舉妄動(dòng)。

第三點(diǎn)是 SLA 分級(jí)保障。前面也提及過(guò)，我們的資源是多種多樣的，它們的能力以及它們的質(zhì)量穩(wěn)定性也是千差萬(wàn)別的。我們?yōu)榱四軌蛉ズ?jiǎn)化，我們應(yīng)用上去做調(diào)度、去分配任務(wù)的邏輯，我們會(huì)把不同能力、不同質(zhì)量的資源去做分級(jí)的運(yùn)營(yíng)，同時(shí)我們也會(huì)有一些針對(duì)不同類型資源的激勵(lì)運(yùn)營(yíng)手段，去提升每一類資源內(nèi)的自身能力和質(zhì)量。

第四點(diǎn)是大規(guī)模異構(gòu)資源管理。這其實(shí)主要是針對(duì)節(jié)點(diǎn)數(shù)量，之前也提及過(guò)我們目前的節(jié)點(diǎn)是百萬(wàn)級(jí)別的，這個(gè)管理起來(lái)也是頗具難度的。

第五點(diǎn)是調(diào)度裝箱。我們希望最大化利用我們的資源，這其實(shí)和各大云廠做的虛擬機(jī)的調(diào)度裝箱沒(méi)有本質(zhì)的區(qū)別，當(dāng)然它的場(chǎng)景會(huì)更加復(fù)雜一些，因?yàn)槲覀兊墓?jié)點(diǎn)是分開在邊緣里的。首先，它的能力差異就很大，調(diào)度面臨的情況就非常復(fù)雜，其次，你想要去做一些應(yīng)用遷移之類的事情，它也不像傳統(tǒng)云計(jì)算技術(shù)，在 IDC 里遷移是非常方便的，在邊緣就沒(méi)有那么方便，甚至兩個(gè)點(diǎn)中間可能間隔的是整個(gè)城域網(wǎng)或者是整個(gè)省網(wǎng)，這自然是需要去定制一些策略，做一些取舍。

第六點(diǎn)是安全，這也是一個(gè)非常大的挑戰(zhàn)。傳統(tǒng)云計(jì)算，在 IDC 里面能保證一個(gè)物理隔離，閑雜人等不能隨隨便便進(jìn)入 IDC。在邊緣的話，這種保障就沒(méi)有那么強(qiáng)，物理接觸的可能性會(huì)非常高。所以，這塊我們也需要做更多的封裝需要更加全面的一些安全措施。

我們看完中間這一層，再來(lái)看底層的資源。這些年，我們?cè)诘讓淤Y源做了非常多的探索，底層資源也有了非常多演變。最開始，我們基于自研的硬件去構(gòu)建邊緣計(jì)算網(wǎng)絡(luò)。隨著平臺(tái)能力的不斷發(fā)展，我們不斷地把更多資源納入進(jìn)來(lái)，包括之前提及的一些家庭端的其他設(shè)備以及一些在端和云中間這一側(cè)的企業(yè)機(jī)房設(shè)備等等。

經(jīng)過(guò)這些年的積累，我們已經(jīng)積累出了一個(gè)相對(duì)來(lái)說(shuō)全覆蓋的邊緣計(jì)算網(wǎng)絡(luò)，無(wú)論它的節(jié)點(diǎn)位置，還是節(jié)點(diǎn)能力都是非常豐富的。

既然我們?cè)谥虚g層和底層資源做了很多工作，在上層我們是希望將來(lái)我們邊緣應(yīng)用開發(fā)能夠越來(lái)越方便。我們會(huì)向上發(fā)展去做 iPaaS 層的探索，把云原生帶到邊緣計(jì)算的場(chǎng)景里來(lái)。具體的話，是去做一些與行業(yè)標(biāo)準(zhǔn)接軌的邊緣服務(wù)治理，包括更好地容器化和編排，以及通過(guò) Sidecar 等多種方式封裝跨云邊端通信能力。我們希望通過(guò)邊緣云原生能力去降低邊緣計(jì)算應(yīng)用的全生命周期成本。相關(guān)的系統(tǒng)已經(jīng)開始支撐自有業(yè)務(wù)。將來(lái)，如果成熟的話，我們也希望能夠?qū)⑺_放出來(lái)，希望在不久的將來(lái)，我們能夠在這方面給大家?guī)?lái)更多的分享。

4、未來(lái)可期

基于我們對(duì)邊緣計(jì)算的探索和現(xiàn)在整個(gè)邊緣計(jì)算行業(yè)的發(fā)展，我們認(rèn)為接下來(lái)的這些場(chǎng)景可能會(huì)在短時(shí)間內(nèi)成為現(xiàn)實(shí)。

第一個(gè)場(chǎng)景是邊緣上的人工智能。邊緣 AI 也是現(xiàn)在邊緣落地很火的一個(gè)場(chǎng)景。前陣子，非常多的硬件廠商針對(duì)這樣的 AI 場(chǎng)景推出了很多邊緣計(jì)算盒子。從具體的場(chǎng)景來(lái)說(shuō)，一個(gè)是邊緣推斷，比如我們可以將一些復(fù)雜的算法模型，比如之前提及的一些復(fù)雜的特效，如果我們可以在低延遲的邊緣上去運(yùn)行這樣的一些特效，其實(shí)就能夠把這些體驗(yàn)投射到終端上。

另一個(gè)是聯(lián)邦學(xué)習(xí)，我們通過(guò)在邊緣上去進(jìn)行數(shù)據(jù)的處理，來(lái)去確保原始數(shù)據(jù)既不被中心收集，去保護(hù)用戶隱私，又能夠很好地去完成學(xué)習(xí)的過(guò)程。所有的像這樣的一些場(chǎng)景，它都能很好地運(yùn)用邊緣計(jì)算的特點(diǎn)。這些場(chǎng)景落地所需要的工作如下：首先是解決服務(wù)治理的問(wèn)題，我們?cè)趺窗堰@些應(yīng)用，把這些算法去部署到邊緣上，去管理它；其次是數(shù)據(jù)的傳輸，云邊端之間如何很好地去傳輸源數(shù)據(jù)和結(jié)果數(shù)據(jù)，特別是在一些實(shí)時(shí)場(chǎng)景中，傳輸技術(shù)要求還是非常高的；最后是需要有對(duì)應(yīng)的算力，而且算力的成本也是要比較合理。

第二個(gè)場(chǎng)景是視頻處理。這是離我們非常近的，整個(gè)行業(yè)里已經(jīng)有很多這樣的落地應(yīng)用了，比如云端轉(zhuǎn)碼、云端視頻剪輯和實(shí)時(shí)特效。云端視頻剪輯很火，各大視頻平臺(tái)都有云剪輯的工具。實(shí)時(shí)特效其實(shí)是視頻處理和 AI 交界的東西。這塊需要的能力也主要是邊端需要有相應(yīng)的算力，例如轉(zhuǎn)碼的算力、針對(duì)視頻運(yùn)算需要的計(jì)算能力等。其次，也是傳輸，實(shí)時(shí)的超低延遲的視頻傳輸現(xiàn)在也是非?；鸬囊粋€(gè)賽道，RTC 技術(shù)發(fā)展的也非?？臁?/p>

第三個(gè)場(chǎng)景是實(shí)時(shí)演算，比如云渲染、現(xiàn)在大家都看到的云游戲和未來(lái)的元宇宙。元宇宙，我們可以把它理解成一個(gè)大號(hào)版的游戲。元宇宙里有更加復(fù)雜的場(chǎng)景、模型，甚至說(shuō)需要大量的 AI 處理。這對(duì)運(yùn)算顯然提出了更高的要求，同時(shí)，只要了解過(guò) VR 的都知道，我們需要一個(gè)比較好的 VR 體驗(yàn)效果，延遲需要降低到一定的水平。顯然，邊緣計(jì)算在這一塊是不可或缺的，所以行業(yè)也普遍認(rèn)為元宇宙將來(lái)的技術(shù)底座就是邊緣計(jì)算。我們和做邊緣 CDN 一樣，我們也會(huì)結(jié)合自身的優(yōu)勢(shì)去深耕這樣的場(chǎng)景，并且將這些能力進(jìn)一步沉淀到底層平臺(tái)，去更好地服務(wù)我們整個(gè)行業(yè)。

最后，我們來(lái)總結(jié)一下。當(dāng)我們的泛在算力類似于水電是隨時(shí)可獲取的，那就沒(méi)有一個(gè) T 的算力解決不了的問(wèn)題，如果有，那就兩個(gè) T。

我今天的分享就到這里，謝謝！