資訊專(zhuān)欄INFORMATION COLUMN
摘要：最近又火起來(lái)，原因是用戶(hù)對(duì)網(wǎng)絡(luò)響應(yīng)時(shí)間的要求深化。今天主要分享的是第點(diǎn)動(dòng)態(tài)在年開(kāi)始在支持動(dòng)態(tài)，意思就是可以把也存到上，用戶(hù)拿到和靜態(tài)文件都在上，不需要向服務(wù)器請(qǐng)求。下次我們可以討論如何在全局負(fù)載均衡加上做全球化布局的動(dòng)態(tài)。
CDN 不是一個(gè)新名詞，這個(gè)把緩存分布到世界各地的技術(shù)起碼出現(xiàn)了 10 年。最近又火起來(lái)，原因是用戶(hù)對(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, 然后部署 全局負(fù)載均衡GSLB（上一篇文章也有提及過(guò)）。 以技術(shù)角度來(lái)看，我是不會(huì)自己架一個(gè)CDN網(wǎng)絡(luò)的，因?yàn)槟惚仨氂猩习俟?jié)點(diǎn)的才算得上CDN，個(gè)人架設(shè)成本有點(diǎn)高。
選擇 CDN 時(shí)一半會(huì)考慮以下的因素：
支持 Cache invalidation
Invalidation 所需要的時(shí)間與價(jià)格
流量費(fèi)不要超過(guò) USD 0.14／GB
支持動(dòng)態(tài) CDN
支持子域名 （CloudFlare / 安全寶 都需要域名切換，防DDOS）
支持 Cache Behaviour （不同的路徑有不同的 cache 特性）
可以 pass through header / cookie
Respect Cache-control header
最好可以直接有操作介面更改 header
支持 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 上，用戶(hù)拿到 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ō)明。
abc.com CNAME 去 Cloudfront 的域名 （xxxxxxxx.aws.cloudfront.com)
在 xxxxxxxx.aws.cloudfront.com 以下的 Cloudfront ID (cloudfrontID.default.cloudfront.com) 接受 abc.com 的請(qǐng)求
xxxxxxxx.aws.cloudfront.com 指向 origin.abc.com 拿數(shù)據(jù) （就是本服務(wù)器）
要是請(qǐng)求沒(méi)有 cloudfront 本地 cache, 就繼續(xù)，否則反回 cache
要是請(qǐng)求不是特定的 path ( cache behaviour)，則反回
cloudfrontID.default.cloudfront.com 向 web 服務(wù)器 (Origin) 請(qǐng)求 object
(html / css / .jpg / …)
把 header (cache-header / CORs) 也記到 cache 中
把 xxx.default.cloudfront.com 的 cache 反回到 abc.com 的客戶(hù)端
跟據(jù)在第 7) 點(diǎn) 定義的 header按時(shí)間清理緩存
跟據(jù)請(qǐng)求的來(lái)源IP，在世界各地每一個(gè)edge 上操作 1-9
這有點(diǎn)像反向代理，比如 Varnish 就在做差不多的事。只是CDN 在用 edge cache. Varnish 一般的使用情況是把文件緩存最長(zhǎng)時(shí)間，然后根據(jù) Origin 給的指令來(lái)更新緩存。這是客戶(hù)最想要的，這樣就不會(huì)有 “第一位用戶(hù)變慢” 這樣的問(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, 然后在下一位用戶(hù)有需要時(shí)，才把最近那地理位置的 edge cache 上加一個(gè) object cache. 這樣就省去一筆很大的成本。
好的 CDN 得支持 Behavior, 就是路徑不同的特性，在不同的應(yīng)用上，特別是已登錄的用戶(hù)，使用太多的 cache 會(huì)令系統(tǒng)出問(wèn)題。得跟據(jù)路徑來(lái)刪除／加速 刷新。
要是支持登錄用戶(hù)的話(huà)， Cookie 要用客戶(hù)端直接傳送到 Origin, 所以得支持 (forward cookie)
每個(gè) CDN 會(huì)有一個(gè) Default behaviour, 就是不指定情況下，都跟據(jù)這個(gè) behaviour 作出回應(yīng)。比如我們要支持用戶(hù)登錄，得把 session 通過(guò) Dynamic CDN 回傳到 origin
整體來(lái)說(shuō)，AWS Cloudfront 是個(gè)很不錯(cuò)的 CDN, 需要有的都有了。要是能支持 ESI (Edge Side Includes) 就更好了。市面上的云加速 / 云防護(hù)大約都是 Dynamic CDN 的原理，至于能加速多少，能不能支持用戶(hù)登錄，還有 Cookie/Cache-header 等問(wèn)題，就是深度用戶(hù)需要關(guān)注的地方。
下次我們可以討論如何在全局負(fù)載均衡GSLB 加上 Cloudfront 做全球化布局的動(dòng)態(tài) CDN。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/10932.html
摘要：在這篇文章內(nèi)，我站在開(kāi)發(fā)者的角度解析一下的商業(yè)化架構(gòu)。的商業(yè)化架構(gòu)首先，我們采用了分層的方式來(lái)實(shí)現(xiàn)整體架構(gòu)，包含區(qū)塊鏈層激勵(lì)層存儲(chǔ)層數(shù)據(jù)分發(fā)層音視頻等應(yīng)用層。我認(rèn)為去中心化服務(wù)的另外一種說(shuō)法就是霧計(jì)算，或者邊緣技術(shù)。 showImg(https://segmentfault.com/img/remote/1460000019213551); 目前大多數(shù)的區(qū)塊鏈項(xiàng)目，設(shè)計(jì)時(shí)更重視代幣發(fā)行...
摘要：本期大綱隨著從到千萬(wàn)用戶(hù)的業(yè)務(wù)增長(zhǎng)，通過(guò)的不同服務(wù)輕松地實(shí)現(xiàn)高性能和高可用的基礎(chǔ)架構(gòu)。方坤老師本次的主題比較偏向?qū)嵺`的基礎(chǔ)部分，假設(shè)了一個(gè)應(yīng)用從小型到中型和大型的時(shí)候，可能需要用到的服務(wù)，以及相關(guān)介紹和實(shí)踐建議。 極牛技術(shù)實(shí)踐分享活動(dòng) 極牛技術(shù)實(shí)踐分享系列活動(dòng)是極牛聯(lián)合頂級(jí)VC、技術(shù)專(zhuān)家，為企業(yè)、技術(shù)人提供的一種系統(tǒng)的線上技術(shù)分享活動(dòng)。每期不同的技術(shù)主題，和行業(yè)專(zhuān)家深度探討，專(zhuān)注...
摘要：這種情況并非完全是一個(gè)云爆發(fā)的場(chǎng)景，因?yàn)楦鶕?jù)定義，爆發(fā)意味著工作負(fù)載在一段時(shí)間內(nèi)被移動(dòng)到云端，然后最終返回到內(nèi)部部署。在這種情況下，云爆發(fā)將是其設(shè)計(jì)的固有特征。如今，公共云已迅速成為構(gòu)建IT基礎(chǔ)設(shè)施的一種簡(jiǎn)單而無(wú)障礙的方式。如果企業(yè)已經(jīng)擁有內(nèi)部部署系統(tǒng)，那么在某些時(shí)候，可能就會(huì)希望將內(nèi)部部署和外部部署整合在一起。而實(shí)現(xiàn)這一目標(biāo)的一種方法是采用云爆發(fā)，但云爆發(fā)究竟是什么？以及爆發(fā)在云端意味著什...
摘要：當(dāng)更新時(shí)，負(fù)載均衡器還被增強(qiáng)以考慮更多規(guī)則的屬性，包括協(xié)議和。以前這些字段的更改不會(huì)觸發(fā)更新，因?yàn)樨?fù)載均衡器認(rèn)識(shí)不到已經(jīng)發(fā)生了更改。 Kuberentes可謂是2017年風(fēng)頭最勁的編排工具了，隨著Kubernetes社區(qū)及各大廠商的不斷改進(jìn)、發(fā)展，Kuberentes將成為容器管理領(lǐng)域的領(lǐng)導(dǎo)者，昨天，Kubernetes官方發(fā)布了本年度第四次也是最后一次新版本的更新公告，即Kubere...
閱讀 1022·2021-11-22 14:56
閱讀 993·2021-11-11 16:54
閱讀 7793·2021-09-23 11:55
閱讀 3014·2021-09-22 15:57
閱讀 2796·2021-08-27 16:25
閱讀 674·2019-08-30 15:55
閱讀 1665·2019-08-30 15:43
閱讀 1599·2019-08-30 14:23
