个人博客


安装环境:4台Linux机,系统为CentOS 7.7。
Nginx版本:1.12.0

ip作用
172.16.122.101部署Nginx,代理真实服务器1、2、3
172.16.122.104真实服务器1,已经部署应用,并对外暴露http端口10900
172.16.122.105真实服务器2,已经部署应用,并对外暴露http端口10900
172.16.122.106真实服务器3,已经部署应用,并对外暴露http端口10900

1、依赖安装

1.1、gcc 安装

安装Nginx需要先将官网下载的源码进行编译,编译依赖gcc环境,如果没有gcc环境,则需要安装:

1
yum install gcc-c++

1.2、PCRE pcre-devel 安装

PCRE(Perl Compatible Regular Expressions) 是一个Perl库,包括perl兼容的正则表达式库。Nginx的http模块使用pcre来解析正则表达式,所以需要在linux上安装 pcre库,pcre-devel是使用pcre开发的一个二次开发库。Nginx也需要此库。命令:

1
yum install -y pcre pcre-devel

1.3、zlib 安装

zlib库提供了很多种压缩和解压缩的方式,Nginx使用zlibhttp包的内容进行gzip,所以需要在Centos上安装zlib库。

1
yum install -y zlib zlib-devel

1.4、OpenSSL 安装

OpenSSL是一个强大的安全套接字层密码库,囊括主要的密码算法、常用的密钥和证书封装管理功能及SSL协议,并提供丰富的应用程序供测试或其它目的使用。
Nginx不仅支持http协议,还支持https(即在ssl协议上传输http),所以需要在Centos安装OpenSSL库。

1
yum install -y openssl openssl-devel

2、下载安装Nginx

2.1、下载

下载地址:http://nginx.org/download/
选择一个版本进行下载,这里我用的是nginx-1.12.0.zip 版本。

2.2、安装

将下载的安装包上传至服务器。

1
2
tar -xvf nginx-1.12.0.tar.gz
cd nginx-1.12.0

编译

1
2
./configure --prefix=/usr/local/nginx
make && make install
  • prefix:指定安装路径,默认就是/usr/local/nginx

查看验证

1
2
cd /usr/local/nginx/sbin/
./nginx -V

结果:

1
2
3
4
5
6
[root@zxb01 sbin]# ./nginx -V
nginx version: nginx/1.12.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC)
built with OpenSSL 1.0.2k-fips 26 Jan 2017
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx

至此,Nginx安装已经完成。

3、Nginx的启停

3.1、启动

1
./nginx

浏览器访问http://172.16.122.101/,可以看到如下页面。
-w647

3.2、停止

1
2
./nginx -s quit # 待nginx进程处理任务完毕进行停止
./nginx -s stop # 先查出nginx进程id再使用kill命令强制杀掉进程

3.3、重载

Nginx的配置文件nginx.conf修改后,要想让配置生效需要重启Nginx,使用-s reload不用先停止Nginx再启动Nginx即可将配置信息在Nginx中生效,如下:

1
./nginx -s reload

3.4、其它命令

1
./nginx -h

-w768

4、http负载均衡

4.1、新增配置

修改nginx/conf/nginx.conf文件,在http{...}配置块中新增配置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
upstream backend {
server 172.16.122.104:10900;
server 172.16.122.105:10900;
server 172.16.122.106:10900;
}

server {
listen *:11000;

# 日志单独输出配置,默认输出到logs/access.log、logs/error.log
access_log /usr/local/nginx/logs/test_access.log;
error_log /usr/local/nginx/logs/test_error.log;

location / {
proxy_pass http://backend;
}
}

Nginx本地监听11000端口,然后转发到upstream中配置的后台服务器地址,默认是轮询策略。

当然这是最简单的配置,这里location定义的准入url规则是所有都接入,也可以缩小准入的url范围,比如定义location /api {...},就只能接入url后缀是/api开头的请求;Nginxurl匹配和转发规则非常灵活,可以做到改写要转发的url路径,还可以使用正则表达式。

upstream的配置这里使用了默认的策略,如果需要自定义做一些配置可以参考后面的章节内容。

4.2、负载均衡效果测试

postman调用http://172.16.122.101:11000/xxxNginx会将请求转发到对应的后端真实服务器http://172.16.122.104~6:10900/xxx,多次调用可以看到是轮询的效果。

5、upstream配置参数

5.1、主要参数

1
2
3
4
5
6
7
8
upstream backend{
server 127.0.0.1:9001 weight=1;
# 代表在10秒内请求某一应用失败2次,认为该应用宕机,后等待10秒,这期间内不会再把新请求发送到宕机应用,而是直接发到正常的那一台。
# 时间到后再有请求进来继续尝试连接宕机应用且仅尝试1次,如果还是失败,则继续等待10秒...以此循环,直到恢复。
server 127.0.0.1:9002 weight=4 max_conns=800 max_fails=2 fail_timeout=10;
server 127.0.0.1:9003 backup; # 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。
server 127.0.0.1:9004 down; # 表示当前的server暂时不参与负载。
}
  • weight:服务器权重,默认为1。
  • max_conns:最大连接数,针对单台服务器。(Nginx版本1.11.5以上)
  • max_fails:允许请求失败的次数,默认为1,当超过最大次数时,认为这台服务器不可用。
  • fail_timeout:max_fails次失败后,暂停的时间,默认为10s。
  • backup:其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。
  • down:表示当前的server暂时不参与负载。

5.2、几种负载均衡策略

5.2.1、轮询(默认方式)
1
2
3
4
5
upstream backend {
server 172.16.122.104:10900;
server 172.16.122.105:10900;
server 172.16.122.106:10900;
}
  • 在轮询中,如果服务器down掉了,会自动剔除该服务器。
  • 此策略适合服务器配置相当,无状态且短平快的服务使用。
5.2.2、权重
1
2
3
4
5
upstream backend {
server 172.16.122.104:10900 weight=1;
server 172.16.122.105:10900 weight=2;
server 172.16.122.106:10900 weight=3;
}
  • 权重越高分配到需要处理的请求越多。
  • 此策略可以与least_connip_hash结合使用。
  • 此策略比较适合服务器的硬件配置差别比较大的情况。
5.2.3、ip_hash

每个请求按访问IP的hash结果分配,这样来自同一个IP的访客固定访问一个后端服务器,有效解决了动态网页存在的session共享问题。

1
2
3
4
5
6
upstream backend {
ip_hash; # 保证每个访客固定访问一个后端服务器
server 172.16.122.104:10900 weight=1;
server 172.16.122.105:10900 weight=2;
server 172.16.122.106:10900 weight=3 max_fails=2 fail_timeout=10;
}
  • Nginx版本1.3.1之前,不能在ip_hash中使用权重(weight)。
  • ip_hash不能与backup同时使用。
  • 此策略适合有状态服务,比如session
  • 当有服务器需要剔除,必须手动down掉。
5.2.4、least_conn

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

1
2
3
4
5
6
upstream backend {
least_conn; # 把请求转发给连接数较少的后端服务器
server 172.16.122.104:10900 weight=1;
server 172.16.122.105:10900 weight=2 max_fails=2 fail_timeout=10;
server 172.16.122.106:10900 backup;
}
5.2.5、fair(需安装第三方插件)

这是比上面两个更加智能的负载均衡算法。此种算法可以依据页面大小和加载时间长短智能地进行负载均衡,也就是根据后端服务器的响应时间来分配请求,响应时间短的优先分配。Nginx本身是不支持fair的,如果需要使用这种调度算法,必须下载Nginxupstream_fair模块。

1
2
3
4
5
6
upstream backend {
fair; # 实现响应时间短的优先分配
server 172.16.122.104:10900;
server 172.16.122.105:10900;
server 172.16.122.106:10900;
}
5.2.6、url_hash(需安装第三方插件)

按访问urlhash结果来分配请求,使每个url定向到同一个后端服务器,要配合缓存命中来使用。同一个资源多次请求,可能会到达不同的服务器上,导致不必要的多次下载,缓存命中率不高,以及一些资源时间的浪费。而使用url_hash,可以使得同一个url(也就是同一个资源请求)会到达同一台服务器,一旦缓存住了资源,再次收到请求,就可以从缓存中读取。

1
2
3
4
5
6
7
upstream backend {
hash $request_uri; # 实现每个url定向到同一个后端服务器
hash_method crc32; # 指定hash算法为crc32
server 172.16.122.104:10900;
server 172.16.122.105:10900;
server 172.16.122.106:10900;
}

参考链接