如果說訪問量上升對網(wǎng)站性能有很大考驗，那突發(fā)事件，則是檢驗網(wǎng)站架構(gòu)的試金石。從某 L 和某 G 談戀愛，至某 W 和某 M 離婚，到某 F 和某 Z“官宣“事件，都導(dǎo)致某 SNS 網(wǎng)站宕機崩潰，無法為廣大網(wǎng)民提供正常服務(wù)。互聯(lián)網(wǎng)圈有一句比較有名謎之反問：
你的網(wǎng)站能承受幾個明星出軌？
由此可見，想做好一個網(wǎng)站，遠(yuǎn)遠(yuǎn)沒有看起來那么簡單。
無論你將 WEB 前端進(jìn)行何種方式的優(yōu)化，是頁面動靜分離？各種文件壓縮算法？還是將 Web Server 從老牌 Apache 換成性能之王 Nginx(以及其變種)？在絕對的訪問量面前，一切都變得脆弱無比，不堪一擊！更可怕的是，除了熱點爆料會導(dǎo)致海量、合法的用戶訪問請求，還有隱藏在暗處的黑客們源源不斷發(fā)起的各種 DDoS/HTTP Flood 攻擊，這些都會分分鐘讓你的網(wǎng)站瞬間癱瘓。無論是合法的，還是非法的，這些流量就像一支龐然大軍，具有摧枯拉朽的絕對實力。
因此，在互聯(lián)網(wǎng)+追求合作共贏的時代，熱門網(wǎng)站更加需要專業(yè)團(tuán)隊的安全保障。安全防護(hù)類產(chǎn)品可在網(wǎng)站前面砌起一座城墻，將流量大軍擋在城門之外，同時將被訪問網(wǎng)站的真實服務(wù)器隱藏起來，只接受少量、合法的流量的請求訪問。專業(yè)團(tuán)隊固然能夠提供 DDoS／CC／WAF 等各種防護(hù)手段來過濾異常流量，但這不是我們今天的主題，我們要說的，是在防護(hù)的同時對網(wǎng)站的優(yōu)化手段：CDN 緩存優(yōu)化。
首先讓我們來看一張 CDN 的整體架構(gòu)圖：
我們知道，對網(wǎng)站請求返回的文件，有動態(tài)文件和靜態(tài)文件兩類。所謂靜態(tài)文件，具有一個特點，有點類似數(shù)學(xué)中“冪等”的概念。請求靜態(tài)文件好比擲骰子，每次都能擲到六點。而請求動態(tài)文件，則不然，這次擲到六點，下次可能是五點，也可能是一點。所以，對于靜態(tài)文件，只要在 Web Server 上不更新，在響應(yīng)同樣的請求時（主要是 HTTP GET 請求），不管請求多少次，都會返回一樣的文件內(nèi)容。動態(tài)文件則反之，對于每個請求（HTTP GET／POST），都可能會返回不一樣的文件內(nèi)容。Web Server 返回的圖片，文檔，點播視頻，一般都是靜態(tài)文件，而像 html，php，jsp 文件，一般都是動態(tài)文件。
靜態(tài)文件都可以被 CDN 系統(tǒng)緩存下來，甚至某些動態(tài)文件，也可以在很短時間（比如 1 秒內(nèi)）將其看成是靜態(tài)的，從而緩存下來。一旦這些文件被緩存到 CDN 系統(tǒng)中，那流量大軍期望通過攻擊這些文件從而達(dá)到使網(wǎng)站宕機的目的，難度將大大提升，甚至毫無希望！
我們知道，CDN 系統(tǒng)是分布式的。就拿云防護(hù)來說，我們在全國各地都部署了緩存節(jié)點，每個節(jié)點都有同一份文件的拷貝，流量通過智能 DNS 系統(tǒng)調(diào)度，用戶會優(yōu)先訪問距離自己最近的緩存文件，從而得到想獲取的內(nèi)容。這樣，從全國各地發(fā)起集中涌現(xiàn)到源站的突增流量，就被分散到了各地的分布式節(jié)點上。在文件過期之前，Web Server 甚至不會感知到這些訪問請求。這就好比，靜態(tài)文件真身坐鎮(zhèn)大本營，各分身負(fù)責(zé)接待這些流量小分隊。當(dāng)分身能正常分發(fā)給訪客時，其真身可以高枕無憂。
但這并不是萬無一失的完美解決方案，我們還需要考慮到緩存文件會過期的可能性。這就好比，我們的真身在一段時間后（從幾分鐘到幾天不等），任期結(jié)束了，換了一位新的繼任者。此時，CDN 緩存節(jié)點需要重新向 Web Server 重新發(fā)起請求，獲取新文件，生成新的分身。另外，當(dāng)網(wǎng)站剛接入 CDN 緩存系統(tǒng)時，也是需要向 Web Server 發(fā)起請求拷貝文件的。此時此刻，如果有流量部隊剛好“造訪”，CDN 緩存節(jié)點沒法直接響應(yīng)，只能將流量導(dǎo)向 Web Server，在這短暫的瞬間，Web Server 中的真身會被暴露，其可能會被打垮！
如果緩存過期了，就真的無計可施了嗎？
當(dāng)然不是！
云防護(hù) CDN 系統(tǒng)早已考慮到了這種情況，并有至少三種解決對策：
（1）通過建立緩存父層將回源流量進(jìn)行收斂。
我們把 CDN 緩存節(jié)點向 Web Server 發(fā)起的請求稱為回源請求，將 Web Server 稱為源站。當(dāng)靜態(tài)文件過期時，緩存節(jié)點不直接回源，而是先請求上一級的緩存節(jié)點，由上一級的緩存節(jié)點回源。這是一個樹型結(jié)構(gòu)，父層節(jié)點在頂層。大量緩存節(jié)點在葉子處，它們訪問父層，再由少量的父層節(jié)點回源。通過這樣的層級收斂，將大量的緩存節(jié)點請求，轉(zhuǎn)化成少量的父節(jié)點回源請求，從而大大減小源站的壓力。
（2）緩存節(jié)點至父層合并回源。
大量的緩存節(jié)點向父層(或源站)發(fā)起請求時，也勢必會給父層節(jié)點造成很大的壓力。針對這種情況，云防護(hù)有自研的解決方案，可將同一個文件的大量并發(fā)請求，合并成一個或者少量請求返回給父層，從而使父層的請求數(shù)大大減少，緩解父層壓力。而這種技術(shù)，父緩存節(jié)點是無感知的。我們將這個技術(shù)稱之為“合并回源”。目前 Squid/Apache Traffic Server 等開源軟件，都采用了這種技術(shù)。
（3）條件回源。
當(dāng)緩存節(jié)點發(fā)現(xiàn)文件過期時，常規(guī)做法是重新下載整個文件，覆蓋舊文件。在文件體積比較小的情況下，這種方式問題不大；可一旦文件體積過大，大量的文件更新，對服務(wù)器也是一種考驗。此時，我們會啟用條件回源：當(dāng)緩存節(jié)點認(rèn)為緩存文件過期時，源站文件可能并未真正更新，只是到了例行的過期檢查時間點而已。此時，我們會在 HTTP 頭部攜帶特定的信息，來詢問源站是否真的更新了文件。事實經(jīng)驗告訴我們，在大部分情況下，源站文件并沒有真正更新。通過這種方法我們可以避免粗暴無用的重復(fù)下載整個文件。
這樣看來，在大部分情況下你都無需擔(dān)心了。但還有這樣一種情況可能發(fā)生，那就是 Web Server 由于種種原因，無法提供正常服務(wù)了（比如由于自身原因，出現(xiàn)短暫宕機）！而此時靜態(tài)文件又恰好過期，這樣一來，緩存節(jié)點的流量會導(dǎo)向源站，源站又不能正常提供服務(wù)，在訪客看來，網(wǎng)站就無法訪問了。
這可怎么辦呢？！
不用怕！
云防護(hù)系統(tǒng)也同樣考慮到了這種情況，并至少提供以下三種解決方案：
（1）使用舊緩存文件
當(dāng)緩存節(jié)點回源時，源站有故障，會返回異常頁面，如 502/504，或超時等。此時，緩存節(jié)點直接使用舊文件響應(yīng)訪客。在訪客看來，能正常訪問到內(nèi)容，并不會感知到源站出現(xiàn)故障。此外，我們還會對舊文件強制延長一個短的過期時間，防止短時間內(nèi)出現(xiàn)頻繁回源的情況。
（2）永久在線
對于開啟此功能的網(wǎng)站，云防護(hù)會通過自研的爬蟲程序，定期抓取客戶源站的內(nèi)容，緩存到我們的數(shù)據(jù)服務(wù)器上，我們稱之為“鏡像”。當(dāng)源站出現(xiàn)問題時，緩存節(jié)點也可以將訪問請求導(dǎo)向“鏡像”文件，從而正常響應(yīng)數(shù)據(jù)給訪客。
（3）重保只讀
和永久在線原理類似，重保只讀也是通過爬蟲生成“鏡像”文件。只是，此時“鏡像”可以充當(dāng)源站使用（偽源站），源站在重保只讀期間，可完全關(guān)閉。所有的請求或攻擊，都不會導(dǎo)向真正的源站，這樣即可保證重要時期源站不會因攻擊或訪問量過大而出現(xiàn)問題。
當(dāng)然，以上策略都是可能有損的。前面講過，對動態(tài)文件的請求是非冪等的，即使強制緩存起來，也沒有大太作用。另外像 SNS 網(wǎng)站有較強的交互性，除了下載以外，還會上傳文件（HTTP POST/PUT）。這些數(shù)據(jù)，目前都沒有辦法用以上策略解決。當(dāng) Web Server 出現(xiàn)問題時，還需要網(wǎng)站盡快針對自身問題從根源上進(jìn)行修復(fù)。
至此，CDN 緩存系統(tǒng)和 Web Server 各司其職，相得益彰。你不知道的是，云防護(hù) CDN 緩存內(nèi)部其實還有許多其他方面的優(yōu)化：
（1）Range 請求的緩存及回源合并。
（2）熱點文件分級緩存。
（3）全鏈路 IPv6 的支持。
（4）全鏈路 HTTP2 等協(xié)議的支持。
（5）基于日志的分析與監(jiān)控。
（6）基于監(jiān)控的動態(tài)父層設(shè)計。
所有這些，都是為了一個共同的目標(biāo)：最大程度的為客戶網(wǎng)站提供防護(hù)！接入云防護(hù)，安全無憂~
