欢迎光临
我们一直在努力

AWS 中怎么实现动态CDN

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 得支持 Behaviour, 就是路径不同的特性,在不同的应用上,特别是已登录的用户,使用太多的 cache 会令系统出问题。得跟据路径来删除/加速 刷新。

要是支持登录用户的话, Cookie 要用客户端直接传送到 Origin, 所以得支持 (forward cookie)

每个 CDN 会有一个 Default behaviour, 就是不指定情况下,都跟据这个 behaviour 作出回应。比如我们要支持用户登录,得把 session 通过 Dynamic CDN 回传到 origin 

看完上述内容,你们掌握AWS 中怎么实现动态CDN的方法了吗?如果还想学到更多技能或想了解更多相关内容,欢迎关注云搜网行业资讯频道,感谢各位的阅读!

赞(0)
【声明】:本博客不参与任何交易,也非中介,仅记录个人感兴趣的主机测评结果和优惠活动,内容均不作直接、间接、法定、约定的保证。访问本博客请务必遵守有关互联网的相关法律、规定与规则。一旦您访问本博客,即表示您已经知晓并接受了此声明通告。