CDN：静态资源如何加速？
CDN 的关键技术
CDN（Content Delivery Network/Content Distribution Network，内容分发网络）。
简单来说，CDN 就是将静态的资源分发到，位于多个地理位置机房中的服务器上，因此它
能很好地解决数据就近访问的问题，也就加快了静态资源的访问速度。
在大中型公司里面，CDN 的应用非常的普遍，大公司为了提供更稳定的 CDN 服务会选择
自建 CDN，而大部分公司基于成本的考虑还是会选择专业的 CDN 厂商，网宿、阿里云、
腾讯云、蓝汛等等，其中网宿和蓝汛是老牌的 CDN 厂商，阿里云和腾讯云是云厂商提供的
服务，如果你的服务部署在云上可以选择相应云厂商的 CDN 服务，这些 CDN 厂商都是现
今行业内比较主流的。
对于 CDN 来说，你可能已经从运维的口中听说过，并且也了解了它的作用。但是当让你来
配置 CDN 或者是排查 CDN 方面的问题时，你就有可能因为不了解它的原理而束手无策
了。
所以，我先来带你了解一下，要搭建一个 CDN 系统需要考虑哪两点：
1. 如何将用户的请求映射到 CDN 节点上；
2. 如何根据用户的地理位置信息选择到比较近的节点。
下面我就带你具体了解一下 CDN 系统是如何实现加速用户对于静态资源的请求的。
1. 如何让用户的请求到达 CDN 节点
首先，我们考虑一下如何让用户的请求到达 CDN 节点，你可能会觉得，这很简单啊，只需
要告诉用户 CDN 节点的 IP 地址，然后请求这个 IP 地址上面部署的 CDN 服务就可以了
啊。 但是这样会有一个问题： 就是我们使用的是第三方厂商的 CDN 服务，CDN 厂商会给
我们一个 CDN 的节点 IP，比如说这个 IP 地址是“111.202.34.130”，那么我们的电商系
统中的图片的地址很可能是这样的：“ http://111.202.34.130/1.jpg ”, 这个地址是
要存储在数据库中的。
那么如果这个节点 IP 发生了变更怎么办？或者我们如果更改了 CDN 厂商怎么办？是不是
要修改所有的商品的 url 域名呢？这就是一个比较大的工作量了。所以，我们要做的事情是
将第三方厂商提供的 IP 隐藏起来，给到用户的最好是一个本公司域名的子域名。
那么如何做到这一点呢？ 这就需要依靠 DNS 来帮我们解决域名映射的问题了。
DNS（Domain Name System，域名系统）实际上就是一个存储域名和 IP 地址对应关系
的分布式数据库。而域名解析的结果一般有两种，一种叫做“A 记录”，返回的是域名对应
的 IP 地址；另一种是“CNAME 记录”，返回的是另一个域名，也就是说当前域名的解析
要跳转到另一个域名的解析上，实际上 www.baidu.com 域名的解析结果就是一个
CNAME 记录，域名的解析被跳转到 www.a.shifen.com 上了，我们正是利用 CNAME 记
录来解决域名映射问题的， 具体是怎么解决的呢？我给你举个例子。
比如你的公司的一级域名叫做 example.com，那么你可以给你的图片服务的域名定义
为“img.example.com”，然后将这个域名的解析结果的 CNAME 配置到 CDN 提供的域
名上，比如 uclound 可能会提供一个域名是“80f21f91.cdn.ucloud.com.cn”这个域名。
这样你的电商系统使用的图片地址可以是“ http://img.example.com/1.jpg ”。
用户在请求这个地址时，DNS 服务器会将域名解析到 80f21f91.cdn.ucloud.com.cn 域名
上，然后再将这个域名解析为 CDN 的节点 IP，这样就可以得到 CDN 上面的资源数据了。
不过，这里面有一个问题： 因为域名解析过程是分级的，每一级有专门的域名服务器承担解
析的职责，所以，域名的解析过程有可能需要跨越公网做多次 DNS 查询，在性能上是比较
差的。
从“ 域名分级解析示意图”中你可以看出 DNS 分为很多种，有根 DNS，顶级 DNS 等
等。除此之外还有两种 DNS 需要特别留意：一种是 Local DNS，它是由你的运营商提供的
DNS，一般域名解析的第一站会到这里；另一种是权威 DNS，它的含义是自身数据库中存
储了这个域名对应关系的 DNS。
下面我以 www.baidu.com 这个域名为例给你简单介绍一下域名解析的过程：
一开始，域名解析请求先会检查本机的 hosts 文件，查看是否有 www.baidu.com 对应
的 IP；
如果没有的话，就请求 Local DNS 是否有域名解析结果的缓存，如果有就返回，标识是
从非权威 DNS 返回的结果；
如果没有，就开始 DNS 的迭代查询。先请求根 DNS，根 DNS 返回顶级 DNS（.com）
的地址；再请求.com 顶级 DNS，得到 baidu.com 的域名服务器地址；再从
baidu.com 的域名服务器中查询到 www.baidu.com 对应的 IP 地址，返回这个 IP 地址
的同时，标记这个结果是来自于权威 DNS 的结果，同时写入 Local DNS 的解析结果缓
存，这样下一次的解析同一个域名就不需要做 DNS 的迭代查询了。
经过了向多个 DNS 服务器做查询之后，整个 DNS 的解析的时间有可能会到秒级别， 那么
我们如何来解决这个性能问题呢？
一个解决的思路是： 在 APP 启动时，对需要解析的域名做预先解析，然后把解析的结果缓
存到本地的一个 LRU 缓存里面。这样当我们要使用这个域名的时候，只需要从缓存中直接
拿到所需要的 IP 地址就好了，如果缓存中不存在才会走整个 DNS 查询的过程。 同时， 为
了避免 DNS 解析结果的变更造成缓存内数据失效，我们可以启动一个定时器，定期地更新
缓存中的数据。
我曾经测试过这种方式， 对于 HTTP 请求的响应时间的提升是很明显的，原先 DNS 解析时
间经常会超过 1s，使用这种方式后，DNS 解析时间可以控制在 200ms 之内，整个 HTTP
请求的过程也可以减少大概 80ms～100ms。
如何找到离用户最近的 CDN 节点
GSLB（Global Server Load Balance，全局负载均衡）, 它的含义是对于部署在不同地域
的服务器之间做负载均衡，下面可能管理了很多的本地负载均衡组件。 它有两方面的作用：
一方面，它是一种负载均衡服务器，负载均衡，顾名思义嘛，指的是让流量平均分配使
得下面管理的服务器的负载更平均；
另一方面，它还需要保证流量流经的服务器与流量源头在地缘上是比较接近的。
GSLB 可以通过多种策略，来保证返回的 CDN 节点和用户尽量保证在同一地缘区域，比如
说可以将用户的 IP 地址按照地理位置划分为若干的区域，然后将 CDN 节点对应到一个区
域上，然后根据用户所在区域来返回合适的节点；也可以通过发送数据包测量 RTT 的方式
来决定返回哪一个节点。 不过，这些原理不是本节课重点内容， 你了解一下就可以了，我不
做详细的介绍。
有了 GSLB 之后，节点的解析过程变成了下图中的样子：
当然，是否能够从 CDN 节点上获取到资源还取决于 CDN 的同步延时。 一般，我们会通过
CDN 厂商的接口将静态的资源写入到某一个 CDN 节点上，再由 CDN 内部的同步机制将
资源分散同步到每个 CDN 节点，即使 CDN 内部网络经过了优化，这个同步的过程是有延
时的，一旦我们无法从选定的 CDN 节点上获取到数据，我们就不得不从源站获取数据，而
用户网络到源站的网络可能会跨越多个主干网，这样不仅性能上有损耗，也会消耗源站的带
宽，带来更高的研发成本。所以，我们在使用 CDN 的时候需要关注 CDN 的命中率和源站
的带宽情况。
推荐阅读
知识星球 | 深度连接铁杆粉丝，运营高品质社群，知识变现的工具
180Wtps超高并发、大流量生产案例 字节钱包 架构与落地方案
技术总体方案设计思路