Matt Conran 陳琳華

CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）屬于邊緣應(yīng)用程序，后者則是CDN服務(wù)的一個(gè)超集。

我們正生活在一個(gè)超級(jí)連接的世界當(dāng)中，所有的東西都可以被推至云端。將內(nèi)容放在一個(gè)地方，站在管理層的角度這種想法可能是有用的，但是現(xiàn)在可以說(shuō)是多余的。如今用戶和數(shù)據(jù)已經(jīng)變得無(wú)處不在。

這種發(fā)展趨勢(shì)正使得客戶的期望值不斷飆升。人們對(duì)高質(zhì)量服務(wù)的期望值越來(lái)越高，與此同時(shí)客戶的耐心也正變得越來(lái)越低。過(guò)去，人們可以耐心地等待10個(gè)小時(shí)來(lái)下載內(nèi)容，但是現(xiàn)在這顯然是不可能的事情。如今雖然我們都有著很高的期望值并且對(duì)性能也有著很高的要求，然而在另一方面顧慮也是存在的?；ヂ?lián)網(wǎng)是一個(gè)很神奇的地方，它們有著不可預(yù)測(cè)的非對(duì)稱模式、緩沖膨脹以及一系列與性能相關(guān)的問(wèn)題。

此外，互聯(lián)網(wǎng)正在以越來(lái)越快的速度不斷增長(zhǎng)。到2020年，在互聯(lián)網(wǎng)上每人每天的流量預(yù)計(jì)將達(dá)到1.5吉字節(jié)。未來(lái)，由物聯(lián)網(wǎng)生成的數(shù)據(jù)將遠(yuǎn)遠(yuǎn)超過(guò)這一數(shù)據(jù)量。例如，實(shí)現(xiàn)連網(wǎng)的飛機(jī)每天可產(chǎn)生大約5太字節(jié)的數(shù)據(jù)。這種呈螺旋式增長(zhǎng)的數(shù)據(jù)量需要一種新的數(shù)據(jù)管理方法，迫使我們重新思考交付應(yīng)用程序的方式。

為什么呢？因?yàn)樗羞@些信息都無(wú)法由單個(gè)云或內(nèi)部數(shù)據(jù)中心處理。延遲始終是個(gè)問(wèn)題。例如，在虛擬現(xiàn)實(shí)（VR）中，延遲超過(guò)7毫秒就會(huì)引起暈動(dòng)病。當(dāng)需要實(shí)時(shí)做出決策時(shí)，我們會(huì)面臨無(wú)法將數(shù)據(jù)發(fā)送到云端的問(wèn)題。不過(guò)不要緊，我們可以使用邊緣計(jì)算和多CDN設(shè)計(jì)來(lái)解決這一問(wèn)題。

引入邊緣計(jì)算和多CDN設(shè)計(jì)

云部署、全物視頻（all-things-video）、物聯(lián)網(wǎng)和邊緣計(jì)算正在為CDN和多CDN設(shè)計(jì)帶來(lái)契機(jī)。通常，多CDN為一種包含了多個(gè)CDN提供商的實(shí)現(xiàn)模式。利用不同的計(jì)量指標(biāo)可實(shí)現(xiàn)流量定向，從而實(shí)現(xiàn)流量負(fù)載在不同提供商之間平衡或進(jìn)行失效備援。

邊緣計(jì)算將操作盡可能地移動(dòng)到了源頭。這是物理世界與數(shù)字世界互動(dòng)的關(guān)鍵所在。從邏輯上講，邊緣計(jì)算的去中心化方法不會(huì)替代集中化方法。它們之間的關(guān)系是相互補(bǔ)充的關(guān)系，應(yīng)用程序可以根據(jù)它們?cè)诰W(wǎng)絡(luò)中的位置以最佳方式運(yùn)行。

例如，在物聯(lián)網(wǎng)中，節(jié)省電池壽命至關(guān)重要。假設(shè)一個(gè)物聯(lián)網(wǎng)設(shè)備以10ms往返時(shí)延（RTT）處理事務(wù)，而不是100ms RTT，那么它們的電池壽命便可延長(zhǎng)10倍。

互聯(lián)網(wǎng)是性能瓶頸

互聯(lián)網(wǎng)的設(shè)計(jì)原則是每個(gè)人都可以與其他任何人進(jìn)行對(duì)話，因此它們提供的是通用連接，無(wú)論是否需要。雖然網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）會(huì)帶來(lái)一些設(shè)計(jì)變化，但是無(wú)論在哪里，互聯(lián)網(wǎng)的角色在連接方面基本保持不變。

使用這種類型的連接模型，距離是應(yīng)用程序性能的重要決定因素。無(wú)論緩沖區(qū)有多大或怎么優(yōu)化設(shè)備性能，地球另一側(cè)的用戶都會(huì)受到影響。由于數(shù)據(jù)包在實(shí)際數(shù)據(jù)傳輸之前會(huì)來(lái)回傳遞，因此需要經(jīng)歷較長(zhǎng)的RTT。盡管采取了緩存和流量重新定向技術(shù)，但是到目前為止取得的成功只是有限的。

應(yīng)用程序交付原則

傳輸控制協(xié)議（TCP）的啟用時(shí)間可以追溯到20世紀(jì)70年代后期。背景是假設(shè)所有服務(wù)都在局域網(wǎng)（LAN）上并且沒有丟包現(xiàn)象。在它們被設(shè)計(jì)時(shí)，還沒有出現(xiàn)實(shí)時(shí)流量，例如對(duì)延遲和抖動(dòng)非常敏感的語(yǔ)音和視頻。

TCP的設(shè)計(jì)初衷是為了易用性和可靠性，而不是為了提高性能。用戶實(shí)際上需要優(yōu)化TCP堆棧。這就是CDN非常擅長(zhǎng)執(zhí)行此類任務(wù)的原因。例如，如果收到了一個(gè)來(lái)自移動(dòng)電話的連接，那么CDN在一開始就會(huì)假設(shè)存在高抖動(dòng)和丟包的情況。這使得它們能夠正確地調(diào)整TCP窗口大小，以準(zhǔn)確地匹配網(wǎng)絡(luò)條件。

那么我們應(yīng)當(dāng)如何提升它們的性能，選擇哪些選項(xiàng)設(shè)置呢？在一般情況下，許多人都希望能夠降低延遲。但是對(duì)于視頻流等應(yīng)用程序，我們無(wú)法知道延遲是否是視頻緩沖造成的。人們只能假設(shè)較少的緩沖可以緩解延遲現(xiàn)象。在這種情況下，基于吞吐量的測(cè)量遠(yuǎn)比更高的性能指標(biāo)要合理，因?yàn)樗鼈兡軌蚋嬖V我們對(duì)象的加載速度。

我們還要考慮頁(yè)面加載時(shí)間。在網(wǎng)絡(luò)層中，人們開發(fā)出了首字節(jié)時(shí)間（TTFB）和ping。但是由于所有東西都被打在一個(gè)數(shù)據(jù)包里，因此這些機(jī)制并沒有多好的用戶體驗(yàn)。ping也不會(huì)顯示帶寬問(wèn)題。

如果一旦數(shù)據(jù)包丟包率超過(guò)5%，并且用戶正在測(cè)算TTFB（即第4個(gè)數(shù)據(jù)包）那么網(wǎng)頁(yè)速度將會(huì)下降25%。TTFB與堆棧上一層的互聯(lián)網(wǎng)控制消息協(xié)議（ICMP）請(qǐng)求相當(dāng)。如果有什么東西壞了，反而好處理，如果出現(xiàn)了影響性能的問(wèn)題就不那么好辦了。

在檢查TTFB測(cè)算記錄時(shí)，用戶會(huì)發(fā)現(xiàn)它們之所以被部署的原因是當(dāng)時(shí)缺乏真實(shí)用戶監(jiān)控（RUM）。以前，TTFB在估算某物的加載速度方面的表現(xiàn)還是不錯(cuò)的，但是有了RUM之后我們就不再需要估算了。RUM是來(lái)自最終用戶的測(cè)量值。提供給實(shí)際用戶的網(wǎng)頁(yè)所生成的指標(biāo)可以作為范例。

總的來(lái)看，TTFB、ping和頁(yè)面加載時(shí)間并不是非常精準(zhǔn)的測(cè)算方式。我們應(yīng)該盡可能地選擇使用RUM，因?yàn)樗鼈兛梢蕴峁└鼮闇?zhǔn)確的用戶體驗(yàn)。這是在過(guò)去十年中最為重要的事情。

現(xiàn)在我們生活在一個(gè)RUM世界當(dāng)中，這讓我們可以根據(jù)業(yè)務(wù)用戶的重要性來(lái)構(gòu)建網(wǎng)絡(luò)。所有CDN都應(yīng)當(dāng)針對(duì)RUM測(cè)量。為此，它們可能需要與流量管理系統(tǒng)整合在一起，以智能地衡量最終用戶真正看到的內(nèi)容。

對(duì)多CDN的需求

首先，選擇多CDN環(huán)境的原因是可用性和性能。對(duì)于全球任何人和任何一個(gè)地方來(lái)說(shuō)，沒有任何一個(gè)CDN可以成為速度最快的CDN。從互聯(lián)網(wǎng)的連接模式看，這也是不可能的。但是將兩個(gè)甚至更多的優(yōu)秀CDN服務(wù)商組合在一起是可以提高性能的。

與單個(gè)CDN相比，多CDN可提供更好的性能和更高的可用性。一個(gè)好的設(shè)計(jì)可以運(yùn)行兩個(gè)可用區(qū)域。更好的設(shè)計(jì)是使用單個(gè)CDN提供程序運(yùn)行兩個(gè)可用區(qū)。 但是更優(yōu)秀的設(shè)計(jì)是在多CDN環(huán)境中運(yùn)行兩個(gè)可用區(qū)域。

邊緣應(yīng)用程序?qū)⒊蔀樾鲁B(tài)

不久之前，大型物理單片架構(gòu)開始向敏捷云過(guò)渡。但是真正發(fā)生變化的是從物理設(shè)備向基于虛擬云的設(shè)備過(guò)渡。也許現(xiàn)在是時(shí)候捫心自問(wèn)一下，這就是我們真正想要的未來(lái)嗎？

引入邊緣應(yīng)用程序的一個(gè)主要問(wèn)題是心態(tài)。要讓自己或同行相信，在基礎(chǔ)設(shè)施上花費(fèi)時(shí)間和投資并不是業(yè)務(wù)的最佳推進(jìn)方式，這很困難。

盡管云服務(wù)的發(fā)展已經(jīng)引起了巨大反響，但是僅僅遷移到云端并不意味著應(yīng)用程序會(huì)運(yùn)行得更快。實(shí)際上，云所做的只是將架構(gòu)的物理部分抽象出來(lái)并付費(fèi)讓他人進(jìn)行管理。然而，云服務(wù)的推出為邊緣應(yīng)用程序帶來(lái)了機(jī)遇。我們已經(jīng)邁出了邁向云端的第一步，現(xiàn)在是時(shí)候邁出第二步了。

基本上，我們可以將邊緣應(yīng)用程序認(rèn)為是一種可編程的CDN。CDN屬于邊緣應(yīng)用程序，后者則是CDN服務(wù)的一個(gè)超集。邊緣應(yīng)用程序指位于邊緣的云計(jì)算。其將應(yīng)用程序部署的更靠近源，以實(shí)現(xiàn)更低的延遲、額外的彈性和簡(jiǎn)化的基礎(chǔ)設(shè)施，不過(guò)用戶仍然可以擁有控制權(quán)和隱私權(quán)。

從架構(gòu)的角度來(lái)看，邊緣應(yīng)用程序比集中化部署的應(yīng)用程序更具彈性。在當(dāng)今的高期望值世界中，彈性是業(yè)務(wù)連續(xù)性的必要條件。邊緣應(yīng)用程序允許用戶將基礎(chǔ)設(shè)施拆分為更加便宜、更為簡(jiǎn)單且更注重應(yīng)用程序的架構(gòu)?；A(chǔ)設(shè)施規(guī)模越小，用戶就越有時(shí)間專注于對(duì)業(yè)務(wù)至關(guān)重要的事情，即客戶身上。

邊緣架構(gòu)的范例

邊緣架結(jié)構(gòu)的一個(gè)范例是在每個(gè)PoP中每個(gè)應(yīng)用程序都有自己獨(dú)立的JavaScript（JS）環(huán)境。JavaScript非常適合安全隔離和以提升性能為目的的擴(kuò)展。此外，JavaScript還是一個(gè)專用的隔離實(shí)例，允許在邊緣執(zhí)行代碼。

每個(gè)JavaScript都可以有自己的虛擬機(jī)（VM）。VM執(zhí)行的獨(dú)立操作是JavaScript運(yùn)行時(shí)引擎，其只運(yùn)行客戶的代碼。用戶還可以選擇使用谷歌V8開源高性能JavaScript和WebAssembly引擎。

盡管如此，我們需要面對(duì)一個(gè)現(xiàn)實(shí)，那就是如果持續(xù)建造大量的PoP將會(huì)出現(xiàn)收益遞減的情況。如果涉及到諸如移動(dòng)設(shè)備之類的應(yīng)用程序時(shí)，采用以PoP為主體的解決方案會(huì)導(dǎo)致失敗。所以我們需要找到其他的解決方案。

在即將到來(lái)的時(shí)代里，我們將會(huì)看到一個(gè)大多數(shù)應(yīng)用程序開始向全球性應(yīng)用程序轉(zhuǎn)變的趨勢(shì)，這意味著邊緣應(yīng)用程序的崛起。無(wú)論用戶處于什么位置，將所有應(yīng)用程序放在某個(gè)地方必然會(huì)變得沒有意義。

本文作者M(jìn)att Conran擁有超過(guò)19年的網(wǎng)絡(luò)行業(yè)從業(yè)經(jīng)驗(yàn)，曾經(jīng)服務(wù)于多個(gè)初創(chuàng)企業(yè)和政府機(jī)構(gòu)。此外，他還作為高級(jí)架構(gòu)師參與了全球某大型服務(wù)提供商和數(shù)據(jù)中心網(wǎng)絡(luò)的建設(shè)工作。

原文網(wǎng)址

https：//www.networkworld.com/article/3409027/how-edge-computing-is-driving-a-new-era-of-cdn.html