天貓瀏覽型應用的CDN靜態化架構演變

原文連接：http://www.csdn.net/article/2014-01-22/2818227-CDN-Architecture

在天貓雙11活動中，商品詳情、店鋪等瀏覽型系統，一般會承受超出平常數倍甚至數十倍的流量衝擊。隨着歷年來雙11流量的大幅增長，每一年這些瀏覽型系統都要面臨容量評估、硬件擴容、性能優化等各種技術挑戰。所以，架構方面的重點在於，如何可以利用合理成本應對瞬間飆高的峯值請求，並確保活動完整週期中系統容量的可伸縮性、用戶響應時間的穩定性，以及外部依賴系統出現問題時的高可用性。此外，做爲最主要的頁面流量承載體系，架構方面還需考慮防爬攻擊、流控容災等安全、穩定的需求，並綜合衡量網絡帶寬、硬件成本、緩存效率等各方面要素，找準平衡點，從而達到以不變應萬變的理想效果。

演進

爲此，自2011年起，以天貓商品詳情繫統爲表明，天貓瀏覽型系統在架構上的主要工做之一就是經過靜態化技術實現了動靜態信息分離、利用緩存技術存放靜態化內容、利用少許動態數據異步加載填充。整個過程歷經單機靜態化、統一緩存接入，到2013年雙11前完全CDN化三個階段（如圖1所示），有效解決了緩存命中率、流量天然分佈、系統擴容簡化、用戶端響應速度等關鍵問題。

圖1  CDN化的三個階段

目前，天貓瀏覽型系統最新使用的這套基於CDN的靜態化架構，能夠知足高可用持續伸縮的原始預期，幷包含以下特性。

 

• 動靜分離：HTML靜態化和熱點分離。
• 分佈式緩存體系：利用CDN節點分佈式緩存。
• 多級緩存機制：CDN兩級+應用一級。
• 統一服務靜態化集羣。
• 一致性維持：主動失效&自動失效緩存機制。
• 動態內容填充：能支持多種時效性動態內容填充方式。
• 監控預警機制：流量、失效、命中率等關鍵參數實時監控報警。

 

本文將針對這一優化歷程，就主要技術挑戰、架構改造策略、最終優化成果作一個總覽式的介紹，並重點對CDN化過程當中總體架構的演進、緩存失效機制、動態內容填充等具體要點進行論述。

第一階段：系統靜態化

早期天貓瀏覽型系統大多采用簡單架構，實現一層很薄的前臺應用。以天貓商品詳情繫統爲例，針對商品、用戶等訪問量較大的數據中心接口模式改造爲應用 Client端緩存前置，同時廣泛使用頁面高速緩存（PageCache）來下降後端系統壓力，使得總體可支持應用水平擴展不受限制。這一階段系統面臨的 主要問題和挑戰包括如下幾點。

 

• 應用服務器瓶頸，頁面渲染帶來的CPU開銷巨大。
• 單純基於Java端的緩存已基本覆蓋，總體性能提高空間有限。
• 水平擴容只能支持容量線性提高，難以知足大促井噴式流量增加，擴容成本高。

 

從問題看，基於原有動態瀏覽型系統模式而優化的瓶頸很難規避，例如如下幾點。

 

• Java應用服務器端必要開銷，包括：涉及頁面內容的字符串查找、替換、拼接等；元數據獲取的網絡開銷；Servlet自己的性能瓶頸。
• Web服務器端，包括：模塊過濾，例如訪問日誌、Cookie打點、繁簡轉換；大HTML頁面自己的GZIP壓縮等。
• 突發流量的抵禦，例如攻擊、秒殺、大促，等等。
• 已用優化手段達到了邊界，包括：可以使用緩存的地方已經使用；服務端CPU能力已優化完畢（模板解析、壓縮）。

 

整體來看，必須從架構着手完全解決。架構優化的方向上，考慮如下3個方面。

 

• 改變緩存方式，直接緩存HTTP響應結果。
• 改變緩存位置，直接基於Web服務器，屏蔽業務邏輯。
• 基本原則，緩存空間足夠大、無單點、易於維護。

 

爲此，2012年起正式啓動了動態瀏覽型系統的改造項目，經過靜態化手段解決上述問題。即基於業務把原動態系統中的內容作動靜分離，對瀏覽者無關部分作緩 存，動態內容作CSI填充。具體考慮從三方面重點着手展開：動靜信息分離、靜態化緩存方式，以及緩存失效機制。圖2爲一期靜態化總體架構。

圖2  一期靜態化總體架構

動靜分離

將原頁面內容按業務進行區分，從瀏覽用戶、信息發佈者、時間、地域、私有（Cookie等）信息等維度分析，抽取出頁面中相對公共不依賴以上因素，且變化頻 度較低的內容做爲基礎，生成靜態化內容。靜態化後頁面URL固定，不一樣URL表示不一樣內容，服務器返回的請求與URL相關，其餘動態內容則經過異步接口調 用，經過CSI方式填充。以商品詳情繫統爲例，靜態化後商品基本信息如標題、商品詳情、銷售屬性組合等信息均直接進入緩存，其餘如優惠、庫存、物流、服務 等動態信息則經過異步調用方式填充至靜態化後的頁面框架內。

緩存方式

總體可劃分爲應用服務器、Web服務器、CDN節點、客戶端瀏覽器4層緩存體系（如圖3所示），分別承載不一樣使命。

圖3  緩存總體劃分

緩存系統方面從開發成本、穩定性、I/O性能各方面綜合考慮，選擇了阿里內部普遍使用的分佈式key/value系統Tair，存取靜態化後的頁面。相對 Nginx本地硬盤緩存方式來講，本地Tair讀寫性能更優，且服務器響應時間和負載波動影響小，使用及維護成本低。整套體系詳解以下。

 

• 應用層緩存：減少後端應用服務器壓力，減小遠程調用量。
• Web服務器緩存：減少後端應用服務器壓力，抵擋瞬間峯值和/或針對少許定點內容的攻擊。
• CDN緩存：合理地利用CDN，內容緩存放置在離用戶最近的地方，加快響應的速度。
• 瀏覽器緩存：減小用戶請求數量，下降系統壓力，提高用戶體驗。

 

緩存失效

緩存失效主要包含「失效後臺進行主動失效」和「緩存過時自動失效」兩種機制。針對主動失效，主要技術難點包括如下3個方面。

 

• 失效來源及監控範圍：基於業務決定須要監聽哪些數據源哪部份內容變動，經過變動消息接收執行緩存失效動做。
• 每秒失效數據量級：單位時間內大量數據源（如商品、店鋪裝修）失效處理。
• 要失效的緩存範圍：支持批量（例如基於域名）和單個數據源緩存失效變動。

 

以商品詳情繫統爲例，失效來源主要爲商品數據及店鋪裝修信息，後臺用戶修改致使對應內容發生變動時，經過消息機制通知失效後臺。失效後臺接收消息並保留待失效商品ID，經過調用本地Tair接口失效緩存，大體流程如圖4所示。

圖4  緩存失效流程

改造效果

依然以天貓商品詳情繫統爲例，採起靜態化架構後，2012年雙11時，在性能方面，結合後期完成的店鋪裝修分離等優化工做，系統單機（實體機）在80%緩存 命中率的狀況下，安全QPS（每秒查詢率）相較2011年同期單機性能提高7倍多，系統資源則不到原來的50%。與此同時，靜態化還解決了單URL熱點攻 擊問題，更重要的是，使得原動態架構下依賴的後端Java系統能夠轉變爲弱依賴：一方面既經過靜態化緩存層必定程度上保護了後端系統；另外一方面在極限狀況 下，當後端系統不可用時，能夠經過緩存維持一部分訪問量。

第二階段：統一Web緩存

第一階段以商品詳情爲主的靜態化架構改造取得了良好的效果，除天貓商品詳情繫統率先完成改造外，店鋪等瀏覽型業務系統也很快參照相似方案完成了架構調整。在 過程當中，逐漸確立了靜態化技術規範，簡化了接入步驟；同時，也發如今各自的系統中，儘管一樣基於瀏覽型業務場景，但因爲採用的緩存方案細節差別，存在一些 涉及靜態化緩存體系相關的共性問題，包括如下幾點。

 

• 單機緩存靜態頁面，受部署模式影響，緩存層沒法水平擴展。
• 單機模式下，緩存受限於服務器能力及內存容量，命中率受制約。
• CSI模式填充動態內容，須要前端腳本配合，開發成本較高。

 

所以，天然而然想到有必要統一Web緩存層接入，共享靜態化集羣以節省成本、提升穩定性和命中率。從運維角度看：

 

• 統一接入層能夠減小多個應用接入使用的成本，接入的應用只需維護自身Java系統，不用單獨維護緩存；只要關心如何使用，統一的緩存框架也可更好地讓更多流量型系統接入使用；
• 統一接入層易於維護，並可統一增強全局監控、實現配置自動化，使集中維護升級更加便利；
• 統一接入層能夠共享內存，最大化利用內存，不一樣系統間的內存能夠動態切換，有效應對攻擊等相似突發狀況。

 

搭建統一接入層，須要針對各瀏覽型系統作局部改動。而總體須要重點解決的技術問題，從架構層次上看，主要涉及如下幾大部分。

緩存系統選擇

第一階段各瀏覽型系統採用了單機緩存模式，基於成本、業務場景等各方面因素稍有不一樣。搭建統一接入層須要可以兼顧各瀏覽型系統的特殊要求，同時還需能支持共 同須要的ESI解析及ESI模式下GZIP壓縮，完成靜態頁面局部動態內容服務端填充；性能方面，可以知足雙11/雙12流量壓力下的QPS（每秒訪問 率）要求；支持失效協議以及長鏈接，可執行批量失效。綜合以上分析，並考慮將來靜態化內容最終CDN化部署方式，統一接入層Cache最終軟件層面可支持 以上全部功能，同時還包括快速失效和預熱能力，支持CSS和JavaScript的腳本合併，長鏈接和批量失效，支持基於HTTP頭的可編程配置等。

統一失效機制

與 緩存軟件變動對應，各接入統一緩存的瀏覽型系統需針對新的緩存體系及協議改造原有失效機制，使用公共協議標準來執行批量及單個對象的主動失效。同時，創建 了統一的失效中心和緩存校驗層，全部接入應用的主動失效請求統一經由失效中心，經過Purge方式執行緩存失效。底層失效源方面，監控信息源數據變動。以 商品爲例，當商品編輯完畢，包括商品標題描述等更新後詳情頁面須要失效，基於實時監控和消息機制進行主動失效（如圖5所示）。

圖5  基於事實監控和消息機制主動失效

Web服務器改造

緩存層以前的Web服務層，須要能支持一致性Hash分組，並集成現有系統使用的Session框架，可支持基於域名虛擬主機的動態配置。爲此，核心系統部門的同事自行開發了淘寶定製版本的Nginx服務器（Tengine），做爲統一接入層之上的Web服務器層部署。

網絡流量支持

統一接入緩存層後，因爲集中了各系統緩存信息且訪問集中，因此網絡部署層次方面，可以使用萬兆網卡配置解決硬件瓶頸；同時評估集羣需支撐的網絡出口流量，確保機房內部及外部出口無瓶頸；在緩存不命中的狀況下，需能支撐請求回源服務器端造成的內部流量。

總體部署方案

圖6是總體部署方案，從中能夠看出：

 

• 統一接入層部署，包括前端Nginx服務器+緩存系統+後端Java應用部署結構；
• Web服務器層作一致性Hash分組；
• 統一緩存層支持ESI或CSI方式獲取動態內容；
• 統一失效中心機制失效緩存。

圖6  總體部署方案

 

改造效果

統一接入層於2013年上半年改造完成並開始了商品詳情等瀏覽型系統的接入工做，完成後，在原有單機緩存模式之上又增長了一層集中式緩存，解決了緩存層的水 平擴展問題。萬兆網卡的使用有效解決了緩存層的網絡瓶頸。因爲統一接入層與應用無關，所以能夠多應用共用，使監控和維護成本大大下降，並提升了質量和效 率。固然，這一改造也形成應用對緩存層的強依賴鏈路，同時這一層緩存也存在單點問題。從靜態化單機緩存模式到統一接入層，路只走了一半，一切改造的終極目 標，是利用CDN分佈式、地域性特性及強大的流量容量體系，實現瀏覽型應用的CDN靜態化。

第三階段：CDN靜態化

統一接入層解決了單機緩存內存使用率低的問題，擺脫了單機緩存受內存大小制約，在面對商品數量增長和商品熱點分散的場景下，只能垂直擴展那些沒法水平擴展的 問題，這提高了緩存系統的可維護性和擴展性。在完成系統從單機靜態化緩存到統一接入層的架構改造以後，已經具有了將靜態頁面放置到CDN上的條件。CDN 提供了更強的服務能力，放置在離用戶最近的節點上，是緩存系統單元化最理想的架構。同時，也爲雙11峯值流量和防攻擊提供了更爲可靠穩定的保障。

CDN化涉及3個具體技術難點。

 

• CDN分佈式節點失效問題。方案：採用主動失效的方式，商品變動後主動發送請求給緩存校驗層，由其通知失效中心，接收並分發處理節點失效任務，以確保秒級失效。
• 命中率問題。方案：優化節點部署條件，CDN節點數量可控，避免失效請求量過大，靠近流量集中區域，且節點到主站網絡穩定；控制節點數量，訪問流量集中分佈在這批節點；節點內部採用相似統一緩存層的一致性Hash規則，以達到相似命中率。
• 局部區域動態內容定時切換。方案：價格、庫存等動態信息走動態系統接口，經過異步方式獲取；展示端定時切換活動Banner等內容，走ESI回源，並一樣緩存回源的靜態資源。

 

總體架構

基於以上思路，整體架構已經較爲清晰，方案上從緩存體系、失效模式、動態內容填充幾方面入手執行改造，總體架構如圖7所示。

圖7  靜態化總體架構

緩存體系

統一接入層和CDN節點上都是用Web服務器+Cache方式。靜態化應用對應的域名會被解析到CDN和統一接入層的虛擬IP上，CDN拿到請求後，先讀取 本地緩存，緩存不命中則到統一緩存層獲取。統一接入層按原有邏輯處理請求，緩存不命中則回源到服務器端獲取數據。同時，統一接入層Web服務器須要可以識 別用戶請求是CDN回源類型，仍是正常請求，以避免重複打點訪問日誌和GZIP壓縮。

緩存失效

緩存失效原理與統一接入層相似。失效執行流程大體爲，客戶端請求經VIP被隨機分配給失效中心某個節點，而後失效任務被髮送至代理，經代理向緩存服務器發送失效命令並返回結果，如圖8所示。

圖8  緩存失效原理

動態內容填充

業務方面，由於存在定時切換頁面局部內容的需求，總體架構中增長ESI和頁面打點做爲動態內容填充方式。ESI標籤由Cache層負責解析回源，而且會對ESI請求作緩存，而且提供以下特性。

 

• 須要定時作全站變動的頁面模塊用ESI的Include實現，時間判斷則放在應用服務器處理回源請求的時候。
• 回源之後，應用服務器設置失效時間。例如請求回源時應用服務器加上s-maxAge，這個頁頭的緩存在定點失效。
• Cache系統提供合併回源，避免重複，防止失效後的高併發回源給應用服務器帶來衝擊。
• Cache系統在ESI的緩存失效後回源，回源的請求處理期間不會掛起外部請求，會繼續向客戶端返回老版本的頁面，回源請求處理完之後更新成新版本。相似Copy on Write，防止回源請求掛起致使前端服務器掛起。
• ESI回源時對Response Header的操做不會發到客戶端。

 

改造效果

最終基於CDN靜態化的架構去除了單機緩存的橫向擴展瓶頸，命中率越高、系統容量越大的特性決定了能夠用較小的成本支持峯值流量；引入ESI編程模型，解決 了頁面上的局部刷新問題，支持雙11業務中一些須要全網定時切換頁面內容的特殊需求；靜態頁面+弱依賴改造帶來高可用性，並最終沉澱出了一套與應用無關的 緩存和失效體系。2013年雙11當天，憑藉這一整套CDN靜態化架構，天貓商品詳情等瀏覽型系統平穩度過了創造歷史的一天，不管是頁面訪問量（PV）還 是頁面請求峯值（QPS）均創新高，而系統自己很是穩定，並有充足餘量承受更大級別的訪問流量。同時，新的部署模型和基於CDN節點地域特性的緩存體系， 也下降了秒級請求的衝擊型峯值，更好地知足了系統穩定性需求。在將來一段時間內，與天貓相似的瀏覽型系統均可以參照這套架構體系較爲方便地完成靜態化改造 和接入，並達到理想的穩定性和可伸縮目標。