CDN加速技术，开发人员也必须要搞清楚( 二 ) _CDN加速

假设我们的一级域名为 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 查询，在性能上是比较差的。

文章插图
经过了向多个 DNS 服务器做查询之后，整个 DNS 的解析的时间有可能会到秒级别，那我们应该解决这个问题呢？
这里，我就将我们在做数据抓取的时候是怎么解决这个性能问题告诉大家，希望给遇到同样问题的朋友一点思路。即如果是APP的项目话，我们就在APP启动的时候，对需要的域名进行预解析，然后将解析结果缓存到一个LRU缓存中， LRU缓存算法可以看前面的文章哈（LRU缓存淘汰算法，这次没人再说你不会开发）。这样，如果我们使用这个域名的时候，就先从缓存中获得对应的 IP ，如果没有的话，就再走整个DNS 的查询过程。这个时候缓存中解析结果可能会变更，这样就会缓存数据失效，我们可以起一个定时任务，去定期的更新缓存中的数据就行了。这种方案在解析性能上还是提升不少的，基本控制在200ms以内。

文章插图
通过上面我们已经知道了用户的请求是怎么到达CDN服务器的，并且针对DNS的解析进行了相关的讲解同时对于性能问题也给出了自己开发中的建议，现在我们再来看看它的整体架构图，来整体回顾下。

文章插图
怎么才能找到离用户最近的CDN节点现在，我相信大家肯定都掌握了如何让用户的请求怎么请求到CDN上了，接下来我们就要看另一个问题了，就是我们应该怎么将最近的CDN节点分给用户。
GSLB（Global Server Load Balance）这个组件就是对于部署在不同地理位置的服务器做负载均衡，其下面也可能管理了很多的本地负载均衡组件，主要有两个作用：
是负载均衡器，这个不用多少，就是分摊流量的。保证流量流经的服务器与流量的源头在地理上是很接近的。GSLB它可以通过多种策略，来保证返回的CDN 服务器与用户尽量保证在同一个地理区域。例如可以通过将用户的 IP 分为n多不同的地理区域，然后将CDN 服务器对应到各个区域里，这样就可以根据用户所在的区域来返回相应的CDN节点。现在再来看看其现在的架构图：

文章插图
当然，是否能够从 CDN 节点上获取到资源还取决于 CDN 的同步延时，一般在使用CDN时是这样的流程：
我们先通过CDN厂商提供的接口将静态资源写到CDN的其中一个节点上。CDN 自己内部会将静态资源同步到各个节点。我们知道其实只要有同步，肯定是会有延时的，一旦我们无法从选定的 CDN 节点上获取到数据，我们就不得不从源站获取数据，而用户网络到源站的网络可能会跨越多个主干网，这样不仅性能上有损耗，也会消耗源站的带宽，带来更高的研发成本。所以，我们在使用 CDN 的时候需要关注 CDN 的命中率和我们自身服务器的带宽情况。
总结，今天我们学习了使用CDN技术对我们的静态资源进行加速，主要有两个核心知识，一个是如何将用户请求落到CDN节点上，另一个则是怎么才能选择用户最近的CDN节点给用户。CDN技术并不是运维的专属，我们开发人员应该要掌握其核心知识，这样我们在遇到这方面问题时才不会显得那么不专业，如果今天的内容对你有帮助，恰好你又喜欢就关注我，我会持续更新开发中实战案例方案，谢谢。