AWS 中怎么實(shí)現(xiàn)動(dòng)態(tài)cdn，相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

成都創(chuàng)新互聯(lián)從2013年成立，先為鳳泉等服務(wù)建站，鳳泉等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為鳳泉企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。

CDN 不是一個(gè)新名詞，這個(gè)把緩存分布到世界各地的技術(shù)起碼出現(xiàn)了 10 年。最近又火起來(lái)，原因是用戶對(duì)網(wǎng)絡(luò)響應(yīng)時(shí)間的要求深化。國(guó)內(nèi)就有阿里云的 CDN, ChinaCache, Baidu+Cloudfare, UCloud, 7牛 還有很多。。。因?yàn)榫W(wǎng)絡(luò)問(wèn)題，很多大公司都會(huì)采用國(guó)外服務(wù)器，然后把內(nèi)容通過(guò)CDN 推到國(guó)內(nèi)。

技術(shù)上，我認(rèn)為這么多公司一起做CDN，其中一個(gè)原因就是這東西不復(fù)雜，當(dāng)然國(guó)內(nèi)國(guó)外的支持還會(huì)加上一些其他問(wèn)題。主流技術(shù)就是 Nginx / Varnish 作為 File Cache, 然后部署 GSLB（全局負(fù)載均衡）。 以技術(shù)角度來(lái)看，我是不會(huì)自己架一個(gè)CDN網(wǎng)絡(luò)的，得上百節(jié)點(diǎn)的才算得上CDN，個(gè)人架設(shè)成本有點(diǎn)高。認(rèn)為選擇 CDN 時(shí)會(huì)考慮以下的因素

1. 支持 Cache invalidation 

2. Invalidation 所需要的時(shí)間與價(jià)格

3. 流量費(fèi)不要超過(guò) USD 0.14／GB

4. 支持動(dòng)態(tài) CDN

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

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

7. 可以 pass through header / cookie

8. Respect Cache-control header

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

10. 支持 edge side include

相信能做到以上的，就不純粹是個(gè)簡(jiǎn)單的CDN，是個(gè)真正的CDN。今天主要分享的是第 4)點(diǎn) 動(dòng)態(tài) CDN

AWS 在 2013 年開(kāi)始在 Cloudfront 支持動(dòng)態(tài)CDN，意思就是可以把 html 也存到 CDN 上，用戶拿到 HTML 和 靜態(tài)文件都在 CDN 上，不需要向服務(wù)器 (origin) 請(qǐng)求。原理上，這就支持無(wú)限的訪問(wèn)。read 請(qǐng)求日千萬(wàn)不是問(wèn)題，問(wèn)題去了信用卡能刷多少錢(qián)而已。

這個(gè) Dynamic CDN 的原理是這樣的 比如，以 abc.com為例子作一下說(shuō)明。

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

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

3. xxxxxxxx.aws.cloudfront.com 指向  origin.abc.com 拿數(shù)據(jù) （就是本服務(wù)器）

4. 要是請(qǐng)求沒(méi)有 cloudfront 本地 cache, 就繼續(xù)，否則反回 cache

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

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

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

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

9. 跟據(jù)在第 7) 點(diǎn) 定義的 header按時(shí)間清理緩存

10. 跟據(jù)請(qǐng)求的來(lái)源IP，在世界各地每一個(gè)edge 上操作 1-9

這有點(diǎn)像反向代理，比如 Varnish 就在做差不多的事。只是CDN 在用 edge cache. Varnish 一般的使用情況是把文件緩存最長(zhǎng)時(shí)間，然后根據(jù) Origin 給的指令來(lái)更新緩存。這是客戶最想要的，這樣就不會(huì)有 “第一位用戶變慢” 這樣的問(wèn)題。但要是用過(guò)好幾個(gè) CDN 的人就會(huì)發(fā)現(xiàn)，市面上沒(méi)有CDN 支持永久緩存這回事。原因在哪？這沒(méi)有官方回應(yīng)，我感覺(jué)是 edge cache 是很多很多的服務(wù)器，在 AWS 上跑一次 cache invalidation 去清理所有 edge 上的 cache 要花上 20－30 分鐘，要是每一次的 object 更新也得像 Varnish 去 “push” 更新，就會(huì)花上很大的成本。倒不如自動(dòng) Expire, 然后在下一位用戶有需要時(shí)，才把最近那地理位置的 edge cache 上加一個(gè) object cache. 這樣就省去一筆很大的成本。

好的 CDN 得支持 Behaviour, 就是路徑不同的特性，在不同的應(yīng)用上，特別是已登錄的用戶，使用太多的 cache 會(huì)令系統(tǒng)出問(wèn)題。得跟據(jù)路徑來(lái)刪除／加速 刷新。

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

每個(gè) CDN 會(huì)有一個(gè) Default behaviour, 就是不指定情況下，都跟據(jù)這個(gè) behaviour 作出回應(yīng)。比如我們要支持用戶登錄，得把 session 通過(guò) Dynamic CDN 回傳到 origin 

看完上述內(nèi)容，你們掌握AWS 中怎么實(shí)現(xiàn)動(dòng)態(tài)CDN的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！