Nginx反向代理与负载均衡

Nginx的反向代理，其实就是proxy和upstream

反向代理配置案例如下：

server {
        listen       70;
        server_name  localhost;
        location / {
			root   html;
            index  index.html index.htm;
        }
		
	location ~ /.jsp$ {
            Proxy_set_header:X-real-ip $remote_addr;
	    proxy_pass http://127.0.0.1:8080/;
            proxy_connect_timeout 3000s;
	    proxy_send_timeout 3000s;
	    proxy_read_timeout 3000s;
	    client_max_body_size 1000M;
        }
	}
}

Proxy_set_header:X-real-ip $remote_addr; 解释：请求头中的真实ip存放在X-real-ip变量中，在jsp中可以使用request.getHeader(“X-real-ip”);

proxy_pass ：是nginx代理的url地址。如上述的配置，如果在浏览器输入http://localhost:70,那么这个时候请求的url就是localhost:70,但是如果输入的是http://localhost:70/aa.jsp,那么这个时候请求的url是http://127.0.0.1:8080/aa.jsp。这样的配置可以很好的解决在实际开发过程中的掉跨域问题。

proxy_connect_timeout：默认值60s, 后端服务器连接的超时时间，发起握手等候响应超时时间

proxy_send_timeout：默认值 60s。说明：后端服务器数据回传时间，就是在规定时间之内后端服务器必须传完所有的数据

proxy_read_timeout：默认值 60s。说明：连接成功后_等候后端服务器响应时间，其实已经进入后端的排队之中等候处理（也可以说是后端服务器处理请求的时间）

 

负载均衡

upstream myapp{
	    server 192.168.5.215:8080 weight=1 max_fails=2 fail_timeout=30s;
	    server 192.168.5.215:8080 weight=1 max_fails=2 fail_timeout=30s;
	}
server {
        listen       70;
        server_name  localhost;
        location / {
		root   html;
           index  index.html index.htm;
        }
		
		location ~ /.jsp$ {
           Proxy_set_header:X-real-ip $remote_addr;
		   proxy_pass http://myapp;
        }
	}
}

负载均衡初步完毕了。upstream依照轮询（默认）方式进行负载，每一个请求按时间顺序逐一分配到不同的后端服务器。假设后端服务器down掉。能自己主动剔除。尽管这样的方式简便、成本低廉。但缺点是：可靠性低和负载分配不均衡.

除此之外，upstream还有其他的分配策略，分别例如以下：

weight（权重）

指定轮询几率，weight和訪问比率成正比，用于后端服务器性能不均的情况。例如以下所看到的。10.0.0.88的訪问比率要比10.0.0.77的訪问比率高一倍。

upstream linuxidc{ 
      server 10.0.0.77 weight=5; 
      server 10.0.0.88 weight=10; 
}

ip_hash（訪问ip）

    每一个请求按訪问ip的hash结果分配。这样每一个訪客固定訪问一个后端服务器，能够解决session的问题。

upstream favresin{ 
      ip_hash; 
      server 10.0.0.10:8080; 
      server 10.0.0.11:8080; 
}

fair（第三方）

    按后端服务器的响应时间来分配请求。响应时间短的优先分配。

与weight分配策略相似。

upstream favresin{      
      server 10.0.0.10:8080; 
      server 10.0.0.11:8080; 
      fair; 
}

url_hash（第三方）

按訪问url的hash结果来分配请求，使每一个url定向到同一个后端服务器。后端服务器为缓存时比較有效。

注意：在upstream中加入hash语句。server语句中不能写入weight等其他的參数，hash_method是使用的hash算法。

upstream resinserver{ 
      server 10.0.0.10:7777; 
      server 10.0.0.11:8888; 
      hash $request_uri; 
      hash_method crc32; 
}

upstream还能够为每一个设备设置状态值，这些状态值的含义分别例如以下：

down 表示单前的server临时不參与负载.

weight 默觉得1.weight越大，负载的权重就越大。

max_fails ：同意请求失败的次数默觉得1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误.

fail_timeout : max_fails次失败后。暂停的时间。

backup： 其他全部的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

upstream bakend{ #定义负载均衡设备的Ip及设备状态 
      ip_hash; 
      server 10.0.0.11:9090 down; 
      server 10.0.0.11:8080 weight=2; 
      server 10.0.0.11:6060; 
      server 10.0.0.11:7070 backup; 
}

// 在实际的开发项目中，负载均衡使用的是阿里云的SLB。

注意：常见的负载均衡的算法有

轮询(Round Robin)法，轮询很容易理解，将请求按顺序轮流的分配到后端服务器上，它均衡的对待后端每一台服务器，而不关心服务器实际的连接数和当前的系统负载。
随机(Random)法，通过系统随机函数，根据后端服务器列表的大小值，来随机选取其中一台进行访问，由概率统计的理论可以得知，随着调用量的增大，其实际效果越来越接近于平均分配流量到每一台后端服务器，也就是轮询的效果。
源地址哈希(Hash)法，源地址哈希的思想是获取客户端访问的ip地址值，通过哈希函数计算得到一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是要访问的服务器的序号。采用哈希法进行负载均衡，同一ip地址的客户端，当后端服务器列表不变的时候，它每次都会被映射到同一台后端服务器进行访问。
加权轮询(Weight Round Robin)法，不同的后端服务器，可能机器的配置和系统当前的负载并不相同，因此他们抗压能力也不尽相同，给配置高负载低的机器配置更高的权重，让其处理更多的请求，而低配置负载高的机器，则给其分配较低的权重，降低其系统负载，加权轮询能很好的处理这一问题，并将请求顺序且按照权重分配到后端。

加权随机(Weight Random)法，与加权轮询法类似，加权随机法也根据后端服务器不同的配置和负载情况，配置不同的权重，不同的是，其实按照权重来随机选取服务器，而非顺序。
最小连接数(Least Connections)法，最小连接数算法比较灵活和智能，由于后端服务器配置不尽相同，对于请求的处理有快有慢，它正是根据后端服务器当前的连接情况，动态的选取其中一台当前积压连接数最少的服务器，来处理当前请求，尽可能的提高后端服务器的利用效率，将负载合理的分流到每一台机器。