Web 應用優化實戰：Flickr 架構演進與核心技巧

Flickr 作為 Web 2.0 代表，其優化實踐極具參考價值。本文梳理其在文件策略、壓縮、緩存、構建部署四個維度的核心技巧。

一、文件大小與請求數平衡策略

困境：

• 合併所有 JS/CSS → 請求數少，但首屏阻塞久、緩存失效影響大
• 拆分過細 → 並行下載受瀏覽器同域限制（HTTP/1.1 下 IE/FF 默認 2-6 個連接）

Flickr 折衷方案：

1. 業務邏輯拆分為 核心基礎庫、頁面級模塊、功能組件 三層
2. 核心庫合併為 1-2 文件（極少變動，長期緩存） 3. 頁面級模塊按頁面類型合併（首頁、相冊頁、個人頁等） 4. 功能組件按需異步加載（如上傳組件、編輯器） 5. 總文件數控制在 4-6 個，平衡並行與緩存粒度

二、壓縮優化：mod_deflate 替代 mod_gzip

Flickr 策略：

• 僅壓縮 JS、CSS、HTML 文本資源
• 不壓縮圖片/視頻/字體（已壓縮格式，再壓無增益且浪費 CPU）
• JS 混淆壓縮：Dojo Compressor 構建 AST 樹，安全重命名、移除死代碼
• CSS 壓縮：正則替換多空格、移除註釋、縮短顏色值，最高 50% 壓縮比

三、緩存策略：ETag 與 Last-Modified 深度應用

核心機制：

• Last-Modified + If-Modified-Since：基於修改時間
• ETag + If-None-Match：基於內容指紋（更精確）

負載均衡下的 ETag 陷阱與解法：

• 默認 ETag = inode + size + mtime → 多台服務器 inode 不同 → ETag 不一致 → 緩存失效
• 解法：Apache 配置 FileETag MTime Size（去除 inode），僅用修改時間+大小
• 副作用：可能影響 If-Modified-Since 準確性，需權衡

緩存層級設計：

四、靈活構建部署：mod_rewrite 日常構建

• Daily Build：每日自動化構建發布
• 環境切換：mod_rewrite 規則動態切換到不同版本目錄（v1/, v2/, canary/）
• 灰度發布：基於 Cookie/IP/Header 重寫到新版本目錄
• 回滾秒級：修改 rewrite 規則指向舊版本目錄，無需重啟服務

# 示例：基於 Cookie 灰度
RewriteCond %{HTTP_COOKIE} new_version=1
RewriteRule ^(.*)$ /v2/$1 [L]

# 默認舊版本
RewriteRule ^(.*)$ /v1/$1 [L]

現代架構對應演進

Flickr 的優化哲學——在約束中尋找平衡，用工程化手段解決架構問題——至今仍具指導意義。