大瀏覽量系統的靜態化架構設計

淘寶前臺系統的優化歷程

2009年，系統拆分，靜態文件合併，前端頁面異步化和JSON化。

2010年，去DB依賴，引入緩存，提高單機QPS，關注用戶體驗。

2011年，優化進入深水區Velocity，BigPipe。

2012年，靜態化改造。

2013年，統一Cache，CDN化，網絡協議。

高訪問系統的靜態改造

什麼是靜態化系統？
幾個特徵：

1. 一個頁面對應URL一般固定。
2. 在頁面中不能包含與瀏覽者相關的因素，這裏所說的「不能包含」不包括JS動態生成的部分，也就是在頁面中HTML代碼不能明顯地含有與瀏覽器相關的DOM。
3. 在頁面中不包含時間因素。頁面一樣不能含有與時間（而是服務端輸出的時間）相關的因素，頁面中的DOM不隨時間變化而變化。
4. 頁面中不包含地域信息。
5. 不能包含Cookie等私有數據。

爲何要進行靜態化架構設計？

系統通過屢次優化升級，包括系統架構的升級，系統自己的模塊優化，代碼優化和增長各類緩存等這些優化，咱們的優化層次都是在java系統中作改進的。在這種狀況下壓測咱們的java系統，性能依舊不能知足咱們的指望，咱們的目標是再上一個數量級。java自己遇到了瓶頸，天然就想到了靜態化這種架構，讓請求儘可能不進過java。

那麼系統靜態化爲什麼能作java系統作不到的高性能呢？靜態化有以下優勢：

1. 改變了緩存方式。直接緩存http鏈接而不是僅僅緩存數據，web代理服務器根據請求url直接取出對應的http相應頭和響應體直接返回，這個響應連http協議都不用從新組裝，一樣http請求頭也不必定須要解析，因此作到了獲取數據最快。
2. 改變了緩存的地方。不是在java層面作緩存而是直接在web服務器層上作，因此屏蔽了java層面的一些弱點，而web服務器（如nignx，apache，varnish）都擅長處理大併發的靜態文件請求。

如何改造動態系統？

1. URL惟一化
2. 分離與瀏覽者相關的因素。
3. 分離時間因素。
4. 異地化地域因素。
5. 去掉Cookie。
6. 動態內容結構化。（ESI和CSI）

ps：

ESI(Edge Side Includes)-即在web代理服務器作動態內容請求，並將請求插入到靜態頁面中，當用戶拿到頁面時已是一個完整的頁面了。這種方式對服務端性能有些影響（同步集中請求），對對用戶體驗較好。

CSI(Client Side Include)-這種方式就是發起一個異步js請求單獨向服務端獲取動態內容。對服務端性能影響小，可是用戶端頁面有些延時。

如何選擇靜態化方案的設計？

nignx＋cache(靜態文件)＋java 結構虛擬機單機部署

nignx＋cache(靜態文件)＋java 結構實體機(增大cache內存，增大緩存命中率－採用一致性hash分組)單機部署

統一cache層＋java（把nignx和cache層統一管理和運維）

緩存失效問題？

被動失效：採用設置cache時間長度自動失效，也能夠開發一個cache管理界面手工失效某些cache。

主動失效：

1. cache失效中心監控數據庫表變化發送purge失效請求
2. 裝修時間戳比較失效裝修內容
3. java系統發佈清空cache
4. vm模板發佈清空cache 

 其中失效中心承擔了主要的失效功能，失效中心的邏輯圖以下：