如何在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。