Nginx除了实现基本的Web Server功能之外还可以作为正向代理与反向代理。
正向代理与反向代理的区别在于代理的对象不一样。正向代理的对象是客户端,反向代理的对象是服务端。
做正向代理时,当客户端发起请求其访问目标应该是后端真实服务器;
做反向代理时,客户端发起请求其目标应该是代理服务器本身,但由代理服务器把后端真实服务器上的数据发给了客户端。
反向代理通常是作为负载均衡来分发流量给后端的应用程序服务器,以此来提高性能。比如前端是一台Nginx作为负载均衡的分发器,后端是多台Apache搭建的Web Server,当访问流量很大时,就让Nginx分发请求给后端多台服务器,让它们分工响应。Nginx实现负载均衡用到的模块是proxy_pass代理模块,通过该模块将客户端请求转发到一组upstream服务池,所以还需要用到ngx_http_upstream_module模块,该模块只能配置于http字段中,支持的代理方式有proxy_pass,fastcgi_pass,memcached_pass。
一、Nginx常用负载均衡算法:
1、轮询(默认算法):每个请求会依次分配给后端不同的应用程序服务器,不理会后端服务器的实际压力
2、加权轮询:权重越大的服务器,被分配到的次数就会越多,通常用于后端服务器性能不一致的情况
3、IP HASH:当同IP进行重复访问时会被指定到上次访问到的服务器,可以解决动态网站SESSION共享问题
二、upstream模块中的常用参数说明:
server:负载均衡后端服务器的IP或域名,不写端口的话默认是80。高并发场景用域名,再通过DNS进行负载均衡
weight:后端服务器权重,默认为1,权重越大接收的请求越多。例:weight=5
max_fails:检查节点的健康状态并允许请求失败的次数,达到该次数就将节点下线。默认为1,0表示禁止失败尝试。例:max_fails=2
fail_timeout:max_fails失败次数达到限制后暂停该节点服务的时间,默认是10秒。例:fail_timeout=10s
backup:热备配置,当服务池中所有服务器均出现问题后会自动上线backup服务器
down:标志服务器不可用,不参与负载均衡。这个参数通常配合IP_HASH使用
max_conns:限制最大连接数,通常对后端服务器硬件不一致的情况进行配置
upstream linuxe_backend {
server 192.168.1.110 down; #该节点不可用
server 192.168.1.120 backup; #其他节点挂了后该节点自动上线
server 192.168.1.130 max_failes=1 fail_timeout=10s weight-5;
server backend1.linuxe.cn 8080 weight=3
}
三、Nginx负载均衡的几种调度算法,如果调度策略使用不当会对后端节点造成压力过大:
1、轮询负载,也是默认的负载均衡配置
http { #upstream模块包含在http模块下
upstream myserver{ #定义upstream名字,下面会引用
server 192.168.1.100; #指定后端服务器地址
server 192.168.1.110; #指定后端服务器地址
server 192.168.1.120; #指定后端服务器地址
}
server {
listen 80;
server name www.myserver.com;
location / {
proxy_pass http://myserver; #引用upstream
}
}
}
在上面的例子中,当用户访问www.myserver.com站点时,Nginx会负载平衡分配给后端的三个服务器。使用ab做压力测试可以看到在加了负载均衡后Time per request(每个请求平均消耗时间)降低、Request per second(每秒请求数)提升。如果没有配置upstream模块而只使用proxy_pass模块,可以实现反向代理的作用。
2、加权负载均衡
http {
upstream myserver{
server 192.168.1.100 weight=3; #指定后端服务器地址,权重为3
server 192.168.1.110;
}
server {
listen 80;
server name www.myserver.com;
location / {
proxy_pass http://myserver;
}
}
}
在上面配置中,每3个请求都分配给192.168.1.100,然后第4个请求会分配给192.168.1.110,如此循环下去。
3、IP HASH负载均衡
upstream myserver {
ip_hash; #采用IP HASH算法
server 192.168.1.100;
server 192.168.1.110;
server 192.168.1.120;
}
如果需要将客户与后端一台服务器“绑定”起来,可以使用ip-hash负载平衡。这样可以确保来自相同客户机的请求总是指向相同的服务器除非该服务器不可用。
4、基于URL的HASH,当客户端多次访问同一个地址时分配到固定的节点
upstream myserver {
hash $request_uri;
server 192.168.1.100;
server 192.168.1.110;
server 192.168.1.120;
}
5、最少连接数轮询,哪个节点当前的连接数少就分配给哪个节点处理
http{
upstream sampleapp {
least_conn;
server <>;
server <>;
}
....
server{
listen 80;
...
location / {
proxy_pass http://sampleapp;
}
}
四、如何获取客户端真实IP
由于Nginx作为了反向代理,帮客户取到数据并反馈给客户,所以在后端的服务器访问日志中记录的将会是Nginx这台负载均衡服务器的IP而不是客户端真实IP,要解决这个问题的话就需要使用proxy_set_header模块。
proxy_set_header:让后端服务器能获取到前端用户真实IP,而不只是代理服务器的IP。配置示例如下(还需将后端Apache日志格式中的%h替换为%{X-Real-IP}i):
location /{
proxy_pass http://localhost:8080/web/;
#以下三个proxy_set_header配置项是重点
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_body_buffer_size:客户端请求主体缓冲区大小
proxy_connect_timeout:代理服务器和后端真实服务器握手连接超时时间
proxy_send_timeout:后端服务器回传数据给Nginx的时间,需要在设置的时间范围内发送完所有数据,否则Nginx将断开连接
proxy_read_timeout:代理服务器和后端服务器连接成功后,等待后端服务器响应时间
五、Nginx高可用的实现:
利用backup标签可以实现高可用,当所有节点挂掉后backup服务器会自动接管服务,当有任意一台节点恢复后backup也会自动放弃服务
http {
upstream myserver{
server 192.168.1.100
server 192.168.1.110 backup;
}
server {
listen 80;
server name www.myserver.com;
location / {
proxy_pass http://myserver;
}
}
}
从上面多个配置示例来看Nginx的upstream模块相当于是建立一个服务池,把后端的服务器都放在池子里,而proxy模块则是从这个池子里调用这些服务器。
六、线上配置示例:
#先在nginx.conf中定义一组upstream
upstream pre-cloud_Backend {
server pre-cloud.website.com:8080;
ip_hash;
check interval=5000 rise=1 fall=3 timeout=30000;
check_http_expect_alive http_2xx http_3xx; #tengine的健康检查模块
}
#conf.d/下定义一个文件
server{
listen 80;
server_name cloud.website.com;
limit_conn perserver 10000;
location / {
proxy_next_upstream error timeout http_503 http_504 http_502;
proxy_connect_timeout 500s;
proxy_read_timeout 500s;
proxy_send_timeout 500s;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass http://pre-cloud_Backend;
}
}