在天貓雙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節點地域特性的緩存體系， 也降低了秒級請求的衝擊型峯值，更好地滿足了系統穩定性需求。在未來一段時間內，與天貓類似的瀏覽型系統均能夠參照這套架構體系較爲方便地完成靜態化改造 和接入，並達到理想的穩定性和可伸縮目標。
作者徐昭，花名長恭，主要負責天貓詳情繫統的架構優化工作。畢業於浙江大學計算機專業，熱愛Java Web技術，多關注服務端性能優化，熱衷開源技術的研究和分享。
本文鏈接：http://www.cnblogs.com/oooweb/p/tmall-cdn-architecture.html