无数的cache节点再加上调度就是一个cdn，当然这玩意如果放在运营商里面就是个cache，一来可以帮运营商节省流量，节省其到别的运营商的回源带宽，二来提高用户的用户体验，让用户访问速度更快，结构图如下：

CDN的cache节点(http)结构及工作原理总结（图自画）_第1张图片

整个用户访问过程总结如下：

   用户访问，先进行域名解析。我们通过运营商处的LDNS(local dns)，将要缓存的域名forword到我方DNS设备上，然后根据我方DNS上的策略设置，将要缓存的域名通过轮训、哈希或指定分组的方式解析成不同的反向代理服务器地址，将解析结果返回给客户端浏览器，浏览器再通过解析到的IP去进行资源访问。

主要有三个模块

引导模块：在运营商的DNS（也是网民使用的DNS）上，将要缓存的域名forword到我方DNS上，进行域名引导，我方DNS会通过心跳检测后端反向代理的存活情况，使用哈希、轮序或分组进行域名解析分配，当某台负载设备心跳断掉后，就不会分配请求过去了，直接回源或者转到兄弟设备上服务，不会影响用户服务。

负载模块：对我方DNS分发过来的请求进行负载，通过url哈希（避免资源重复存储），分配给下级的缓存代理服务器，通过心跳检查后端缓存代理服务器是否存活，如果后端死掉，将直接代理回源或分配给兄弟缓存代理服务器，不会影响用户服务；

缓存代理服务器：对负载服务器分发过来的请求进行处理，服务器上挂载了磁盘进行数据存储，请求过来后先查看本地磁盘是否存储了这个资源，如果存储了直接从磁盘读取后吐给前段的负载服务器，如果没有这个资源，就通过本机安装的bind去根域进行解析，然后进行回源，回源后将资源吐给前端负载，如果符合缓存规则，同时会在本地存储一份，前端负载将资源吐给客户端浏览器。


优化建议：其实通过结构图可以看出，如果负载层处理的不好，浪费了一层设备不说，还会影响服务质量。因此在优化上，如果保留负载nginx层，可以在nginx加上最热资源的缓存配置，用指令proxy_cache_min_uses来设置，至于后面到底设置多少合适可以根据业务需要去测试。第二种优化方式直接去掉负载nginx层，直接ats反向代理提供服务，但这时由于ats不是做负载的选手，无法对特定域名做7层处理，所以会遇到一些问题。第三种优化手段同样是去掉负载层，不过可以将nginx和ats装在一台服务器上，nginx正常使用upstream通过url的hash方式向集群里的ats分发请求，虽然会增加一些服务器间的流量，但是解决了域名7层处理和负载问题，至于到底哪种最合身，根据业务情况自己测试，我们线上后面两种都有在跑，服务良好，无客户报障。

自建个人原创站运维网咖社(www.net-add.com)，新的博文会在网咖社更新，欢迎浏览。