NGINX反向代理与负载均衡

反向代理+负载

vi nginx/conf/nginx.conf

加入以下圈出部分

服务端端口：9090

nginx端口：19090

客户端访问http://XXX.XXX.XXX.XXX:19090/testurl时，反向代理到局域网的9090服务

注：如果你的服务（9090）用的tomcat版本较高（网上说9.0版本以上，不过我7.0也同样遇到），则upstream的名称（upstreamname）不可带下划线_，否则报错：

 

获取客户端真实IP

通常在java服务端获取客户端ip用如下方式：

request.getRemoteHost();

不过在nginx代理情况下，如此获取到的是nginx所在服务器ip

若想获取客户端真实ip，需要用下面2种方法：

1.nginx.conf配置+java代码：

首先nginx配置文件添加圈出参数：

location / {
            proxy_pass http://upstreamname;
            proxy_set_header X-Real-Port $remote_port;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

后端服务端代码获取使用

request.getHeader("X-Forwarded-For");

有的人觉得X-Forwarded-For和X-Real-IP在使用中没有区别，其实不然，详细解释如下：

当你使用了nginx反向服务器后，在web端使用request.getRemoteAddr()（本质上就是获取$remote_addr），取得的是nginx的地址，即$remote_addr变量中封装的是nginx的地址，当然是没法获得用户的真实ip的。但是，nginx是可以获得用户的真实ip的，也就是说nginx使用$remote_addr变量时获得的是用户的真实ip，如果我们想要在web端获得用户的真实ip，就必须在nginx里作一个赋值操作，即我在上面的配置：

proxy_set_header X-Real-IP $remote_addr;

$remote_addr 只能获取到与服务器本身直连的上层请求ip，所以设置$remote_addr 一般都是设置第一个代理上面;但是问题是，有时候是通过cdn访问过来的，那么后面web服务器获取到的，永远都是cdn 的ip 而非真是用户ip,那么这个时候就要用到X-Forwarded-For 了，这个变量的意思，其实就像是链路反追踪，从客户的真实ip为起点，穿过多层级的proxy ，最终到达web 服务器，都会记录下来，所以在获取用户真实ip的时候，一般就可以设置成 下面的配置

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 

X-Forwarded-For变量，这是一个squid开发的，用于识别通过HTTP代理或负载平衡器原始IP一个连接到Web服务器的客户机地址的非rfc标准，如果有做X-Forwarded-For设置的话,每次经过proxy转发都会有记录,格式就是client1,proxy1,proxy2以逗号隔开各个地址，由于它是非rfc标准，所以默认是没有的，需要强制添加。在默认情况下经过proxy转发的请求，在后端看来远程地址都是proxy端的ip 。也就是说在默认情况下我们使用request.getAttribute(“X-Forwarded-For”)获取不到用户的ip，如果我们想要通过这个变量获得用户的ip，我们需要自己在nginx添加配置：proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

意思是增加一个$proxy_add_x_forwarded_for到X-Forwarded-For里去，注意是增加，而不是覆盖，当然由于默认的X-Forwarded-For值是空的，所以我们总感觉X-Forwarded-For的值就等于$proxy_add_x_forwarded_for的值，实际上当你搭建两台nginx在不同的ip上，并且都使用了这段配置，那你会发现在web服务器端通过request.getAttribute(“X-Forwarded-For”)获得的将会是客户端ip和第一台nginx的ip。

那么$proxy_add_x_forwarded_for又是什么？

$proxy_add_x_forwarded_for变量包含客户端请求头中的X-Forwarded-For与$remote_addr两部分，他们之间用逗号分开。

举个例子，有一个web应用，在它之前通过了两个nginx转发，www.linuxidc.com即用户访问该web通过两台nginx。

在第一台nginx中,使用：

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

现在的$proxy_add_x_forwarded_for变量的X-Forwarded-For部分是空的，所以只有$remote_addr，而$remote_addr的值是用户的ip，于是赋值以后，X-Forwarded-For变量的值就是用户的真实的ip地址了。

到了第二台nginx，使用：

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

现在的$proxy_add_x_forwarded_for变量，X-Forwarded-For部分包含的是用户的真实ip，$remote_addr部分的值是上一台nginx的ip地址，于是通过这个赋值以后现在的X-Forwarded-For的值就变成了“用户的真实ip，第一台nginx的ip”，这样就清楚了吧。

2.nginx.conf配置+tomcat配置：

nginx配置同上，不再赘述。

tomcat配置：

tomcat中server.xml配置文件<host>内增加：

<Valve className="org.apache.catalina.valves.RemoteIpValve" remoteIpHeader="X-Real-IP"/>

不过此方法我尝试后并未实现，有时间下次再看。

 

负载策略

• 轮询(默认)

最基本的配置方法，它是upstream的默认策略，每个请求会按时间顺序逐一分配到不同的后端服务器。

参数：

在轮询中，如果服务器down掉了，会自动剔除该服务器。 缺省配置就是轮询策略。 此策略适合服务器配置相当，无状态且短平快的服务使用。 权重在轮询策略的基础上制定沦陷的几率。例如:

• weight

这里例子中，weight参数用于制定轮询的几率，weight默认值为1；weight的数值和被访问的几率成正比。

权重越高分配到需要处理的请求越多。 此策略可以与least_conn和ip_hash结合使用。

此策略比较适合服务器的硬件配置差别比较大的情况。

• ip_hash

负载均衡器按照客户端IP地址的分配方式，可以确保相同客户端的请求一直发送到相同的服务器。这样每个访客都固定访问一个后端服务器。

注：在nginx版本1.3.1之前，不能在ip_hash中使用权重（weight）。 ip_hash不能与backup同时使用。
此策略适合有状态服务，比如session。 当有服务器需要剔除，必须手动down掉。

• least_conn 最小连接

把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高。这种情况下，least_conn这种方式就可以达到更好的负载均衡效果

注：此负载均衡策略适合请求处理时间长短不一造成服务器过载的情况。 除了上面这些调度策略之后，还有一些第三方的调度策略可以集成到nginx中。

在实际运用中，需要根据不同的场景选择不同的策略，大多是多种策略结合使用以达到实际需求的性能。