无数的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),新的博文会在网咖社更新,欢迎浏览。