于架构图我们可以看出，我们现在使用了分布式缓存来加速动态请求的各种数据，但是，我们的系统中其实还有很多的静态资源的，并且请求量也是超级大的。例如：

1. 移动端APP，有很多的图片，小视频以及流媒体等。
2. 对于网站来说，不仅有上面那些资源之外，还有大量的HTML 文件，css文件以及Javascript文件等。

现在我们的一个商城里面，有很多的商品图片，并且详情页还有产品介绍视频，目前这些静态资源均是放在Nginx服务器上的，请求量很大，并且这些文件对于访问速度要求极高，并且占据很高的带宽。这里就会很有可能出现访问速度变慢，将带宽占满从而影响我们后端动态请求。这个时候我们就需要考虑该怎么去对这些静态资源做加速了。

如何思考加速

首先我们想一下可不可以也用分布式缓存来存储达到加速的目的呢？答案肯定是不行的，因为：

1. 图片或者视频文件大小都不小，在几兆到几百兆之间。
2. 我们的用户是遍地全国各地的甚至还有国外用户，需要让用户能很快的得到相应，即就近访问，我们不能全国各地都建机房去部署缓存，不现实。
3. 图片或视频信息文件很大，访问量又极高，这样，如果自建机房带宽肯定是会面临极大的风险。

因此，我们不能自建机房来加速静态资源，我们需要在我们的应用服务器外层加一层静态资源处理的组件，并且还能遍地全国各地让用户能就近访问，还能让这些缓存命中率很高，以至于尽量减少回源到我们自己的业务服务器，这种技术就是我们下面要说的CDN。

CDN核心技术

CDN 其实就是网络分发的一种技术，它将我们的静态资源分发到各个地理位置不同的机房服务器上，这样就能实现用户就近访问的问题，且加快静态资源的访问速度。

你可能会说，cdn这玩意我们开发又用不到，不用去掌握的吧，其实不然，建议你不要只是将自己一直放在只是开发的位置，你要有掌控全局的决心，很多cdn排查的工作都是需要资深工程师才能干的，所以你要了解这门技术，现在假如让你来配置cdn和排查CDN问题，你可能就会因为自身技术壁垒而感到束手无策。

首先，我们来看看搭建一个CDN系统需要考虑的两个关键点：

1. 怎样才能让用户请求先映射到CDN服务器上，这应该是最基本的了。
2. 怎样根据用户所处的地理位置，选出离他最近的CDN节点给用户访问。

接下来，我们就基于上面考虑点来一起来看看CDN技术是怎么实现静态资源的加速。

如何将用户请求落到CDN服务器上

12306网站我们应该都不陌生，它是有很多的cdn节点来让我们就近访问提供静态资源加速的，而我们输入的网址就是12306自己家的网址，并不是cdn的ip。这是为什么呢？因为如果直接提供给用户cdn 节点IP的话，如果IP改变怎么办，那所有的静态资源都得改变地址，这种是很不靠谱的，所以都是直接给我们服务的自己家域名，然后隐藏住CDN 的IP，那这种机制该怎么做呢？其实大家应该能猜得到，就是运用DNS 进行域名映射。

DNS（Domain Name System）就是一个存储域名和 IP 映射的分布式数据库，其中域名解析返回的结果有两种：

1. 直接返回域名对应的 IP 地址。
2. 返回另一个域名，即将当前域名解析到另一个域名，会跳转到另一个域名解析上，现在我们就是通过这种方式来解决上面域名映射问题

下面我们就来看看具体的是怎么操作的。

假设我们的一级域名为 a.com ，那么我们就可以将图片服务域名定义为“img.a.com”，然后将这个域名的解析结果配置到CDN提供的域名上。例如，ucoud提供一个这样的域名“78f98.cdn.ucloud.com.cn”，我们的系统图片地址是这个样子"img.a.com/100.jpg"。

用户在请求100.jpg 地址的时候，DNS服务器就会将这个域名解析到78f98.cdn.ucloud.com.cn 域名上，然后再将这个域名解析到CDN的IP地址，这样就得到了CDN上资源数据了。

我们知道其实DNS解析是有个问题的就是，因为域名解析过程是分好几个级别的，每一级有专门的域名服务器承担其解析的职责，所以，域名的解析过程有可能需要跨越公网做多次 DNS 查询，在性能上是比较差的。