邊緣計算將推動CDN進入新時代

Matt Conran 陳琳華

CDN（內容分發網絡）屬于邊緣應用程序，后者則是CDN服務的一個超集。

我們正生活在一個超級連接的世界當中，所有的東西都可以被推至云端。將內容放在一個地方，站在管理層的角度這種想法可能是有用的，但是現在可以說是多余的。如今用戶和數據已經變得無處不在。

這種發展趨勢正使得客戶的期望值不斷飆升。人們對高質量服務的期望值越來越高，與此同時客戶的耐心也正變得越來越低。過去，人們可以耐心地等待10個小時來下載內容，但是現在這顯然是不可能的事情。如今雖然我們都有著很高的期望值并且對性能也有著很高的要求，然而在另一方面顧慮也是存在的。互聯網是一個很神奇的地方，它們有著不可預測的非對稱模式、緩沖膨脹以及一系列與性能相關的問題。

此外，互聯網正在以越來越快的速度不斷增長。到2020年，在互聯網上每人每天的流量預計將達到1.5吉字節。未來，由物聯網生成的數據將遠遠超過這一數據量。例如，實現連網的飛機每天可產生大約5太字節的數據。這種呈螺旋式增長的數據量需要一種新的數據管理方法，迫使我們重新思考交付應用程序的方式。

為什么呢？因為所有這些信息都無法由單個云或內部數據中心處理。延遲始終是個問題。例如，在虛擬現實（VR）中，延遲超過7毫秒就會引起暈動病。當需要實時做出決策時，我們會面臨無法將數據發送到云端的問題。不過不要緊，我們可以使用邊緣計算和多CDN設計來解決這一問題。

引入邊緣計算和多CDN設計

云部署、全物視頻（all-things-video）、物聯網和邊緣計算正在為CDN和多CDN設計帶來契機。通常，多CDN為一種包含了多個CDN提供商的實現模式。利用不同的計量指標可實現流量定向，從而實現流量負載在不同提供商之間平衡或進行失效備援。

邊緣計算將操作盡可能地移動到了源頭。這是物理世界與數字世界互動的關鍵所在。從邏輯上講，邊緣計算的去中心化方法不會替代集中化方法。它們之間的關系是相互補充的關系，應用程序可以根據它們在網絡中的位置以最佳方式運行。

例如，在物聯網中，節省電池壽命至關重要。假設一個物聯網設備以10ms往返時延（RTT）處理事務，而不是100ms RTT，那么它們的電池壽命便可延長10倍。

互聯網是性能瓶頸

互聯網的設計原則是每個人都可以與其他任何人進行對話，因此它們提供的是通用連接，無論是否需要。雖然網絡地址轉換（NAT）會帶來一些設計變化，但是無論在哪里，互聯網的角色在連接方面基本保持不變。

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

應用程序交付原則

傳輸控制協議（TCP）的啟用時間可以追溯到20世紀70年代后期。背景是假設所有服務都在局域網（LAN）上并且沒有丟包現象。在它們被設計時，還沒有出現實時流量，例如對延遲和抖動非常敏感的語音和視頻。

TCP的設計初衷是為了易用性和可靠性，而不是為了提高性能。用戶實際上需要優化TCP堆棧。這就是CDN非常擅長執行此類任務的原因。例如，如果收到了一個來自移動電話的連接，那么CDN在一開始就會假設存在高抖動和丟包的情況。這使得它們能夠正確地調整TCP窗口大小，以準確地匹配網絡條件。

那么我們應當如何提升它們的性能，選擇哪些選項設置呢？在一般情況下，許多人都希望能夠降低延遲。但是對于視頻流等應用程序，我們無法知道延遲是否是視頻緩沖造成的。人們只能假設較少的緩沖可以緩解延遲現象。在這種情況下，基于吞吐量的測量遠比更高的性能指標要合理，因為它們能夠告訴我們對象的加載速度。

我們還要考慮頁面加載時間。在網絡層中，人們開發出了首字節時間（TTFB）和ping。但是由于所有東西都被打在一個數據包里，因此這些機制并沒有多好的用戶體驗。ping也不會顯示帶寬問題。

如果一旦數據包丟包率超過5%，并且用戶正在測算TTFB（即第4個數據包）那么網頁速度將會下降25%。TTFB與堆棧上一層的互聯網控制消息協議（ICMP）請求相當。如果有什么東西壞了，反而好處理，如果出現了影響性能的問題就不那么好辦了。

在檢查TTFB測算記錄時，用戶會發現它們之所以被部署的原因是當時缺乏真實用戶監控（RUM）。以前，TTFB在估算某物的加載速度方面的表現還是不錯的，但是有了RUM之后我們就不再需要估算了。RUM是來自最終用戶的測量值。提供給實際用戶的網頁所生成的指標可以作為范例。

總的來看，TTFB、ping和頁面加載時間并不是非常精準的測算方式。我們應該盡可能地選擇使用RUM，因為它們可以提供更為準確的用戶體驗。這是在過去十年中最為重要的事情。

現在我們生活在一個RUM世界當中，這讓我們可以根據業務用戶的重要性來構建網絡。所有CDN都應當針對RUM測量。為此，它們可能需要與流量管理系統整合在一起，以智能地衡量最終用戶真正看到的內容。

對多CDN的需求

首先，選擇多CDN環境的原因是可用性和性能。對于全球任何人和任何一個地方來說，沒有任何一個CDN可以成為速度最快的CDN。從互聯網的連接模式看，這也是不可能的。但是將兩個甚至更多的優秀CDN服務商組合在一起是可以提高性能的。

與單個CDN相比，多CDN可提供更好的性能和更高的可用性。一個好的設計可以運行兩個可用區域。更好的設計是使用單個CDN提供程序運行兩個可用區。 但是更優秀的設計是在多CDN環境中運行兩個可用區域。

邊緣應用程序將成為新常態

不久之前，大型物理單片架構開始向敏捷云過渡。但是真正發生變化的是從物理設備向基于虛擬云的設備過渡。也許現在是時候捫心自問一下，這就是我們真正想要的未來嗎？

引入邊緣應用程序的一個主要問題是心態。要讓自己或同行相信，在基礎設施上花費時間和投資并不是業務的最佳推進方式，這很困難。

盡管云服務的發展已經引起了巨大反響，但是僅僅遷移到云端并不意味著應用程序會運行得更快。實際上，云所做的只是將架構的物理部分抽象出來并付費讓他人進行管理。然而，云服務的推出為邊緣應用程序帶來了機遇。我們已經邁出了邁向云端的第一步，現在是時候邁出第二步了。

基本上，我們可以將邊緣應用程序認為是一種可編程的CDN。CDN屬于邊緣應用程序，后者則是CDN服務的一個超集。邊緣應用程序指位于邊緣的云計算。其將應用程序部署的更靠近源，以實現更低的延遲、額外的彈性和簡化的基礎設施，不過用戶仍然可以擁有控制權和隱私權。

從架構的角度來看，邊緣應用程序比集中化部署的應用程序更具彈性。在當今的高期望值世界中，彈性是業務連續性的必要條件。邊緣應用程序允許用戶將基礎設施拆分為更加便宜、更為簡單且更注重應用程序的架構。基礎設施規模越小，用戶就越有時間專注于對業務至關重要的事情，即客戶身上。

邊緣架構的范例

邊緣架結構的一個范例是在每個PoP中每個應用程序都有自己獨立的JavaScript（JS）環境。JavaScript非常適合安全隔離和以提升性能為目的的擴展。此外，JavaScript還是一個專用的隔離實例，允許在邊緣執行代碼。

每個JavaScript都可以有自己的虛擬機（VM）。VM執行的獨立操作是JavaScript運行時引擎，其只運行客戶的代碼。用戶還可以選擇使用谷歌V8開源高性能JavaScript和WebAssembly引擎。

盡管如此，我們需要面對一個現實，那就是如果持續建造大量的PoP將會出現收益遞減的情況。如果涉及到諸如移動設備之類的應用程序時，采用以PoP為主體的解決方案會導致失敗。所以我們需要找到其他的解決方案。

在即將到來的時代里，我們將會看到一個大多數應用程序開始向全球性應用程序轉變的趨勢，這意味著邊緣應用程序的崛起。無論用戶處于什么位置，將所有應用程序放在某個地方必然會變得沒有意義。

本文作者Matt Conran擁有超過19年的網絡行業從業經驗，曾經服務于多個初創企業和政府機構。此外，他還作為高級架構師參與了全球某大型服務提供商和數據中心網絡的建設工作。

原文網址

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