资讯专栏INFORMATION COLUMN

如何在AWS 中实现动态CDN

netScorpion / 1198人阅读

摘要:最近又火起来,原因是用户对网络响应时间的要求深化。今天主要分享的是第点动态在年开始在支持动态,意思就是可以把也存到上,用户拿到和静态文件都在上,不需要向服务器请求。下次我们可以讨论如何在全局负载均衡加上做全球化布局的动态。

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为例子作一下说明。

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

在 xxxxxxxx.aws.cloudfront.com 以下的 Cloudfront ID (cloudfrontID.default.cloudfront.com) 接受 abc.com 的请求

xxxxxxxx.aws.cloudfront.com 指向 origin.abc.com 拿数据 (就是本服务器)

要是请求没有 cloudfront 本地 cache, 就继续,否则反回 cache

要是请求不是特定的 path ( cache behaviour),则反回

cloudfrontID.default.cloudfront.com 向 web 服务器 (Origin) 请求 object

   (html / css / .jpg / …)

把 header (cache-header / CORs) 也记到 cache 中

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

跟据在第 7) 点 定义的 header按时间清理缓存

跟据请求的来源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。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/10932.html

相关文章

  • 《周四橄榄球之夜》流媒体视频拆解:Twitch VS Amazon Prime

    摘要:去年亚马逊在其平台上开始直播流媒体周四橄榄球之夜。最近,亚马逊开始通过在亚马逊和上举办周四橄榄球之夜来进行自我竞争提醒亚马逊在年以约亿美元收购了。 showImg(https://segmentfault.com/img/bVbkHCz?w=900&h=500);文 / Phil Cluff 译 / 王月美 原文链接:https://mux.com/blog/thursday... 文...

    elisa.yang 评论0 收藏0
  • PPIO 商业化架构解析

    摘要:在这篇文章内,我站在开发者的角度解析一下的商业化架构。的商业化架构首先,我们采用了分层的方式来实现整体架构,包含区块链层激励层存储层数据分发层音视频等应用层。我认为去中心化服务的另外一种说法就是雾计算,或者边缘技术。 showImg(https://segmentfault.com/img/remote/1460000019213551); 目前大多数的区块链项目,设计时更重视代币发行...

    toddmark 评论0 收藏0
  • 从零到千万用户的云端(AWS)基础架构最佳实践

    摘要:本期大纲随着从到千万用户的业务增长,通过的不同服务轻松地实现高性能和高可用的基础架构。方坤老师本次的主题比较偏向实践的基础部分,假设了一个应用从小型到中型和大型的时候,可能需要用到的服务,以及相关介绍和实践建议。 极牛技术实践分享活动 极牛技术实践分享系列活动是极牛联合顶级VC、技术专家,为企业、技术人提供的一种系统的线上技术分享活动。每期不同的技术主题,和行业专家深度探讨,专注...

    ZHAO_ 评论0 收藏0
  • 一文看懂:云爆发的定义与应用

    摘要:这种情况并非完全是一个云爆发的场景,因为根据定义,爆发意味着工作负载在一段时间内被移动到云端,然后最终返回到内部部署。在这种情况下,云爆发将是其设计的固有特征。如今,公共云已迅速成为构建IT基础设施的一种简单而无障碍的方式。如果企业已经拥有内部部署系统,那么在某些时候,可能就会希望将内部部署和外部部署整合在一起。而实现这一目标的一种方法是采用云爆发,但云爆发究竟是什么?以及爆发在云端意味着什...

    LeanCloud 评论0 收藏0
  • 数人云|一年4更,如此勤奋的Kuberentes,1.9版更新前瞻

    摘要:当更新时,负载均衡器还被增强以考虑更多规则的属性,包括协议和。以前这些字段的更改不会触发更新,因为负载均衡器认识不到已经发生了更改。 Kuberentes可谓是2017年风头最劲的编排工具了,随着Kubernetes社区及各大厂商的不断改进、发展,Kuberentes将成为容器管理领域的领导者,昨天,Kubernetes官方发布了本年度第四次也是最后一次新版本的更新公告,即Kubere...

    Ku_Andrew 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<