发现我自己好像和Amazon的云服务杠上了，在使用S3云存储服务备份并保管自己的文档后，昨天晚上我又瞄上了Amazon的另一个云服务：CloudFront。

CDN是什么？CloudFront又是什么？

这一节内容适合非技术型用户。如果您是技术型用户，或者已经对CDN有了基本了解，可以跳过这一节直接阅读下文。

CDN是Content delivery network（内容分发网络）的 简称，这一技术以往只应用于大型商业性网站。通过使用这种技术，可以将网站上的静态内容（例如.html文件、.jpg图片）和动态内容（例如数据库查 询）缓存到CDN提供商位于全球各地的多个服务器上。这样当全世界不同访客访问这个网站的时候，就不再需要通过网站所在服务器读取这些内容，而是可以从就 近的CDN缓存服务器上读取，因此内容的读取速度更快，直接影响就是网页的加载速度更快。

这一系列过程都是完全自动实现的，并且在配置好后，对于网站的内容提供方（例如正在写这篇文章的我）也是完全透明的。我只需要按照正常方式撰写并发 布内容到本站，随后相配套的程序就会自动把需要缓存的内容提交到我指定的缓存服务器上；而正在阅读这篇文章的您，在打开本站文章时，会根据您的实际地理位 置和网络环境，由DNS服务器将您引导到速度最快的缓存服务器上，并从缓存服务器上直接下载显示本站页面所需的各种内容。

简而言之，通过使用CDN，可以有效提升全球各地访客打开网页的速度。因此各大门户网站、社交网站，以及网络视频站点，都会使用各种CDN技术。对 于技术实力强大，并且有充足预算的企业，可能会自行在全球各地搭建缓存服务器（Google这类技术型公司的主要做法）；但对于技术实力不强，或者预算不 充足，或者内容数量过少，自建CDN网络不划算的企业，则会考虑使用专门的CDN服务提供商，借助提供商建好的网络进行加速，并按照一定策略为此付费。

CloudFront则是由Amazon提供的一套覆盖全球的CDN网络。该服务属于一种非常彻底的云计算服务，可以根据流量和请求数量进行收费，并且相对来说费用还算低廉，因此适合小型公司或个人。

根据介绍，Amazon的CloudFront目前在全球下列地区建立了提供CloudFront服务的数据中心：

美国

• 维吉尼亚周，阿什本
• 德克萨斯州，达拉斯/沃斯堡
• 佛罗里达州，杰克逊维尔
• 加利福尼亚州，洛杉矶
• 佛罗里达州，迈阿密
• 纽约
• 新泽西州，纽瓦克
• 加利福尼亚州，帕罗奥图
• 华盛顿州，西雅图
• 密苏里州，圣路易斯

欧洲

• 阿姆斯特丹
• 都柏林
• 法兰克福
• 伦敦
• 巴黎

亚洲

• 香港
• 东京
• 新加坡

因此只要使用CloudFront服务，就等于可以通过上述遍布全球主要地区的缓存服务器，为您的网站提供加速服务。

如何收费？

首先有一个问题需要注意：如果使用CloudFront服务，等于需要创建一个“来源服务器-AmazonS3-缓存服务器”这样的路径。当您的网 站内容（来源服务器）上增添了新内容后，这些内容会被同步到Amazon S3的指定Bucket中，这一过程将产生S3的数据传入流量费用（一次性），S3的请求处理费（一次性），以及数据存储费用（按月收取，只要该数据存在 于S3网络中）。而当位于某地的访客访问您的网站时，访客将向距离自己最近的缓存服务器发出请求，如果所请求的文件是首次被请求，此时缓存服务器将从S3 中检索被请求的文件，并将其自动复制到一台缓存服务器。这一过程将产生S3的数据传出流量费用（一次性），S3的请求处理费（一次性），以及缓存服务器将 内容发送给访客的流量费用（每个请求一次）和请求处理费（每个请求一次）。随后，这台缓存服务器会将被请求的文件复制到整个CloudFront网络的全 部缓存服务器，这一过程不需要收费。再随后，全球各地的访客访问网站时，向缓存服务器发送请求，处理每个此类请求都将收费，而将所请求的文件传输给访客， 也将按照流量计费。

因此来说，这种工作模式下，对于S3，等于需要支付在S3中存储所有缓存内容的费用（按月收取），支付S3的传入和传出网络流量，以及S3的传入和 传出请求处理费用各一次（从来源服务器传入S3的请求收取一次，从S3传到某一台缓存服务器的请求收取一次）。随后，当文件被复制到缓存服务器后，每当访 客访问网站，并从缓存服务器（无论该服务器位于地球上的哪个位置）请求内容时，将按照访客所请求的服务器所在地的费率，并结合请求的文件大小，按此收取流 量费和请求处理费。

听起来比较复杂，关键这里面涉及到S3的相关处理，以及CloudFront缓存服务器的相关处理。但实际上只要将这一过程分开进行理解，实际上也简单多了。

至于具体的费率，可以在这里看到：

 

针对不同地区的缓存服务器，具体的流量和处理费用有略微差异，其中日本的费用最贵。在估算实际费用时需要注意，此时需要考虑您网站访客的主要来源， 例如对于大部分中国用户，取决于具体的ISP和网络环境，往往会通过位于香港/新加坡，或日本的缓存服务器获取内容。我的这个博客位于美国 DreamHost的虚拟主机上，很多人都曾经反应过访问速度比较慢。在决定使用该服务前，通过DreamHost的流量统计功能发现，我的博客每月产生 的网络流量在15 GB左右。如果全部这些流量都通过费用最贵的日本服务器进行处理，我每月需要为此付出多少钱？

本网站的整个目录下所有文件，包含php，以及png等，全部加起来大概在257 MB左右，就算整200 MB。这些文件在S3中的存储和传入及传出费用基本可以忽略不计（S3的文件存储费用的最小统计单位为GB，而请求处理费则取决于文件数量，，每个文件产 生两个请求，请求费的计费单位都是成千上万个请求才记为0.01美元）。由于访客访问网站时所请求的每个文件（PHP、脚本、CSS、图片等）都会产生一 个请求，就算平均每个页面会产生50个请求（毕竟我的博客上完全由博客本身提供的内容数量并不多），假设每天的页面浏览量是300个。其实这些数据通过 Google Analysis都可以获得一个准确值，但我也懒得去找了，用近似值计算好了。

因此每月，通过CloudFront分发15 GB数据的费用为：15 GB * $0.201/GB = $3.015

另外，每月产生的请求数量为 50 * 300 * 30 = 450000个，这些请求都是HTTP请求，因此请求处理费用为 450000 / 10000 * 0.0095 =  $0.4275

所以就算本站的所有访客都通过位于日本的缓存服务器获取内容，我每月需要付出 3.015 + 0.4275 = $3.44，约合￥22。当然，实际上不可能所有访客都使用日本的缓存服务器，因此只要数据量和浏览量没有太大变化，每月实际的付出只会低于这个价格，绝 对不会高于这个价格。在大部分城市，这个价钱可能只够一个人在外面吃一顿像样的午饭，换来的是网站访问速度的极大提升，我觉得还是挺划算的。不过也幸好我 自己的博客本身访问量不是太大，并且只是发布一些自己写的东西，没有什么推广的念头，想必未来的访问量也不会大到哪里去。

如何使用？针对Dreamhost用户

虽然我曾经觉得DreamHost的主机最近一直遇到稳定性问题，不过大部分时候他家的服务还是不错的，例如常用Web应用的一键式安装，以及各种增值功能的使用，CloudFront就包含在内。

如果您也使用DreamHost提供的虚拟主机或VPS，那就最简单了。开通CloudFront帐户，然后在DreamHost网站登录到后台 Panel，在左侧导航栏中找到Goodies栏目，然后单击“CloudFront”，随后可以看到下图所示界面（如果尚未开通该功能，所看到的界面与 下图有所不同，但我已经开通了，首次开通时候忘记截图，所以只能提供开通后的截图，大致还是一样的）。

 

• Sub-domain Amazon should serve your files from：这里设置的是，在CDN生效后，别人访问CDN中内容时使用的域名，并且该域名必须是网站顶级域名下的一个二级域名。首先从右侧下拉菜单中选择 一个想要用CDN加速的网站（如果你这个帐号下有多个网站的话），然后在左侧输入一个有效的二级域名。
• Where you’ll upload files to：这里设置的是，要将DreamHost主机上哪个目录下的文件（先复制到S3，然后自动）复制到CDN缓存服务器中。因此这里首先需要用左侧的下拉 菜单选择承载了该网站的帐户，然后在右侧输入该帐户Home目录下的网站相对路径。这里指定的目录下的所有内容，以及以后新增的或者修改过的内容，都会被 DreamHost的主机自动同步到S3。
• AWS Account to bill：这个选项在首次设置时不会显示，该选项的用途是，指定要将该CDN使用的所有相关费用记在哪个Amazon帐户名下。因此只有在设置完毕后才能看到这个选项。
• AWS Account Access Key ID/Secret Key：这个就不用说了吧，用于访问Amazon云服务所需的必要凭据。

提供这些必要信息，并点击“Create”按钮后，DreamHost的主机就会使用该Key在您的S3中新建一个Bucket，并将指定目录下的所有内容都复制到这个Bucket中。复制完毕后会发出邮件通知。

至此，全部设置工作就都搞定了。不需要任何其他设置，只需要等待片刻，该服务就会直接生效。

如何使用？针对WordPress用户

通过上面的方法，只要您使用DreamHost的主机，无论在上面运行什么应用，都可以直接获得加速。

但如果您没有使用DH，不过使用WordPress，那么也可以通过WP插件的方式实现类似结果。如果没有用DH，也没有用WP，那我就不知道该怎么做了，暂时没有研究过，并且也没条件进行试验。

言归正传，要让其他主机中运行的WP借助CloudFront进行加速，需要按顺序安装并配置两个插件：WP Super Cache，以及CDN Sync Tool。通过WP后台的插件安装即可找到并安装这两个插件。其实我本来是想用这种方法的，但由于实在不同开发，尤其是不懂Linux和PHP，运行过程 中遇到的一些错误无法解决，最终才退而求其次，使用DH直接提供的功能。当然，这也不是唯一的实现方式，类似的插件有很多，都能提供这种功能。

由于没有试验成功，也不好说具体要怎么做，因此大致说一下实现思路：

WP Super Cache插件在这里的功能是，使用URL Rewriting功能，将指向可缓存文件的链接由原始主机修改为CloudFront。也就是说，假设在WP中发布了一篇文章，其中包含一张图片，该图 片的原始URL是“https://www.awsgood.com/wp-content/uploads/picture.jpg”，那么这个插件 可以自动将该链接的域名部分进行更换，把“https://www.awsgood.com”更换为“http: //xxxxx.cloudfront.net”。这样当访客浏览页面时，就会自动转为向最近的CloudFront服务器请求这张图片，并借此实现加 速。

而CDN Sync Tool插件的主要功能就是决定将哪些文件复制到S3，以及在什么时候进行复制。

因此通过配合使用这两个插件，访客就能在正确的缓存服务器上找到自己需要的内容。而我所遇到的问题，是因为DH主机不支持Fileinfo，我不懂 PHP开发，不知道这是做什么的，只知道与MIME类有关，由于该问题导致CDN Sync Tool无法将内容复制到S3。不过在网上搜索了半天，做了多个实验，依然无法搞定，最终只有作罢了。

两种方法的对比

前一种方法固然比较简单，但存在一定的局限。后一种方法比较强大，因为并不是被限定为只能用特定的插件，而是可以根据实际需要，做到完全掌控。因此主要说说DH提供的自动化方式有哪些局限吧。

DH提供的方法，由于简化了大部分操作，因此有很多东西只能使用默认设置。例如在S3中自动创建Bucket时无法指定要使用的数据中心，而且在向 S3复制数据时无法选择使用标准服务还是更便宜的低冗余服务。实际上在CDN应用中，S3只是在来源服务器和缓存服务器之间充当文件中转站，因此在选择 Bucket所在的数据中心时，选择一个存储费用最低的足矣，那就是US Standard，这也是DH的默认设置。不过服务级别的选择就不同了，默认情况下，DH会直接将文件使用标准级别保存，可靠性一堆“9”的那个，相对来 说更贵一些，但也完全没必要。因此在同步完所有数据后，还可以登录AWS后台，或者使用其他客户端浏览器，手工将存储级别改为使用“RRS”低冗余存储。

 

另外则体现在要同步的文件的选择上。DH后台提供的功能只允许我们指定某个目录，并将该目录下的所有文件全部同步。但这有些不够灵活，尤其是在内容 非常多，而有些内容不想用CDN加速的时候。CDN Sync Tool等类似插件则提供了更强大的自定义功能，甚至可以针对搜索引擎的蜘蛛机器人禁用CDN加速。也就是说，人类访问的时候进行加速，而蜘蛛就只让它访 问原始服务器。现在的蜘蛛活动越来越频繁，也许这会造成一笔不小的开销。

现在本博客的全部内容都已经转移到CloudFront了，但DNS的生效可能需要一段时间。因此在未来几天里，如果您之前访问本站感觉速度慢，但随后访问的速度有好转，还请您能留个言让我知道，并让我能愿意继续用这个服务。谢谢。