基于动态、静态内容结合的网络优化案例
一、引入案例................................................ 2
1.硬件环境..................................................... 2
2.软件环境..................................................... 2
二、分析问题................................................ 2
1.硬件、系统方面................................................... 2
2.网络方面............................................................... 2
3.软件架构方面....................................................... 3
4.程序配置方面....................................................... 3
三、解决问题................................................ 4
1、架构方面的调整............................................... 4
2、网站动、静分离............................................... 5
一、引入案例
1.硬件环境：DELL R710 3台、32GB内存、CPU2颗8核、磁盘SATA 600GB+2TB。
R710服务器有三台这是硬件环境，内存呢是32G，这个cpu是两颗八核，硬盘是这个SATA盘的600G两块，那个盘做了个数据盘这是硬件环境是这样子。
2. 软件环境：nginx+tomcat架构,通过nginx做负载均衡。
现象描述：
平时访问量小时，网站正常，当访问量稍大时，网站访问很慢，网站搞活动时，基本处于无法打开状态，而nginx服务器带宽占最高在30M左右，后端2个tomcat服务器占用带宽占用也在30M左右。
3. 通过对以上案例的硬件环境、软件环境、现象描述的了解，分析问题可以往以下几个方面进行思考。
1.硬件、系统方面
通过查看相关数据发现系统负载不存在问题
Mem :65973180k total ，54388372k，used，1584808k free，263808k buffe rs
Swap :16383992k tota1 Ok used，16383992k free，47631608k
Cached
2.网络方面
nginx服务器带宽占最高在30M左右，可以判断网络方面不存在问题
排除了网络方面的问题也是可以排除的，因为服务器是千兆网卡，既然千兆网卡的话，我们刚才又看到这个现象的描述，就说NG服务器最多30多兆，外网出口带宽是百兆的，所以如果说我们NG服务器这个总这样，带宽如果超过百兆的话，那可能就是其它的问题。
但是现在百兆独享，NG带宽30多兆，因此可以通过这点去判断，这网络方面其实也是没有问题的。
3.软件架构方面
nginx+tomcat架构不存在问题
软件架构，其实就是前面一个NG，然后后面两台做两个tomcat,是这样的架构才能有请求过来。架构其实很简单，没有任何别的其它方面的策略，这个架构本身也是没有问题的，很多其实网站架构都是这么来做的，但是为什么访问非常慢呢？
其实还是要考虑程序方面的问题，就这样这一个架构搭建起来之后关于在这个价格配置上面是不是解决问题的，这个也是所需要考虑的，为什么会想到这一点，因为从带宽这块儿看到一些端倪，就是Nginx服务器的占了30多兆的带宽，而后端2个tomcat服务器也占用了30M左右。
4.程序配置方面
（1）nginx服务器带宽占最高在30M左右，后端2个tomcat服务
器占用带宽占用也在30M左右这方面存在很大的问题。 因为从这个NG+tomcat来说所有的请求都是经过NG，然后再转到tomcat去，tomcat处理的都是动态的请求，动态请求不可能有30多兆这么大的流量带宽，如果说后端真是纯粹的tomcat，NG服务器那这样会远远大于30兆，而现在ng这个带宽也仅仅是30兆左右，那么通过这个对比就发现这个在程序配合是肯定是存在问题，那么针对这个问题呢，查询相关的这个日志，那怎么查询日志首先第一块儿，就是要看一下相关的这个配置文件。第二就是要查看一下这tomcat的一个日输出。
（2）所有的请求都是通过nginx转到tomcat，tomcat都是动态
请求，而带宽占最高在30M左右过大，如果后端是纯粹的，那么nginx服务器的带宽占比应大于30M。所以通过对比发现程序配置上存在问题。
（3）针对以上问题，通过查看相关日志里面的nginx配置文件、
tomcat日输出。在tomcat日输出里面发现tomcat日输出包含了静态输出，而tomcat是负责动态输出，对于静态输出功能性很差。所以本应由nginx处理的文件却转到了tomcat上，这就导致了tomcat的性能下降。带宽在30M左右对以上解释做了验证。
通过分析，找到了出现以上问题的原因，以下是如何解决问题
对nginx负载做重新分配，操作如下图所示：
upstream myserver{
ip_hash;
server172.16.100.11:8080weight=1max_fails=2fail_timeout=10s;
server172.16.100.12:8080weight=3max_fails=2fail_timeout=10s;
server172.16.100.13:8080weight=2max_fails=2fail_timeout=10s;
server172.16.100.14:8080weight=2max_fails=2fail_timeout=10s;
}
这是最终配置的一个方案，比如我们后端有三台机器，那么我们配置的方法呢，就是通过upstream，然后后面跟上myserver这个名字就是负载均衡的一个组，然后在这块做了一个简单的调试，就是做了一个权重的设置，因为后台这个tomcat每台机器的性能，如果不一样的话，可以根据后端每一个性能去做一个权值的一个划分，性能高度把它设高一点，那么划分的这个标准就通过weight这么一个参数值，weight等于一就是它的权值是一，然后max_field，那就是失败两次。
然后失败的一个评判标准就是这个fall_timeout，那就是在这个超时十秒钟这个范围之内，如果说这个NG还没有收到请求的话，就认为，这个后端tomcat的节点出现了故障。
故障连续两次发生，就会把它从那个机器里面去剔除，因为在这个故障发生的时候，看到它们这个案例的的配置，是后面没有这些属性参数配置的，那么，在这个情况下，很容易造成后端请求本身因故障，还会把请求就说不成的分类，这样一些故障节点。
那么，这种情况可能就导致了我们刚才所说的这个表面信息，网站打开非常非常慢，得了半天都打不开，那就因为它可能会把很多请求都发到了本身因故障这样的一个逃不开的结点上来，那么加了这些参数配置之后，就是如果后端节点确实故障，它就能够根据本身就可以自动检测到，然后把它给剔除出去。
Location~*\.(gifljpglpngljslcss)${
root /data/static/images/ROOT;
}
第二部分要调优就是关于网站的动静分离，那么这个其实也是要讲的一个核心，那么本案例的最终目的就是没有做网站的动静分离，所以导致开始后段流量很大，处理了很多一些静态请求资源。
而动态资源，就得不到这种即时的请求，所以导致网站对方非常非常的慢，那么做动静分离，这个东西其实是这个NG的一个强项，那么NG服务器的一个非常强劲的地方其实就是处去处理这种静态的这种数据文件，那么我们做的一个标准就是将所有的，将我们这个网站上所有的这些静态资源，不管是图片还是视频还是一些文本等等，把这些资源完全的交给这个NG去完成那么一些动态的JSP，加大请求，我们把它交给这个tomcat后端，多台tomcat的去完成。
Nginx中location匹配规则：
首先匹配=,其次匹配,然后是按文件中的顺序的正则匹配，最后是交给/通用匹配，当有匹配成功的时候，停止匹配，按当前匹配规则处理要求。
