Nginx反向代理和负载均衡

一、正向代理和反向代理的概念

1.1 反向代理

反向代理服务器是位于客户端和原始服务器之间的服务器。反向代理代理的对象是服务端。

对于用户而言，反向代理服务器就相当于目标服务器，直接访问反向代理服务器就可以获得目标服务器的资源。

由于客户端只知道代理服务器的地址，因此用反向代理可以对客户端隐藏服务器的IP地址。

反向代理服务器接收客户端发来的请求。

然后将其分发到内网的服务器，并将内网服务器返回的结果返回给客户端。

这在实际生产环境中应用是非常广泛的。

原理如下：

1.2 正向代理

正向代理服务器也是位于客户端和原始服务器之间的服务器。正向代理代理的对象是客户端。

客户端向代理服务器发送一个请求并指定目标服务器，这个目标服务器就是最终的服务器。

然后代理向原始服务器转交请求并将获得的内容返回给客户端。

由此看出，正向代理服务器只是做了一个请求转发的作用，而客户端是知道最终服务器的IP和端口号等信息的。

相反服务器端并不知道客户端的IP地址，它只能知道正向代理服务器的地址的IP地址。

正向代理暴露了服务器端的关键信息，系统会更容易遭受到恶意攻击。

在安全性上来说，正向代理是不如反向代理安全的。

但是正向代理也有自己的用途，这里就不赘述了。

二、使用Nginx进行反向代理配置

2.1 反向代理配置格式

server {
    listen 80;
    server_name localhost;
    location / {
   		#反向代理配置，将/匹配的请求路径转发到指定服务器
        proxy_pass http://192.168.137.129:8080;  
    }
}

最基本的格式，就是在server块中的location块中配置反向代理服务器的地址。

客户端之间访问Nginx，是没有办法知道Nginx中代理的最终服务器地址的。

上面配置的含义：

访问Nginx的80端口时，/代表任意请求路径。

根据proxy_pass反向代理的配置，会把请求转发到http://192.168.137.129:8080这台服务器上。

如何访问：

假设Nginx位于Ip为192.168.137.128的服务器上.

只需访问http://192.168.137.128就能访问到最终需要访问的 http://192.168.137.129:8080这台服务器。

三、使用Nginx代理多台服务器并进行负载均衡配置

3.1 使用Nginx代理多台服务器

Nginx除了可以代理单台服务器，也可以代理多台服务器，即代理一个服务集群。

此时Nginx的作用不仅相当于一台反向代理服务器，还相当于一个负载均衡器。

配置示例如下：

#upstream指令 能够定义需要代理的一组服务器，通常这些服务器都只是集群中实现了相同功能一个个微服务
upstream targetserver{	
    server 192.168.137.129:8080;
    server 192.168.137.129:8081;
}

server {
    listen       8082;
    server_name  localhost;
    location / {
        proxy_pass http://targetserver;	 #反向代理到刚才定义的一组服务器
    }
}

如何访问：

假设Nginx位于Ip为192.168.137.128的服务器上.

只需访问http://192.168.137.128

Nginx默认会使用轮询策略，代理到upstream中配置的其中一台服务器上。

3.2 Nginx负载均衡策略详解

轮询策略是Nginx代理多台服务器时的默认负载均衡策略。

除了轮询策略，其它轮询策略都需要手动配置。

其它负载均衡策略如下：

3.2.1 Nginx负载均衡–weight配置

upstream targetserver{	
    server 192.168.137.129:8080 weight=4;
    server 192.168.137.129:8081 weight=2;
}

只有在upstream块的配置中，给每个服务器地址后面加上weight来配置权重即可。

权重越大的服务器，会根据权重值承受更多的请求压力。

权重4和权重2的配置，也不是说192.168.137.129:8080承担的请求完全是192.168.137.129:8081的两倍。

只是在大量请求访问之下，前者承担的请求数会趋向于后者的两倍。

3.2.2 Nginx负载均衡–ip_hash配置

可以让相同IP的客户端的请求发送到相同的服务器。这样每个访客都固定访问一个后端服务器。

能够解决访客在其中一台服务器上登录了。

然后由于其它负载均衡策略把访客请求代理到别的服务器，导致登录失效的问题。

并且这样的话对于相同IP的客户端而已，session也是一致的。

upstream targetserver{	
	ip_hash;
    server 192.168.137.129:8080 ;
    server 192.168.137.129:8081 ;
}

3.3.3 Nginx负载均衡–least_conn配置

哪个服务器当前处理的连接少, 请求优先转发到这台服务器。

当有些请求较慢，对服务器压力较大的请求较多时。使用这个策略，把请求分给连接数较小的服务器。

也可以对整个系统的访问压力起到一定的缓解作用。

upstream targetserver{	
	least_conn;
    server 192.168.137.129:8080;
    server 192.168.137.129:8081;
}

3.3.4 Nginx负载均衡–generic hash配置

从用户定义的键确定请求的服务器.

该键可以是文本字符串、变量或组合。例如，密钥可以是配对的源 IP 地址和端口，也可以是 URI

upstream targetserver{	
	hash $request_uri consistent;
    server 192.168.137.129:8080 weight=4;
    server 192.168.137.129:8081 weight=2;
}

3.3.5 Nginx负载均衡–fair配置(需要第三方插件的支持)

upstream targetserver{	
	fair;
    server 192.168.137.129:8080 weight=4;
    server 192.168.137.129:8081 weight=2;
}

关于fair其实也已经很久没有更新了，用到它的场景也有限，了解即可。

3.3.6 Nginx负载均衡–组合策略

常常一种负载均衡策略可能解决不了实际问题。

而Nginx也是支持同时使用多种负载均衡策略的。

组合策略示例

# 既使用ip_hash策略，让同一ip只访问固定的服务器	
# 又使用weight策略，让性能较好的服务器承担更多的请求
upstream targetserver{	
	ip_hash;				
    server 192.168.137.129:8080 weight=4;
    server 192.168.137.129:8081 weight=2;
}

四、Nginx负载均衡其它参数配置

关于proxy_next_upstream定义的错误的解析：

server {
    listen       8082;
    server_name  localhost;
    location / {
        proxy_pass http://targetserver;	  #反向代理到刚才定义的一组服务器
        proxy_next_upstream timeout;  	  #upstream中的服务器组，故障时，被代理服务器返回的状态值
    }
}

在location块中除了配置proxy_pass(反向代理的地址)之外，其实还有很多反向代理的参数可以配置。

例如proxy_next_upstream设置被代理服务器返回的状态值，状态码可选如下：

error、timeout、invalid_header、http_500、http_502、http_503、http_504、http_404、off

可以更据业务需求自行选择。

综合示例：

upstream targetserver{	
	ip_hash;				
    server 192.168.137.129:8080 weight=2 max_fails=2 fail_timeout=20;
    server 192.168.137.129:8081 weight=2 max_fails=2 fail_timeout=10;
    server 192.168.137.129:8082 weight=2 down;
    server 192.168.137.129:8083 weight=2 backup;
}

示例配置解析：

 使用ip_hash策略，让同一ip只访问固定的服务器	
 192.168.137.129:8080的 权重为2，允许请求次数为2次，两次请求都失败以后等待20秒再去请求
 192.168.137.129:8082的 服务器状态为下线，不参与接收请求
 192.168.137.129:8083的 服务器状态为热备，当其它所有的非backup机器down或者忙的时候，才请求它