Nginx 反向代理集群 & 负载均衡（Tomcat，Jetty集群）

Nginx 反向代理后端服务器集群

在 Java Web 生产环境中，假如网站的访问量很大，为了提高访问速度和稳定性，可以将多个后端服务器（tomcat，jetty等）与 Nginx 服务器进行集成，在这些 Servlet 中各自运行同一个WebApp， 共同分担 Servlet/JSP 组件任务，这些Servlet容器构成一个Cluster集群系统，能够提供高可靠性，高性能计算，负载平衡的优点；

以下以Tomcat集群为例：

假如要解决一个Tomcat中的web应用demoapp访问量很高，负载过高的问题，可以按以下形式部署服务器；

• 使用2个Tomcat（这2个Tomcat位于不同的服务器上）来做一个集群共同处理demoapp，这2个Tomcat中运行一样的demoapp应用；
  
• 使用另外一个服务器作为nginx代理服务器（或者使用以上2个Tomcat所在服务器的其中一个）；

说明：假设访问demoapp的域名为“www.demo.com”，2个Tomcat所在服务器的ip为"12.34.56.78","87.65.43.21",Tomcat端口都是8080；

1）配置 Nginx的 nginx.conf

在http节点下添加upstream节点

1

upstream demoRP{

2

    server 12.34.56.78:8080;

3

    server 87.65.43.21:8080;

4

}

 在server/location节点添加proxy_psss配置：

1

server{

2

    ......

3

    location / {

4

    ......

5

    proxy_pass http://demoRP

6

    ......

7

    }

8

}

2）两个Tomcat各自配置 server.xml

在tomcat1，tomcat2 中 server.xml 中的  Server/Service/Engine/ 节点下，添加以下<Host>节点：

1

<Host name="www.demo.com"  appBase="/tomcat/webapps/demoapp"  unpackWARs="true" autoDeploy="true">

2

    <Context path="" docBase="/tomcat/webapps/demoapp" debug="0" reloadable="true" />

3

    <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" 

4

           prefix="localhost_access_log." suffix=".txt" 

5

           pattern="%h %l %u %t "%r" %s %b" />

6

</Host>

以上nginx配置为了方便演示，忽略了动静分离配置，要实现动静分离，可以将demoapp中的静态文件目录结构拷贝到nginx服务器中，在设置location过滤；

以上配置过程没使用默认的nginx负载均衡，不能解决集群中的 session 独立匹配问题，解决方式见下面；

---

Nginx 后端集群负载均衡

nginx对于集群默认的负载形式是使用upstream方式进行负载（默认是轮询upstream的形式）， 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除，这种默认方式的可靠性比较低、负载分配不均衡；

一般在纯静态页面服务器集群才会使用这种方式，对于负载均衡，nginx还提供了以下均衡模式：

1）weight 模式

权重模式，指定upstream的轮询记录，weight和访问比例成正比，主要与后端服务器性能不均的情况；

1

upstream demoRP { 

2

     server 12.34.56.78:8080 weight=40;

3

     server 87.65.43.21:8080 weight=60;

4

}

以上配置  87.65.43.21 比 12.34.56.78 有更高的访问比例；

2）ip_hash 模式

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session独立匹配的问题；

1

upstream demoRP{

2

    server 12.34.56.78;

3

    server 87.65.43.21;

4

    ip_hash;

5

}

3） fair 模式

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

1

upstream demoRP { 

2

     server 12.34.56.78:8080;

3

     server 87.65.43.21:8080;

4

     fair；

5

}

4） url_hash 模式

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

1

upstream demoRP{

2

    server 12.34.56.78:8080;

3

    server 87.65.43.21:8080;

4

    hash $request_uri;

5

    hash_method crs32;

6

}

upstream还可以为每个设备设置状态值，部分常用的状态如下：

• down：当前的server暂时不参与负载.
  
• max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误；
  
• fail_timeout : max_fails次失败后，暂停的时间；
  
• backup： 指定为备用服务器，其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻；
  

示例如下：

1

upstream demoRP { 

2

     ip_hash;    #每个服务器之间保持session独立

3

     server 12.34.56.78:8080 weight=40 max_fails=3 fail_time_out=10;  #主服务器，权重40

4

     server 12.65.43.21:8080 weight=60;                               #主服务其，权重60

5

     server 12.34.56.11:8080 backup max_fails=2 fail_time_out=20;     #备用服务器

6

     server 12.22.34.21:8080 down;                                    #暂停使用

7

}

参考资料： http://tengine.taobao.org/book/index.html