我們正生活在一個超級連接的世界當中，所有的東西都可以被推至云端。將內容放在一個地方，站在管理層的角度這種想法可能是有用的，但是現(xiàn)在可以說是多余的。如今用戶和數(shù)據(jù)已經變得無處不在。
這種發(fā)展趨勢正使得客戶的期望值不斷飆升。人們對高質量服務的期望值越來越高，與此同時客戶的耐心也正變得越來越低。過去，人們可以耐心地等待10個小時來下載內容，但是現(xiàn)在這顯然是不可能的事情。如今雖然我們都有著很高的期望值并且對性能也有著很高的要求，然而在另一方面顧慮也是存在的?；ヂ?lián)網是一個很神奇的地方，它們有著不可預測的非對稱模式、緩沖膨脹以及一系列與性能相關的問題。
此外，互聯(lián)網正在以越來越快的速度不斷增長。到2020年，在互聯(lián)網上每人每天的流量預計將達到1.5GB。未來，由物聯(lián)網生成的數(shù)據(jù)將遠遠超過這一數(shù)據(jù)量。例如，實現(xiàn)連網的飛機每天可產生大約5TB的數(shù)據(jù)。這種呈螺旋式增長的數(shù)據(jù)量需要一種新的數(shù)據(jù)管理方法，迫使我們重新思考交付應用程序的方式。
為什么呢？因為所有這些信息都無法由單個云或內部數(shù)據(jù)中心處理。延遲始終是個問題。例如，在虛擬現(xiàn)實（VR）中，延遲超過7毫秒就會引起暈動病。當需要實時做出決策時，我們會面臨無法將數(shù)據(jù)發(fā)送到云端的問題。不過不要緊，我們可以使用邊緣計算和多CDN設計來解決這一問題。
引入邊緣計算和多CDN設計
云部署、全物視頻（all-things-video）、物聯(lián)網和邊緣計算正在為CDN和多CDN設計帶來契機。通常，多CDN為一種包含了多個CDN提供商的實現(xiàn)模式。利用不同的計量指標可實現(xiàn)流量定向，從而實現(xiàn)流量負載在不同提供商之間平衡或進行失效備援。
邊緣計算將操作盡可能地移動到了源頭。這是物理世界與數(shù)字世界互動的關鍵所在。從邏輯上講，邊緣計算的去中心化方法不會替代集中化方法。它們之間的關系是相互補充的關系，應用程序可以根據(jù)它們在網絡中的位置以最佳方式運行。
例如，在物聯(lián)網中，節(jié)省電池壽命至關重要。假設一個物聯(lián)網設備以10ms往返時延（RTT）處理事務，而不是100ms RTT，那么它們的電池壽命便可延長10倍。
互聯(lián)網是性能瓶頸
互聯(lián)網的設計原則是每個人都可以與其他任何人進行對話，因此它們提供的是通用連接，無論是否需要。雖然網絡地址轉換（NAT）會帶來一些設計變化，但是無論在哪里，互聯(lián)網的角色在連接方面基本保持不變。
使用這種類型的連接模型，距離是應用程序性能的重要決定因素。無論緩沖區(qū)有多大或怎么優(yōu)化設備性能，地球另一側的用戶都會受到影響。由于數(shù)據(jù)包在實際數(shù)據(jù)傳輸之前會來回傳遞，因此需要經歷較長的RTT。盡管采取了緩存和流量重新定向技術，但是到目前為止取得的成功只是有限的。
應用程序交付原則
傳輸控制協(xié)議（TCP）的啟用時間可以追溯到20世紀70年代后期。背景是假設所有服務都在局域網（LAN）上并且沒有丟包現(xiàn)象。在它們被設計時，還沒有出現(xiàn)實時流量，例如對延遲和抖動非常敏感的語音和視頻。
TCP的設計初衷是為了易用性和可靠性，而不是為了提高性能。用戶實際上需要優(yōu)化TCP堆棧。這就是CDN非常擅長執(zhí)行此類任務的原因。例如，如果收到了一個來自移動電話的連接，那么CDN在一開始就會假設存在高抖動和丟包的情況。這使得它們能夠正確地調整TCP窗口大小，以準確地匹配網絡條件。
那么我們應當如何提升它們的性能，選擇哪些選項設置呢？在一般情況下，許多人都希望能夠降低延遲。但是對于視頻流等應用程序，我們無法知道延遲是否是視頻緩沖造成的。人們只能假設較少的緩沖可以緩解延遲現(xiàn)象。在這種情況下，基于吞吐量的測量遠比更高的性能指標要合理，因為它們能夠告訴我們對象的加載速度。
我們還要考慮頁面加載時間。在網絡層中，人們開發(fā)出了首字節(jié)時間（TTFB）和ping。但是由于所有東西都被打在一個數(shù)據(jù)包里，因此這些機制并沒有多好的用戶體驗。ping也不會顯示帶寬問題。
如果一旦數(shù)據(jù)包丟包率超過5％，并且用戶正在測算TTFB（即第4個數(shù)據(jù)包）那么網頁速度將會下降25％。TTFB與堆棧上一層的互聯(lián)網控制消息協(xié)議（ICMP）請求相當。如果有什么東西壞了，反而好處理，如果出現(xiàn)了影響性能的問題就不那么好辦了。
在檢查TTFB測算記錄時，用戶會發(fā)現(xiàn)它們之所以被部署的原因是當時缺乏真實用戶監(jiān)控（RUM）。以前，TTFB在估算某物的加載速度方面的表現(xiàn)還是不錯的，但是有了RUM之后我們就不再需要估算了。RUM是來自最終用戶的測量值。提供給實際用戶的網頁所生成的指標可以作為范例。
總的來看，TTFB、ping和頁面加載時間并不是非常精準的測算方式。我們應該盡可能地選擇使用RUM，因為它們可以提供更為準確的用戶體驗。這是在過去十年中最為重要的事情。
現(xiàn)在我們生活在一個RUM世界當中，這讓我們可以根據(jù)業(yè)務用戶的重要性來構建網絡。所有CDN都應當針對RUM測量。為此，它們可能需要與流量管理系統(tǒng)整合在一起，以智能地衡量最終用戶真正看到的內容。
對多CDN的需求
首先，選擇多CDN環(huán)境的原因是可用性和性能。對于全球任何人和任何一個地方來說，沒有任何一個CDN可以成為速度最快的CDN。從互聯(lián)網的連接模式看，這也是不可能的。但是將兩個甚至更多的優(yōu)秀CDN服務商組合在一起是可以提高性能的。
與單個CDN相比，多CDN可提供更好的性能和更高的可用性。一個好的設計可以運行兩個可用區(qū)域。更好的設計是使用單個CDN提供程序運行兩個可用區(qū)。 但是更優(yōu)秀的設計是在多CDN環(huán)境中運行兩個可用區(qū)域。
邊緣應用程序將成為新常態(tài)
不久之前，大型物理單片架構開始向敏捷云過渡。但是真正發(fā)生變化的是從物理設備向基于虛擬云的設備過渡。也許現(xiàn)在是時候捫心自問一下，這就是我們真正想要的未來嗎？
引入邊緣應用程序的一個主要問題是心態(tài)。要讓自己或同行相信，在基礎設施上花費時間和投資并不是業(yè)務的最佳推進方式，這很困難。
盡管云服務的發(fā)展已經引起了巨大反響，但是僅僅遷移到云端并不意味著應用程序會運行得更快。實際上，云所做的只是將架構的物理部分抽象出來并付費讓他人進行管理。然而，云服務的推出為邊緣應用程序帶來了機遇。我們已經邁出了邁向云端的第一步，現(xiàn)在是時候邁出第二步了。
基本上，我們可以將邊緣應用程序認為是一種可編程的CDN。CDN屬于邊緣應用程序，后者則是CDN服務的一個超集。邊緣應用程序指位于邊緣的云計算。其將應用程序部署的更靠近源，以實現(xiàn)更低的延遲、額外的彈性和簡化的基礎設施，不過用戶仍然可以擁有控制權和隱私權。
從架構的角度來看，邊緣應用程序比集中化部署的應用程序更具彈性。在當今的高期望值世界中，彈性是業(yè)務連續(xù)性的必要條件。邊緣應用程序允許用戶將基礎設施拆分為更加便宜、更為簡單且更注重應用程序的架構。基礎設施規(guī)模越小，用戶就越有時間專注于對業(yè)務至關重要的事情，即客戶身上。
邊緣架構的范例
邊緣架結構的一個范例是在每個PoP中每個應用程序都有自己獨立的JavaScript（JS）環(huán)境。JavaScript非常適合安全隔離和以提升性能為目的的擴展。此外，JavaScript還是一個專用的隔離實例，允許在邊緣執(zhí)行代碼。
每個JavaScript都可以有自己的虛擬機（VM）。VM執(zhí)行的獨立操作是JavaScript運行時引擎，其只運行客戶的代碼。用戶還可以選擇使用谷歌V8開源高性能JavaScript和WebAssembly引擎。
盡管如此，我們需要面對一個現(xiàn)實，那就是如果持續(xù)建造大量的PoP將會出現(xiàn)收益遞減的情況。如果涉及到諸如移動設備之類的應用程序時，采用以PoP為主體的解決方案會導致失敗。所以我們需要找到其他的解決方案。
在即將到來的時代里，我們將會看到一個大多數(shù)應用程序開始向全球性應用程序轉變的趨勢，這意味著邊緣應用程序的崛起。無論用戶處于什么位置，將所有應用程序放在某個地方必然會變得沒有意義。
作者：Matt Conran擁有超過19年的網絡行業(yè)從業(yè)經驗，曾經服務于多個初創(chuàng)企業(yè)和政府機構。此外，他還作為高級架構師參與了全球某大型服務提供商和數(shù)據(jù)中心網絡的建設工作。
編譯：陳琳華
原文網址：https://www.networkworld.com/article/3409027/how-edge-computing-is-driving-a-new-era-of-cdn.html
