如何在AWS 中實現動態CDN

CDN 不是一個新名詞，這個把緩存分佈到世界各地的技術起碼出現了 10 年。最近又火起來，原因是用戶對網絡響應時間的要求深化。國內就有阿里雲的 CDN, ChinaCache, Baidu+Cloudfare, UCloud, 7牛 還有很多。。。因爲網絡問題，很多大公司都會採用國外服務器，然後把內容通過CDN 推到國內。

技術上，我認爲這麼多公司一起做CDN，其中一個原因就是這東西不復雜，當然國內國外的支持還會加上一些其他問題。主流技術就是 Nginx / Varnish 作爲 File Cache, 然後部署全局負載均衡GSLB（上一篇文章也有提及過）。 以技術角度來看，我是不會自己架一個CDN網絡的，因爲你必須有上百節點的纔算得上CDN，個人架設成本有點高。

選擇 CDN 時一半會考慮以下的因素：

1. 支持 Cache invalidation 

2. Invalidation 所需要的時間與價格

3. 流量費不要超過 USD 0.14／GB

4. 支持動態 CDN

5. 支持子域名 （CloudFlare / 安全寶 都需要域名切換，防DDOS）

6. 支持 Cache Behaviour （不同的路徑有不同的 cache 特性）

7. 可以 pass through header / cookie

8. Respect Cache-control header

9. 最好可以直接有操作介面更改 header

10. 支持 edge side include

相信能做到以上的，就不純粹是個簡單的CDN，是個真正的CDN。今天主要分享的是第 4)點 動態 CDN

AWS 在 2013 年開始在 Cloudfront 支持動態CDN，意思就是可以把 html 也存到 CDN 上，用戶拿到 HTML 和 靜態文件都在 CDN 上，不需要向服務器 (origin) 請求。原理上，這就支持無限的訪問。read 請求日千萬不是問題，問題你的信用卡能刷多少錢而已。

這個 Dynamic CDN 的原理是這樣的 比如，以 abc.com爲例子作一下說明。

1. abc.com CNAME 去 Cloudfront 的域名 （xxxxxxxx.aws.cloudfront.com)

2. 在 xxxxxxxx.aws.cloudfront.com 以下的 Cloudfront ID (cloudfrontID.default.cloudfront.com) 接受 abc.com 的請求

3. xxxxxxxx.aws.cloudfront.com 指向  origin.abc.com 拿數據 （就是本服務器）

4. 要是請求沒有 cloudfront 本地 cache, 就繼續，否則反回 cache

5. 要是請求不是特定的 path ( cache behaviour)，則反回

6. cloudfrontID.default.cloudfront.com 向 web 服務器 (Origin) 請求 object (html / css / .jpg / …)

7. 把 header (cache-header / CORs) 也記到 cache 中

8. 把 xxx.default.cloudfront.com 的 cache 反回到 abc.com 的客戶端

9. 跟據在第 7) 點 定義的 header按時間清理緩存

10. 跟據請求的來源IP，在世界各地每一個edge 上操作 1-9

這有點像反向代理，比如 Varnish 就在做差不多的事。只是CDN 在用 edge cache. Varnish 一般的使用情況是把文件緩存最長時間，然後根據 Origin 給的指令來更新緩存。這是客戶最想要的，這樣就不會有 “第一位用戶變慢” 這樣的問題。但要是用過好幾個 CDN 的人就會發現，市面上沒有CDN 支持永久緩存這回事。原因在哪？這沒有官方迴應，我感覺是 edge cache 是很多很多的服務器，在 AWS 上跑一次 cache invalidation 去清理所有 edge 上的 cache 要花上 20－30 分鐘，要是每一次的 object 更新也得像 Varnish 去 “push” 更新，就會花上很大的成本。倒不如自動 Expire, 然後在下一位用戶有需要時，才把最近那地理位置的 edge cache 上加一個 object cache. 這樣就省去一筆很大的成本。

好的 CDN 得支持 Behavior, 就是路徑不同的特性，在不同的應用上，特別是已登錄的用戶，使用太多的 cache 會令系統出問題。得跟據路徑來刪除／加速 刷新。

要是支持登錄用戶的話， Cookie 要用客戶端直接傳送到 Origin, 所以得支持 (forward cookie)

每個 CDN 會有一個 Default behaviour, 就是不指定情況下，都跟據這個 behaviour 作出迴應。比如我們要支持用戶登錄，得把 session 通過 Dynamic CDN 回傳到 origin 

整體來說，AWS Cloudfront 是個很不錯的 CDN, 需要有的都有了。要是能支持 ESI (Edge Side Includes) 就更好了。市面上的雲加速 / 雲防護大約都是 Dynamic CDN 的原理，至於能加速多少，能不能支持用戶登錄，還有 Cookie/Cache-header  等問題，就是深度用戶需要關注的地方。

下次我們講怎麼用 全局負載均衡GSLB 加上 Cloudfront 做全球佈局的動態 CDN。