在天貓雙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系統可以轉變為弱依賴：一方面既通過靜態化快取層一定程度上保護了後端系統；另一方面在極限情況 下，當後端系統不可用時，可以通過快取維持一部分訪問量。

第一階段以商品詳情為主的靜態化架構改造取得了良好的效果，除天貓商品詳情繫統率先完成改造外，店鋪等瀏覽型業務系統也很快參照類似方案完成了架構調整。在 過程中，逐漸確立了靜態化技術規範，簡化了接入步驟；

同時，也發現在各自的系統中，儘管同樣基於瀏覽型業務場景，但由於採用的快取方案細節差異，存在一些 涉及靜態化快取體系相關的共性問題，包括以下幾點。

• 單機快取靜態頁面，受部署模式影響，快取層無法水平擴充套件。

• 單機模式下，快取受限於伺服器能力及記憶體容量，命中率受制約。

• 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 提供了更強的服務能力，放置在離使用者最近的節點上，是快取系統單元化最理想的架構。同時，也為雙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節點地域特性的快取體系， 也降低了秒級請求的衝擊型峰值，更好地滿足了系統穩定性需求。在未來一段時間內，與天貓類似的瀏覽型系統均能夠參照這套架構體系較為方便地完成靜態化改造 和接入，並達到理想的穩定性和可伸縮目標。

推薦閱讀：

覺得有幫助？請轉發給更多人！

架構師小祕圈，聚集10萬架構師的小圈子！不定期分享技術乾貨，行業祕聞！彙集各類奇妙好玩的話題和流行動向！長按左側圖片，掃碼加入架構師微信群！