如何在AWS 中實現動態CDN

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

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

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

支持 Cache invalidation

Invalidation 所須要的時間與價格

流量費不要超過 USD 0.14／GB

支持動態 CDN

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

支持 Cache Behaviour （不一樣的路徑有不一樣的 cache 特性）

能夠 pass through header / cookie

Respect Cache-control header

最好能夠直接有操做介面更改 header

支持 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。