在一个项目还是单体架构的时候，所有的js，css，image都会在一个web网站上，看起来并没有什么问题，比如下面这样：
但是当web网站流量起来的时候，这个单体架构必须要进行横向扩展，而在原来的架构中静态资源这羊毛是出在单体架构这头羊身上，所以横向多少个单体，就有多少个静态资源文件夹，比如下面这样的架构。
那这种架构有什么问题呢？ 总的来说会有如下二个问题：
1. 浏览器对单一域名的请求有并发限制。
在同一个域名下，一般来说有js，css,img,media,html等等静态资源，如果资源都挂在同一个域名下，势必会影响页面的加载速度，而且单一域名下静态资源还会带上同域名下的cookie等本不需要附加的信息。
2. 不方便管理和资源的浪费
我们知道静态资源一般来说都是很占资源空间的，尤其是用户上传的头像，csv那更是占用web服务器资源，为了应对突发情况，一般会保持web代码的3个版本的回滚策略，也就是说你需要在web1，web2，web3上同时进行3个静态资源文件夹的copy，相比单独用静态资源服务器统一管理的文件夹的情况对比，前者的磁盘资源的浪费可想而知。所以改正后的架构如下：
三：css文件和合并加载的验证
1. css文件验证
下面在nginx.conf 中配置一下静态资源的访问路径，所有静态资源都是放在/usr目录下。
location ~ ^/(images|javascript|js|css|flash|media|static)/ {
root /usr;
}
然后生成 /usr/css/top.css 文件，最终浏览可以发现配置已生效。
[root@localhost usr]# mkdir css
[root@localhost usr]# ls
bin css etc games include lib lib64 libexec local myapp sbin share src tmp
[root@localhost usr]# cd css
[root@localhost css]# rz
[root@localhost css]# ls
top.css
2. css 合并压缩
这个合并模式还需要在tengine下安装一个ngx_http_concat_module 模块，可以看下官网：http://tengine.taobao.org/document_cn/http_concat_cn.html。
我这里采用静态编译，编译之前先把之前的tengine进程给关闭掉（nginx -s stop）。
[root@localhost myapp]# cd tengine-2.2.0
[root@localhost tengine-2.2.0]# ls
AUTHORS.te CHANGES CHANGES.ru conf contrib html Makefile modules packages README.markdown tests
autoCHANGES.cn CHANGES.te configure docs LICENSE man objs READMEsrc THANKS.te
[root@localhost tengine-2.2.0]# ./configure --prefix=/usr/myapp/tengine --with-http_concat_module && make && make install
接下来只要在nginx.conf 中配置concat on，最多合并20个文件，最后 nginx -s reload 重启一下
location ~ ^/(images|javascript|js|css|flash|media|static)/ {
root /usr;
concat on;
concat_max_files 20;
concat_types text/css application/x-javascript;
}
接下来再上传一个tips.css到/usr/css目录下，然后键入url：http://192.168.23.168/css/??top.css,tips.css ，，，大功告成。
网友评论