面向互聯(lián)網(wǎng)應(yīng)用的網(wǎng)絡(luò)優(yōu)化
關(guān)于Web 應(yīng)用的性能、可靠性和可伸縮性，最大的瓶頸在哪里？在許多情況下，限制性的瓶頸是網(wǎng)絡(luò)傳輸，或者說是數(shù)據(jù)在互聯(lián)網(wǎng)上往返于服務(wù)器和終端用戶之間的時間。
如今，設(shè)計網(wǎng)絡(luò)應(yīng)用時，服務(wù)端的基礎(chǔ)設(shè)施往往最受關(guān)注，這也是容易受架構(gòu)師控制的部分?；A(chǔ)設(shè)施的良好性能和可靠性現(xiàn)在是一個相對容易理解和處理的問題。然而，從最終用戶的角度來看，為了實現(xiàn)強大的應(yīng)用性能和可靠性，服務(wù)端的基礎(chǔ)設(shè)施只是個必要不充分條件。
難以駕馭和經(jīng)常被忽視的是，互聯(lián)網(wǎng)“中間網(wǎng)絡(luò)”的模糊將延遲瓶頸、吞吐量約束和可靠性問題注入到 Web 應(yīng)用的性能公式中。實際上，“中間網(wǎng)絡(luò)”這個詞本身就是模糊的，因為它指的是由許多競爭實體擁有的、通?？缭綌?shù)百或數(shù)千公里的異構(gòu)基礎(chǔ)設(shè)施。
在服務(wù)器與用戶中間的網(wǎng)絡(luò)問題
雖然我們把互聯(lián)網(wǎng)稱為一個單一的實體，但它實際上是由數(shù)萬個不同的互相競爭的網(wǎng)絡(luò)組成的，每個網(wǎng)絡(luò)都提供一些最終用戶的子集訪問。隨著市場需求的增長，承載服務(wù)器的IDC和用戶的接入網(wǎng)絡(luò)都有了極大的提升，互聯(lián)網(wǎng)的容量也在不斷發(fā)展。
另一方面，那些由網(wǎng)絡(luò)流量交換的對等節(jié)點和中轉(zhuǎn)節(jié)點組成的互聯(lián)網(wǎng)“中間網(wǎng)絡(luò)”實際上是一片無人區(qū)。在這里，從經(jīng)濟上講，幾乎沒有動力去擴大產(chǎn)能。如果說有什么不同的話，那就是網(wǎng)絡(luò)希望盡量減少流入他們網(wǎng)絡(luò)的無償流量。因此，對等節(jié)點通常負(fù)載過重，導(dǎo)致數(shù)據(jù)包丟失和服務(wù)退化。對等節(jié)點經(jīng)濟模型的脆弱可能會帶來更嚴(yán)重的后果，其他的可靠性問題也困擾著它們?；ヂ?lián)網(wǎng)中斷的原因多種多樣，包括跨洋電纜中斷、斷電和DDOS。互聯(lián)網(wǎng)主要的網(wǎng)間路由算法協(xié)議是 BGP，它和物理網(wǎng)絡(luò)基礎(chǔ)設(shè)施一樣容易受到影響。
這些互聯(lián)網(wǎng)可靠性和對等節(jié)點問題的普遍存在意味著數(shù)據(jù)經(jīng)過中間網(wǎng)絡(luò)的時間越長，它就越容易受到擁塞、數(shù)據(jù)包丟失和性能差的影響。
規(guī)模問題
隨著對寬帶需求和可用性的增加，用戶對更快的網(wǎng)站、更豐富的媒體和高交互性應(yīng)用程序的期望也在上升。不斷增加的流量負(fù)載和性能要求反過來又給互聯(lián)網(wǎng)的“中間網(wǎng)絡(luò)”帶來了更大的壓力。
距離瓶頸
視頻和富媒體文件大小增長的一個有趣的副作用是，服務(wù)器和最終用戶之間的距離對最終用戶的性能至關(guān)重要。既然數(shù)據(jù)包可以以接近光速的速度穿越網(wǎng)絡(luò)，在網(wǎng)絡(luò)并不擁擠的時候，為什么一個“大文件”要花這么長時間才能穿越網(wǎng)絡(luò)到達用戶呢？
這歸因于底層網(wǎng)絡(luò)協(xié)議的工作方式，延遲和吞吐量是直接耦合的。例如，TCP 窗口一次只允許發(fā)送少量數(shù)據(jù) ，然后必須暫停并等待接收端的確認(rèn)。這意味著網(wǎng)絡(luò)往返時間(延遲)有效地抑制了吞吐量，這可能成為文件下載速度和視頻觀看質(zhì)量的瓶頸。
數(shù)據(jù)包丟失使問題進一步復(fù)雜化，因為如果檢測到數(shù)據(jù)包丟失，這些協(xié)議在等待確認(rèn)之前會退出并發(fā)送更少的數(shù)據(jù)。較長的距離增加了擁塞和數(shù)據(jù)包丟失的機會，從而進一步損害吞吐量。
內(nèi)容分發(fā)的主要方式
考慮到這些瓶頸和可伸縮性挑戰(zhàn)，如何實現(xiàn)通過互聯(lián)網(wǎng)有效交付內(nèi)容呢？以及如何提升應(yīng)用程序所需的性能和可靠性水平呢？內(nèi)容分發(fā)體系中主要有四種方法: 集中托管、CDN、分布式CDN 和 P2P (對等網(wǎng)絡(luò))網(wǎng)絡(luò)。
集中托管
傳統(tǒng)的Web 站點使用一個或少量的配置站點來承載內(nèi)容。商業(yè)站點通常至少有兩個地理上分散的鏡像站點，以提供額外的性能、可靠性和可伸縮性。
這種方法是一個良好的開端，對于迎合本地化用戶的小型網(wǎng)站來說，這可能已經(jīng)足夠了。然而，由于最終用戶體驗受不可靠的互聯(lián)網(wǎng)“中間網(wǎng)絡(luò)”的影響，其性能和可靠性一般會低于對商業(yè)級網(wǎng)站和應(yīng)用程序的預(yù)期。
另外， 站點鏡像復(fù)雜且成本高昂，管理也是如此。流量水平波動很大，因此需要為峰值流量提供更多的冗余資源，這意味著昂貴的基礎(chǔ)設(shè)施在大多數(shù)時候?qū)⒌貌坏匠浞掷?。而?zhǔn)確地預(yù)測流量需求是極其困難的，集中托管無法提供靈活性來處理突發(fā)的流量。
數(shù)據(jù)中心
通過將可緩存內(nèi)容從源服務(wù)器轉(zhuǎn)移到更大的共享網(wǎng)絡(luò)，內(nèi)容分發(fā)網(wǎng)絡(luò)提供了更好的可伸縮性。一種常見的 CDN被描述為“數(shù)據(jù)中心”，包括可能連接到骨干網(wǎng)的幾十個高容量數(shù)據(jù)中心緩存和分發(fā)的資源。
雖然這種方法比集中托管提供了一些性能優(yōu)勢和規(guī)模經(jīng)濟，但潛在的改進是有限的，因為 數(shù)據(jù)中心的服務(wù)器仍然遠離大多數(shù)用戶，仍然收到中間網(wǎng)絡(luò)的瓶頸影響。有了自己的骨干網(wǎng)仍不足以實現(xiàn)商業(yè)級的性能，這似乎有悖常理。事實上，即使是最大的網(wǎng)絡(luò)所控制的最終用戶也是有限的，互聯(lián)網(wǎng)的網(wǎng)絡(luò)上用戶是一個長尾分布。即使連接到主干網(wǎng)，數(shù)據(jù)也必須穿過“中間網(wǎng)絡(luò)”的泥沼才能到達互聯(lián)網(wǎng)的大多數(shù)用戶。
分布式CDN
另一種方法是利用一個高度分布式的網(wǎng)絡(luò)，一個有數(shù)千個網(wǎng)絡(luò)服務(wù)器的網(wǎng)絡(luò)，而不是幾十個。從表面上看，這可能看起來非常類似于“數(shù)據(jù)中心”的CDN。然而，在現(xiàn)實中，它是一種完全不同的內(nèi)容服務(wù)器部署方式，在分布程度上高出兩個數(shù)量級。例如，通過將服務(wù)器放在最終用戶的ISP中，一個高度分布的 CDN 消除了對等、連接、路由和距離問題，并減少了所依賴的互聯(lián)網(wǎng)組件數(shù)量。此外，這種架構(gòu)具有擴展性。
另一方面，部署高分布式 CDN 成本高、耗時長，并伴隨著一系列挑戰(zhàn)。從根本上說，必須從部署和管理的角度有效地設(shè)計網(wǎng)絡(luò)的規(guī)模，包括:
復(fù)雜的全局調(diào)度、映射和負(fù)載平衡算法
復(fù)雜的緩存管理協(xié)議，以確保高緩存命中率
分布式控制協(xié)議和可靠的自動監(jiān)測和報警系統(tǒng)
分布式內(nèi)容更新機制、數(shù)據(jù)完整性保證和管理系統(tǒng)
智能自動故障轉(zhuǎn)移和恢復(fù)方法
大規(guī)模數(shù)據(jù)聚合和分發(fā)技術(shù)
健壯的全局軟件部署機制
這些都是非常重要的挑戰(zhàn)，是CDN的核心技術(shù)。
P2P 網(wǎng)絡(luò)
由于高分布式體系結(jié)構(gòu)對于視頻分發(fā)中的可伸縮性和性能至關(guān)重要，因此考慮 P2P 體系結(jié)構(gòu)是很自然的。P2P 可以被認(rèn)為是將分布式體系結(jié)構(gòu)發(fā)揮到了邏輯極致，理論上提供了近乎無限的可伸縮性。此外，在當(dāng)前的網(wǎng)絡(luò)定價結(jié)構(gòu)下，P2P 提供了很有吸引力的經(jīng)濟性。
然而，在現(xiàn)實中，P2P 面臨著一些嚴(yán)重的限制，主要是因為 P2P 網(wǎng)絡(luò)的總下載容量受到其總上行容量的限制，對于用戶的寬帶連接，上行速度往往比下行速度低得多。
這意味著，在實時流媒體等情況下，上傳(對等點共享內(nèi)容)的數(shù)量受到下載(對等點請求內(nèi)容)數(shù)量的限制，平均下載吞吐量相當(dāng)于平均上行吞吐量，因此往往不能支持高質(zhì)量的Web流量。
使用一種混合方法可以獲得更好的結(jié)果，即利用 P2P 作為CDN的擴展，P2P 可以幫助降低在某些情況下的總體分發(fā)成本。然而，由于 P2P 網(wǎng)絡(luò)的容量有限，網(wǎng)絡(luò)中的非 P2P的體系結(jié)構(gòu)仍然決定著整體性能和可伸縮性。
這四種網(wǎng)絡(luò)體系結(jié)構(gòu)各有其優(yōu)缺點，為我們在考慮內(nèi)容分發(fā)的時候提供了方向。
CDN選擇中的技術(shù)因素
在網(wǎng)絡(luò)中的任何時候都會發(fā)生大量的組件或其他故障，互聯(lián)網(wǎng)系統(tǒng)出現(xiàn)了許多故障模式，例如機器故障、數(shù)據(jù)中心故障、連接故障、軟件故障和網(wǎng)絡(luò)故障等等，所有這些故障發(fā)生的頻率都比人們想象的要高。我們希望盡管發(fā)生了故障，網(wǎng)絡(luò)應(yīng)該還能夠繼續(xù)無縫地工作。
在我們的應(yīng)用系統(tǒng)中，需要選擇一個健壯的、高分布式CDN，這里從技術(shù)層面給出了幾點建設(shè)性的建議。
考察點1: 確保所有系統(tǒng)具有大量冗余，以方便故障轉(zhuǎn)移
擁有一個高度分布式的CDN可以帶來大量的冗余，如果一個組件出現(xiàn)故障，可以進行多種備份。然而，為了確保所有系統(tǒng)的健壯性，可能需要繞過現(xiàn)有協(xié)議的約束和與第三方軟件的交互，以及涉及成本的折衷，看看是否在每個級別都構(gòu)建了適當(dāng)?shù)墓收限D(zhuǎn)移機制。
考察點2: 使用軟件邏輯提供消息的可靠性
在數(shù)據(jù)中心之間建立專用的鏈接，還是使用公共互聯(lián)網(wǎng)在CDN網(wǎng)絡(luò)中分發(fā)數(shù)據(jù)么？包括控制信息、配置、監(jiān)控信息和客戶的內(nèi)容。是否使用了 UDP 的多路由和有限重傳，在不犧牲延遲的情況下實現(xiàn)可靠性。
考察點3: 使用分布式控制進行協(xié)調(diào)
主要是考量容錯和可伸縮性，主服務(wù)器的評估可以依賴于許多因素，包括機器狀態(tài)，與網(wǎng)絡(luò)中其他機器的連接，以及監(jiān)控能力。當(dāng)本地主服務(wù)器的連接性降低時，是否自動選擇一個新服務(wù)器來承擔(dān)主服務(wù)器的角色。
考察點4: 簡單失敗，優(yōu)雅重啟
網(wǎng)絡(luò)已經(jīng)被設(shè)計成能夠快速無縫地處理服務(wù)器故障，并從最后一個已知的良好狀態(tài)重新啟動它們。這降低了在潛在的損壞狀態(tài)下工作的風(fēng)險。如果給定的機器繼續(xù)需要重新啟動，只需將其置于“休眠”模式，以盡量減少對整個網(wǎng)絡(luò)的影響。
考察點5: 階段性軟件發(fā)布
CDN的供應(yīng)商是否分階段將網(wǎng)絡(luò)軟件發(fā)布到實時的網(wǎng)絡(luò)中，即先單臺部署，然后，在執(zhí)行適當(dāng)?shù)臋z查之后，進行單區(qū)域部署，然后可能部署到網(wǎng)絡(luò)的其他子集，最后全網(wǎng)部署。發(fā)布的性質(zhì)決定了每個階段持續(xù)的時間和數(shù)量。
考察點6: 主動檢查缺陷
隔離故障的能力，特別是在面向恢復(fù)的計算/系統(tǒng)中，也許是最具挑戰(zhàn)性的問題之一。如果有這樣一種情況，即對具有一組罕見配置參數(shù)的特定內(nèi)容的請求會引發(fā)潛在的 bug。僅僅自動讓受影響的服務(wù)器失效是不夠的，因為對這些內(nèi)容的請求將被定向到其他機器，從而擴大了故障域。是否有緩存算法將每組內(nèi)容限制在特定的服務(wù)器上呢？這些約束是否根據(jù)當(dāng)前對內(nèi)容的需求水平動態(tài)確定的，同時保證了網(wǎng)絡(luò)的安全。
考慮到CDN龐大的規(guī)模異構(gòu)的性質(zhì)以及地理、時區(qū)和語言的多樣性，大型的、高度分布的、基于 internet 的網(wǎng)絡(luò)可能很難維護。我們需要的是操作更少，成本更低，而且容易擴容的CDN 網(wǎng)絡(luò)。
應(yīng)用程序的網(wǎng)絡(luò)優(yōu)化
從歷史上看，CDN方案主要關(guān)注靜態(tài)內(nèi)容的卸載和交付，然而，隨著 Web 應(yīng)用變得越來越動態(tài)化、個性化和業(yè)務(wù)邏輯驅(qū)動，加速非內(nèi)容的處理能力對于提供強大的用戶體驗也變得同樣重要。
加速數(shù)據(jù)的往返是一個復(fù)雜的問題，但是通過使用高分布式的基礎(chǔ)結(jié)構(gòu)，許多優(yōu)化都是可能的。
1: 減少傳輸層開銷
TCP 協(xié)議有著巨大的開銷，數(shù)據(jù)在兩個通信方之間需要多次往返來建立連接，使用緩慢的初始數(shù)據(jù)交換速率，并從數(shù)據(jù)包丟失中緩慢恢復(fù)。相比之下，使用持久連接并優(yōu)化參數(shù)以提高效率的網(wǎng)絡(luò)可以通過減少傳送同一組數(shù)據(jù)所需的往返次數(shù)來顯著提高性能。
2: 尋找更好的路由
除了減少往返所需的時間外，我們還希望減少每次往返所需的時間，確切地說，每次通過互聯(lián)網(wǎng)的時候數(shù)據(jù)往返所需的時間。乍一看，這似乎是不可能的。所有的互聯(lián)網(wǎng)數(shù)據(jù)必須由BGP路由，并且必須通過許多自治網(wǎng)絡(luò)傳輸。
BGP 是簡單的和可擴展的，但不是非常有效或健壯。通過利用CDN，可以使用更快、更少擁堵的路由，可以將通信速度提高30%甚至更多，還可以通過在缺省路由中斷時尋找替代路由來實現(xiàn)更高的通信可靠性。
3: 內(nèi)容預(yù)取
我們可以在應(yīng)用程序?qū)訄?zhí)行許多其他操作，以提高最終用戶的 Web 應(yīng)用程序響應(yīng)能力。一種方式就是內(nèi)容預(yù)取: 當(dāng)邊緣服務(wù)器向終端用戶提供資源時，它也可以解析并緩存，在終端用戶的瀏覽器請求之前檢索所有預(yù)取的內(nèi)容。
這種優(yōu)化的有效性依賴于在最終用戶附近有服務(wù)器，這樣用戶就可以感知到應(yīng)用程序響應(yīng)的級別類似于直接從附近服務(wù)器發(fā)出的，盡管事實上，一些預(yù)取的內(nèi)容是通過長途跋涉從源服務(wù)器獲取的。另外，請注意，與鏈接預(yù)取不同，內(nèi)容預(yù)取不會消耗額外的帶寬資源，也不會請求與終端用戶請求無關(guān)的對象。在這些情況下，預(yù)取對于 Web 應(yīng)用程序的用戶感知響應(yīng)能力有著巨大的影響。
4: 邊緣組裝
在邊緣服務(wù)器上緩存頁面片段，并在邊緣節(jié)點動態(tài)地組裝它們，以響應(yīng)最終用戶的請求。頁面可以是個性化數(shù)據(jù)，包括最終用戶的位置，連接速度，cookie 值等。在邊緣組裝頁面不僅可以為源服務(wù)器減壓，而且可以避免中間的延遲，從而降低最終用戶的響應(yīng)時間。
5: 使用壓縮和增量編碼
對基于文本的組件進行壓縮可以將內(nèi)容減少到原來大小的十分之一。使用增量編碼，即服務(wù)器只發(fā)送緩存頁面和動態(tài)生成頁面之間的差異，也可以大大減少必須在互聯(lián)網(wǎng)上傳輸?shù)膬?nèi)容量。
通過使用一個CDN來控制“中間網(wǎng)絡(luò)”的兩個端點，無論使用哪種瀏覽器，壓縮和增量編碼都可以成功使用。在這種情況下，性能得到了提高，因為只有很少的數(shù)據(jù)傳輸?shù)街虚g網(wǎng)絡(luò)。然后，邊緣服務(wù)器解壓縮內(nèi)容，并將完整、正確的內(nèi)容交付給最終用戶。
6: 邊緣計算
將應(yīng)用程序分發(fā)到邊緣服務(wù)器提供了應(yīng)用程序性能和可伸縮性的極限。與邊緣頁面組裝一樣，邊緣計算支持完整的源服務(wù)器加載，從而為終端用戶帶來巨大的可伸縮性和極低的應(yīng)用程序延遲。
雖然并非每種類型的應(yīng)用程序都適合于邊緣計算，但是大量流行的應(yīng)用(如產(chǎn)品目錄、存儲、產(chǎn)品配置、游戲等)都非常適合邊緣計算。
綜合使用
其中許多優(yōu)化技術(shù)都需要依賴高分布式CDN網(wǎng)絡(luò)。路由優(yōu)化依賴于一個龐大的覆蓋層網(wǎng)絡(luò)的可用性，該覆蓋層網(wǎng)絡(luò)包括了許多不同網(wǎng)絡(luò)上的機器。如果交付服務(wù)器靠近最終用戶，則內(nèi)容預(yù)取和頁面動態(tài)組裝的優(yōu)化方法將最為有效。最后，許多傳輸層和應(yīng)用層優(yōu)化需要在網(wǎng)絡(luò)中使用雙節(jié)點連接。為了最大化這個優(yōu)化連接的效果，端點應(yīng)該盡可能接近源服務(wù)器和最終用戶。
這些優(yōu)化是協(xié)同工作的，TCP 開銷在很大程度上是在未知網(wǎng)絡(luò)條件下保證可靠性的結(jié)果。因為路由優(yōu)化給我們提供了高性能、無擁塞的路徑，它允許采用更積極、更有效的方法來優(yōu)化傳輸層。
結(jié)束語
盡管、互聯(lián)網(wǎng)在不確定性和有用性方面的巨大進步，但是帶寬密集型的網(wǎng)絡(luò)內(nèi)容、富媒體以及基于 Web 和 ip 的應(yīng)用在跳躍式增長。這種增長帶來的挑戰(zhàn)有很多: 隨著企業(yè)將更多的關(guān)鍵功能轉(zhuǎn)移到網(wǎng)上，消費者娛樂(游戲、電影、體育)已經(jīng)轉(zhuǎn)移到了互聯(lián)網(wǎng)，互聯(lián)網(wǎng)“中間網(wǎng)絡(luò)“的壓力將變得越來越明顯，越來越有害。因此，使互聯(lián)網(wǎng)能夠滿足用戶的需求，面向應(yīng)用系統(tǒng)的網(wǎng)絡(luò)優(yōu)化是必須的。
【關(guān)聯(lián)閱讀】