Nginx企业实战，负载聚能以及软件平滑升级

冬冬的狼外婆

于 2024-07-30 19:37:34 发布

阅读量362

点赞数 2

文章标签： nginx 运维服务器

本文链接：https://blog.csdn.net/ln2915275834/article/details/140804220

版权

（一）Nginx企业实战

1.Nginx 的内置变量

2.开启 nginx 状态监听模块

（1）修改配置

进⼊ nginx 主配置⽂件（yum 和编译安装的⽂件路径不⼀样）。

找到“server { }”，添加⼀个“location { }”，也就是虚拟主机。

（2）访问测试

浏览器访问 192.168.33.110/status，查看 nginx 状态信息。

3.nginx 虚拟主机配置

⼀个“location”相当于⼀个虚拟主机，也就是⽤户访问⽹站时，点击跳转的另⼀个⻚⾯。

location 内可以添加 nginx 各种功能模块

4.nginx 反向代理配置

反向代理：⽤户直接访问反向代理服务器就可以获得⽬标服务器（后端服务器）的资源

（1）修改配置

在配置⽂件中添加⼀⾏反向代理块指令（proxy_pass），表示当访问本机地址 192.168.33.110 的 80 端⼝时即可跳转到后端服务器 192.168.33.11 的 80 端⼝上

（2）建⽴后端服务器

使⽤另⼀台虚拟机，安装 nginx ，然后进⼊ /usr/share/nginx/html/ ⽬录，修改其中的 index.html ⽂件，随便写⼊⼀条内容进⾏测试。

（3）访问测试

浏览器输⼊本机地址 192.168.33.110，将会⾃动跳转到后端服务器 192.168.33.11 上

5.nginx 访客 IP ⿊名单

（1）修改配置

作为运维⼈员，我们可以选择允许哪些⽤户 IP 来访问我们的服务器，也可以选择允许哪个⽹段的⽤户。 allow：允许 deny：拒绝在 nginx 配置⽂件的 server 模块内可以添加下⾯的内容。当访问被拒绝时，会显示 403 错误⻚⾯。

（2）访问测试

（a）因为当前服务器拒绝了 33.0 ⽹段的⽤户访问，⽽本机浏览器正是通过 33.1 ⽹关与服务器建⽴连接，所以浏览器被拒绝访问了，显示 403 错误信息

（b）使⽤也是 192.168.33.0 ⽹段的 33.11 的 YH1 主机访问服务器进⾏测试

（c）使⽤之前允许的 192.168.33.22 的 YH2 主机进⾏访问服务器测试

6.为 server 主机配置访问和错误⽇志

（1）控制⽇志参数

（a）nginx 访问⽇志主要控制参数 log_format：⽤来定义记录⽇志的格式（可以定义多种⽇志格式，取不同名字即可）

access_log：⽤来指定⽇志⽂件的路径及使⽤何种⽇志格式记录⽇志

（b）log_format ⽇志格式变量 $remote_addr：记录访问⽹站的客户端地址。

$remote_user：远程客户端⽤户名。

$time_local：记录访问时间与时区。

$request：⽤户的http请求起始⾏信息。

$status：http状态码，记录请求返回的状态码，例如：200、 301、404等。

$body_bytes_sent：服务器发送给客户端的响应body字节数。

$http_referer：记录此次请求是从哪个连接访问过来的，可以根据该参数进⾏防盗链设置。 $http_user_agent：记录客户端访问信息，例如：浏览器、⼿机客户端等。 $http_x_forwarded_for：当前端有代理服务器时，设置web节点记录客户端地址的配置，此参数⽣效的前提是代理服务器也要进⾏相关的x_forwarded_for设置

（c）access_log 访问⽇志

（d）error_log 错误⽇志

错误⽇志：error_log 不能改变.

⽇志⽂件：指定⽇志的存放⽬录

错误⽇志级别：debug、info、notice、warn、error、crit、 alert、emerg，级别越⾼记录的信息越少

⽣产环境⼀般为 warn、error、crit 这三个级别之⼀。

不要配置 info 等级较低的级别，会造成磁盘消耗

7.nginx 错误⻚⾯

nginx 的错误⻚⾯与访问⾸⻚⼀样，都有⾃⼰的索引⽂件，⼀般⽤户访问的⽹站都是对应的索引⽂件

8.location 块的匹配规则和优先级

（1）location⼤致可以分为三类

精准匹配：location = / {...}

正则匹配：location ~ / {...}

⼀般匹配：location / {...}

（2）location常⽤的匹配规则 = ：进⾏普通字符精确匹配，也就是完全匹配。

^~ ：表示普通字符匹配。使⽤前缀匹配。如果匹配成功，则不再匹配其它 location

~ ：区分⼤⼩写的匹配。

~* ：不区分⼤⼩写的匹配。

!~ ：区分⼤⼩写的匹配取⾮。

!~* ：不区分⼤⼩写的匹配取⾮。

（3）、location优先级

⾸先精确匹配 =

其次前缀匹配 ^~

其次是按⽂件中顺序的正则匹配或 *

然后匹配不带任何修饰的前缀匹配

最后是交给 / 通⽤匹配

精确>前缀>正则>⼀般>通⽤

(location = 完整路径) > (location ^~ 完整路径) > (location ~* 完

整路径) > (location ~ 完整路径) >(location 部分起始路径) >

(location /)

（4）location 示例说明

（a）location = / {}

= 为精确匹配 / ，主机名后⾯不能带任何字符串，⽐如访问 / 和

/data，则 / 匹配，/data 不匹配

再⽐如 location = /abc，则只匹配/abc ，/abc/或 /abcd不匹

配。若 location /abc，则即匹配/abc 、/abcd/ 同时也匹配

/abc/。

（b）location / {}

因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求⽐

如访问 / 和 /data, 则 / 匹配， /data 也匹配，但若后⾯是正则表

达式会和最⻓字符串优先匹配（最⻓匹配）

（c）location /file/ {}

匹配任何以 /file/ 开头的地址，匹配符合以后，还要继续往下搜

索其它 location

只有其它 location后⾯的正则表达式没有匹配到时，才会采⽤这

⼀条

（d）location /file/abc {}

匹配任何以 /file/abc 开头的地址，匹配符合以后，还要继续往

下搜索其它location只有其它 location后⾯的正则表达式没有匹配到时，才会采⽤这

⼀条。

（e）location ^~ /images/ {}

匹配任何以 /images/ 开头的地址，匹配符合以后，停⽌往下搜

索正则，采⽤这⼀条。

（f）location ~ .(gif|jpg|jpeg)$ {}*

匹配所有以 gif、jpg或jpeg 结尾的请求.然⽽，所有请求

/images/ 下的图⽚会被 location ^~ /images/ 处理，因为 ^~ 的

优先级更⾼，所以到达不了这⼀条正则。

（g）location /images/abc {}

最⻓字符匹配到 /images/abc，优先级最低，继续往下搜索其它

location，会发现 ^~ 和 ~ 存在。

（h）location ~ /images/abc {}

匹配以/images/abc 开头的，优先级次之，只有去掉 location

^~ /images/ 才会采⽤这⼀条。

（i）location /images/abc/1.html {}

匹配/images/abc/1.html ⽂件，如果和正则location ~

/images/abc/1.html 相⽐，正则优先级更⾼。

9.rewrite 重写和⽹站跳转

（1）301 永久跳转

301 永久跳转：当⽤户或搜索引擎向⽹站服务器发起浏览请求

时，服务器返回的 HTTP 数据流中头信息（index.html 等）中的

状态码的⼀种，表示本⽹⻚永久性地转移到了另⼀个地址。

rewrite 重写跳转规则

http://www.yang1314/$1：跳转到的⽬标地址，后⾯的$1代表

链参数也⼀起跳转。

⽐如访问 www.yh666.com/123 就会跳转到

www.yang1314/123 没有的话。就会直接跳转到 www.yang131

4.com

permanent：301 永久跳转

2、302 临时跳转

跟 301 永久跳转相⽐，302 就是⼀个参数的差别。

配置规则按着 301 配置⾛即可找到域名配置⽂件的Server或者

location段，适当位置添加下⾯代码:

rewrite^/(*)[http://www.yang1314.com/1](http://www.lei ge.com/$1) redirect；

10.平滑升级

（1）原理

（a）启动后完成配置加载和端⼝绑定等动作，分离出指定数量的⼯

作⼦进程，这些⼦进程会持有监听端⼝的⽂件描述符 (fd)，并通过

在该描述符上添加监听事件来接受连接。

（b）Nginx 主进程在启动完成后会进⼊等待状态，负责响应各类系

统消息，如 SIGCHLD、SIGHUPSIGUSR2 等。

（c）主进程⽀持的信号

TERM、INT：⽴刻退出

QUIT：等待⼯作进程结束后再退出

KILL：强制终⽌进程;

HUP：重新加载配置⽂件，使⽤新的配置启动⼯作进程，并逐

步关闭旧进程

USR1：重新⽣成⽇志⽂件;

USR2：启动新的主进程，实现热升级

WINCH：逐步关闭⼯作进程及⼯作进程⽀持的信号

（2）过程

（a）查看旧版nginx的编译参数;

（b）编译新版本 Nginx 源码包，安装路径需与旧版⼀致，注意: 不

要执⾏ make install;

（c）备份⼆进制可执⾏⽂件，⽤新版本的替换;

（d）确保配置⽂件⽆报错;

（e）发送USR2信号：向主进程(master) 发送USR2信号，Nginx 会

启动⼀个新版本的 master 进程和对应⼯作进程，和旧版⼀起处理请

求;

（f）发送WINCH信号：向旧的 Nginx主进程(master) 发送 WINCH

信号，它会逐步关闭⾃⼰的⼯作进程(主进程不退出)，这时所有请求

都会由新版Nginx处理;

（g）发送QUIT 信号: 升级完毕，可向旧的 Nginx 主进程(master) 发

送 (QUIT、TERM、或者KILL)信号，使旧的主进程退出;

（h）验证nginx 版本号，并访问测试.

（3）配置

（ 1 ）准备软件包并查看旧版软件

[root@YH1 ~]# ls

公共视频⽂档⾳乐 anaconda-ks.cfg nginx-

1.22.1.tar.gz #旧版nginx

模板图⽚下载桌⾯ initial-setup-ks.cfg nginx-

1.24.0.tar.gz #新版nginx

[root@YH1 nginx]# nginx -V #查看nginx版本信息及安

装的模块

nginx version: nginx/1.22.1 #当前版本为1.22.1

built by gcc 8.5.0 20210514 (Red Hat 8.5.0-15)

(GCC)

built with OpenSSL 1.1.1k FIPS 25 Mar 2021

TLS SNI support enabled

configure arguments: --prefix=/usr/local/nginx --

user=nginx --group=nginx --with-http_ssl_module --

with-http_stub_status_module --with

http_realip_module --with-stream

[root@YH1 ~]# systemctl start nginx #启动nginx[root@YH1 ~]# tar -xf nginx-1.24.0.tar.gz -C

/usr/src #解压1.24.0版本

[root@YH1 ~]# cd /usr/src/nginx-1.24.0/ #移动到

解压好的1.24.0的nginx安装包⽬录

[root@YH1 nginx-1.24.0]# ls

auto CHANGES.ru configure html man

src

CHANGES conf contrib LICENSE README

[root@YH1 nginx-1.24.0]# ./configure --

prefix=/usr/local/nginx --user=nginx --group=nginx

--with-http_ssl_module --with

http_stub_status_module --with-http_realip_module

--with-stream

......省略部分预配置信息......

[root@YH1 nginx-1.24.0]# make #预配置后进⾏编译，

不要进⾏make install编译安装

......省略部分编译信息......

[root@YH1 nginx-1.24.0]# mv

/usr/local/nginx/sbin/nginx

/usr/local/nginx/sbin/nginx.old

#此次mv修改的是1.22.1版本的nginx执⾏程序，将1.22.1nginx

程序修改为nginx.old，以防不与⼀会的新版本重名出现错误，整个

逻辑需要注意

[root@YH1 nginx-1.24.0]# cp /usr/src/nginx-

1.24.0/objs/nginx /usr/local/nginx/sbin

#将1.24.0版本的nginx的可执⾏程序复制到1.22.1版本的nginx

的程序⽬录下（2）向进程发信号实现热升级

虽然主程序完成了升级，但此时正在⼯作的 nginx 进程并未完成

升级，依旧是 1.22.1 ⽼版本的 nginx 在运⾏，所以这⾥要向⽼

版本 nginx 进程发送信号。

[root@YH1 nginx-1.24.0]# nginx -v #查询nginx版本号

nginx version: nginx/1.24.0

[root@YH1 ~]# ps aux | grep nginx | grep -v grep

#查询当前运⾏的nginx的pid号

USER PID %CPU %MEM VSZ RSS TTY

STAT START TIME COMMAND

root 7314 0.0 0.0 26660 736 ?

Ss 22:18 0:00 nginx: master process

/usr/local/nginx/sbin/nginx

nginx 7315 0.0 0.6 58824 4868 ? S

22:18 0:00 nginx: worker process

[root@YH1 ~]# kill -USR2 7314 #发送USR2信号：向⽼

版本的主进程发送该信号，nginx会启动新版本的进程与⽼版本进程

⼀起处理请求

[root@YH1 ~]# ps aux | grep nginx | grep -v grep

#看到⽼版本与新版本nginx的主进程和⼯作进程都在启动中

root 7314 0.0 0.3 26660 2672 ?

Ss 22:18 0:00 nginx: master process

/usr/local/nginx/sbin/nginx

11.防盗链

作⽤：防盗链就是防⽌别⼈盗⽤服务器中的图⽚、⽂件、视频等

相关资源。在 nginx 中，通过 location + return 实现。

nginx 7315 0.0 0.6 58824 4868 ? S

22:18 0:00 nginx: worker process #⽼版本

root 10374 0.0 0.7 26672 5996 ? S

22:34 0:00 nginx: master process

/usr/local/nginx/sbin/nginx

nginx 10375 0.0 0.6 58836 5040 ? S

22:34 0:00 nginx: worker process #新版本

[root@YH1 ~]# kill -WINCH 7314 #发送WINCH信号：向

⽼版本主进程发送该信号，它会逐步关闭⾃⼰的⼯作进程（主进程不

会退出），此时的处理请求全部交与新版本的nginx处理

[root@YH1 ~]# kill -QUIT 7314 #发送QUIT信号：向⽼

版本的主进程发送该信号，让旧版本退出

[root@YH1 ~]# ps aux | grep nginx | grep -v grep

#可以看到⽼版本的nginx已经完全退出，热升级完成

root 10374 0.0 0.7 26672 5996 ? S

22:34 0:00 nginx: master process

/usr/local/nginx/sbin/nginx

nginx 10375 0.0 0.6 58836 5040 ? S

22:34 0:00 nginx: worker process1、搭建 nginx 主服务器

实例操作需要两台主机做防盗链操作，所以这⾥我⽤我的两台主

机（server：192.168.33.100）和（YH1：192.168.33.11）做防

盗链演示操作。

下⾯是 server：192.168.33.100 主机的搭建过程，代码及解释

如下：

[root@server ~]# vim

/usr/local/nginx/conf/nginx.conf #去nginx配置⽂件中

找到nginx存放⾸⻚索引⽂件的根⽬录

43 location / {

44 root html; #nginx⾸⻚索引⽂件的

根⽬录，默认在nginx软件⽬录下，也就

是/usr/local/nginx/html

45 index index.html index.htm;

#nginx索引⽂件的格式

46 }

:q #因为配置⽂件未做修改，只是找需要的⽂件位置，所以q退出

即可，⽆需w再保存

[root@server ~]# vim

/usr/local/nginx/html/index.html #按照如下格式写

内容，什么意思不⽤细究

1 <html>2、测试访问主服务器

浏览器输⼊已经搭好的 nginx 主服务器，192.168.33.100

访问成功，如下图：

2 <head>

3 <title>192.168.33.100</title>

4 </head>

5 <body>

6 192.168.33.100 #我的server

主机IP

7 <img src="./123.jpg">

#./123.jpg表示在/usr/local/nginx/html的123.jpg图⽚⽂

件，随便导⼊⼀张图⽚改成123.jpg即可

8 </body>

9 </html>

:wq

[root@server ~]# cd /usr/local/nginx/html/ #到这

个⽬录下

[root@server html]# ls

50x.html 微信截图_20230915204153.jpg index.html

#⼿动拖⼊⼀张jpg格式的图⽚，注意格式

[root@server html]# mv 微信截图_20230915204153.jpg

123.jpg #将图⽚改名为刚才在index.html中提到的123.jpg

[root@server html]# systemctl reload nginx.service

#重载nginx，尽量以后少重启服务，避免到了企业中养成坏习惯

3、搭建模拟“盗图”的服务器

搭建 YH1：192.168.33.11 模拟“盗图”的服务器

此时需要⽤到另⼀台主机，代码及解释如下：4、测试访问“盗图”服务器

浏览器输⼊ IP，如下图：

[root@YH1 ~]# vim /usr/local/nginx/html/index.html

#知道索引⽂件位置，⽆需再去nginx主配置⽂件中查看

1 <html>

2 <head>

3 <title>192.168.33.11</title>

4 </head>

5 <body>

6 192.168.33.11

7 <img

src="http://192.168.33.11/123.jpg">

8 </body>

9 </html>

:wq #保存并退出

[root@server html]# systemctl reload nginx.service

#重载nginx，前提nginx服务已启动

5、为主服务器设置防盗链

修改被盗⽤主机（我的是 server：192.168.33.100）的 nginx 配

置⽂件，代码解释如下：

[root@server ~]# vim

/usr/local/nginx/conf/nginx.conf

35 server {

36 listen 80;

37 server_name localhost;

39 #charset koi8-r;40

41 #access_log logs/host.access.log

main;

43 location / {

44 root html;

45 index index.html index.htm;

46 }

47 #在第⼀个location下⾯添加⼀个location即可，格式如

下：

48 location ~* \.(mp3|jpg|png|gif|rar)$ {

#匹配以mp3、jpg、png、gif、rar格式的⽂件

49 valid_referers none blocked

192.168.33.100; #valid_referers参数⽤于指定允许访

问图⽚的域名，⽽none表示不允许任何外部域名访问，blocked表

示拒绝所有外部域名访问

50 if ($invalid_referer) {

#在blocked后⾯可以添加指定的域名和IP，表示允许某个IP或域名

的主机访问（本机IP为192.168.33.100）

51 return 403;

52 } #表示如果请求的

referer不在valid_referers参数指定的域名列表中，则返回403

错误

53 }

:wq #保存并退出

[root@server ~]# systemctl reload nginx.service6、清理浏览器缓存，再次访问测试

浏览器输⼊两个⽹站，⼀个被盗图的服务器 IP，⼀个盗图的服

务器 IP。

做出对⽐，可以看到 192.168.33.11 图⽚失效，⽽

192.168.33.100 图⽚可显示。

12.⽇志分割

随着访问量的增⻓，⽇志⽂件会越来越⼤，时间⻓既会影响访问

的速度，也会占⽤⼀部分磁盘空间，下⾯使⽤脚本⽅式，按天切

割 access 和 error ⽇志。

脚本⽅式：

1. 剪切⽇志后，使⽤ kill -USR1 向 nginx 发送信号重新⽣成⽇志⽂

件，同时还不影响⽹站请求处理进程

2. 错误时通过echo命令将错误显示的同时写⼊到⽇志⽂

件/var/log/messages。

3. 脚本代码及解释如下：

[root@server ~]# vim cut_nginx_logs.sh #新建⼀个脚

本⽂件

#!/bin/bash

#脚本所需环境，shell脚本必备语句

# 获取⽇期

d=$(date +%Y-%m-%d)

# 定义存储⽬录

dir="/usr/local/nginx/logs"

# 定义需要分割的源⽇志

logs_file="/usr/local/nginx/logs/access.log"

logs_error="/usr/local/nginx/logs/error.log"# 定义nginx的pid⽂件

pid_file="/usr/local/nginx/logs/nginx.pid"

#如果$dir定义的变量⽬录不存在，那么执⾏then后⾯的命令

if [ ! -d "$dir" ]

then

mkdir $dir

fi #if条件结束语

# 移动⽇志并重命名⽂件

if [ -f $pid_file ] #如果$pid_file定义的变量⽂件存在

then #那么

mv $logs_file $dir/access_$d.log

mv $logs_error $dir/error_$d.log

kill -USR1 $(cat $pid_file) #发送kill -USR1信

号给Nginx的主进程号，让Nginx重新⽣成⼀个新的⽇志⽂件

find $dir -mtime +30 | xargs rm -f #清理$dir

定义的变量⽇志⽬录下，30天以上的⽂件

else #否则

echo "Error,nginx is not working!" >>

/var/log/messages #将“nginx未运⾏”这条消息追加到系统

内核⽇志/var/log/messages

:wq

[root@server ~]# chmod +x cut_nginx_logs.sh #给脚

本⼀个可执⾏权限

[root@server ~]# crontab -e

13.反向代理及获取客户端 IP 地址

反向代理：反向代理服务器位于⽤户与⽬标服务器之间，但是对

于⽤户⽽⾔，反向代理服务器就相当于⽬标服务器，即⽤户直接

访问反向代理服务器就可以获得⽬标服务器的资源。

获取客户端 IP：经过反向代理后，由于在客户端和 web 后端服

务器之间增加了中间层（反向代理服务器），因此 web 后端服

务器⽆法直接拿到客户端的 IP，⽽通过请求获取 IP 等操作后，

即可从后端服务器获得客户端真实 IP。

1、搭建反向代理服务器

（1）⽤两台主机进⾏反向代理及测试。

⼀台反向代理服务器 server：192.168.33.100，⼀台后端服务器

YH1：192.168.33.11

0 0 * * * /usr/bin/bash /root/cut_nginx_logs.sh

#在每天的0点执⾏该脚本

[root@server ~]# ./cut_nginx_log.sh #启动脚本

[root@server ~]# cd /usr/local/nginx/logs/ #查看

⽇志是否以时间分隔

[root@server logs]# ls

access_2023-09-15.log error_2023-09-15.log

nginx.pid

access.log error.log（2）将 YH1 的 nginx ⾸⻚索引⽂件修改为如下内容：

[root@YH1 ~]# vim /usr/local/nginx/html/index.html

192.168.33.11 这⾥是真实的后端服务器YH1

:wq

（3）配置反向代理服务器 server：192.168.33.100 的 nginx 主配置

⽂件，代码及解释如下：

[root@server ~]# vim

/usr/local/nginx/conf/nginx.conf

......省略部分配置信息.......

server {

listen 80;

server_name localhost;

charset utf-8;

#access_log logs/host.access.log main;

location / {

root html;

index index.html index.htm;

proxy_pass http://192.168.33.11:80;

#在location内添加该条参数，表示为将33.100所收到的访问请求

代理转发到33.11的80端⼝

}

:wq

[root@server ~]# systemctl reload nginx.service

（4）当浏览器访问代理服务器 server：192.168.33.100 时，其实就

访问到了后端服务器 YH1：192.168.33.11 上，如下图：

2、搭建可获取客户端 IP 的服务器

（1）配置代理服务器 server：192.168.33.100 的 nginx 主配置，使

后端服务器 YH1：192.168.33.11 可获取客户端真实 IP。

proxy_pass http://192.168.33.11:80;

#在location内添加该条参数，表示为将33.100所收到的访问请求

代理转发到33.11的80端⼝

}

:wq

[root@server ~]# systemctl reload nginx.service[root@server ~]# vim

/usr/local/nginx/conf/nginx.conf

......省略部分配置信息......

location / {

root html;

index index.html index.htm;

proxy_pass http://192.168.33.11:80;

proxy_set_header X-Real-IP

$remote_addr; #代理服务器为后端服务器请求客户端真实IP

地址

proxy_set_header X-Forwarded-For

$proxy_add_x_forwarded_for;

}

:wq

[root@server ~]# systemctl reload nginx.service

（2）配置后端服务器 YH1：192.168.33.11 的 nginx 主配置

14.Nginx 的 web 缓存服务

Nginx 作为 Web 缓存服务器，它介于客户端和应⽤服务器之

间，当⽤户通过浏览器访问⼀个 URL 时，Web 缓存服务器会去

应⽤服务器获取要展示给⽤户的内容，将内容缓存到⾃⼰的服务

器上，当下⼀次请求到来时，如果访问的是同⼀个 URL，Web

缓存服务器就会直接将之前缓存的内容返回给客户端，⽽不是向

应⽤服务器再次发送请求。

Web 缓存降低了应⽤服务器、数据库的负载，减少了⽹络延

迟，提⾼了⽤户访问的响应速度，增强了⽤户的体验。

[root@YH1 ~]# vim /usr/local/nginx/conf/nginx.conf

......省略部分配置信息......

location / {

root html;

index index.html index.htm;

set_real_ip_from 192.168.33.100; #获

取客户端的真实IP来源于192.168.33.100，也可写⼀个IP范围

real_ip_header X-Forwarded-For; #⽤

于设置使⽤哪个头来替换IP地址

real_ip_recursive on; #是

否递归解析

}

:wq

[root@YH1 ~]# systemctl reload nginx.service（1）搭建反向代理缓存服务器 server：192.168.33.100

[root@server ~]# vim

/usr/local/nginx/conf/nginx.conf

......省略部分配置信息......

http {

include mime.types;

default_type application/octet-stream;

proxy_cache_path /usr/local/proxy_temp

levels=1:2 keys_zone=cache_item:200m inactive=1d

max_size=20g;

#指定缓冲路径，指定缓存⽬录级别⼆层，指定缓存块名称和⼤

⼩，指定缓存数据存储时间，指定占⽤硬盘最⼤值20g

......省略部分配置信息......

location / {

proxy_cache cache item; #指定缓

冲区

proxy_cache_key

$schemesproxy_hostsrequest_uri; #指定参数key值

proxy_cache_valid 200 5d; #返回值

200缓存5天

proxy_cache_valid 404 30s; #返回值

404缓存30秒

proxy_cache_valid any 1m; #其他的

⼀分钟（2）当反向代理缓存服务器搭建完成后，即使nginx服务关闭也可

以访问⾸⻚。

15.nginx 的 https 协议

1、⽣成密钥⽂件

proxy_pass http://192.168.33.11;

#反向代理，将请求转发给后端web服务器

}

......省略部分配置信息......

:wq

[root@server ~]# systemctl reload nginx.service

2、颁发证书

3、编辑 nginx 主配置⽂件

4、通过 https 访问⾃⼰的 IP 地址

例如我的服务器 IP：192.168.33.100，那么想要访问就是 https:

//192.168.33.100，当访问上后会显示不安全的连接-----⾼级---

-添加例外-----确认添加。

（二）Nginx负载聚能

一、负载均衡

早期的网站流量和业务功能都比较简单，单台服务器足以满足基本的需求，

但是随着互联网的发展，业务流量越来越大并且业务逻辑也跟着越来越复

杂，单台服务器的性能及单点故障问题就凸显出来了，因此需要多台服务器

进行性能的水平扩展及避免单点故障出现。

负载均衡是将负载分摊到不同的服务单元，既保证服务的可用性，又保证响

应足够快，给用户很好的体验，快速增长的访问量和数据流量催生了各式各

样的负载均衡的产品，很多专业的的负载均衡硬件提供了很好的功能，但价

格不菲，这使得负载均衡软件大受欢迎， nginx 就是其中一个，在 linux 下有

nginx 、 Ivs 、 haproxy 等服务，可以提供复杂均衡服务。

二、负载均衡原理

负载均衡 NAT （ Network Address Translation 网络地址转换）简单地说就

是将一个 IP 地址转换为另一个 IP 地址，一般用于未经注册的内部地址与合法

的、已获注册的 Internet IP 地址间进行转换。适用于解决 Internet IP 地址紧

张、不想让网络外部知道内部网络结构等的场合下。

系统的扩展可以分为纵向扩展和横向扩展。

纵向扩展：从单机的角度出发，通过增加系统的硬件处理能力来提升服

务器的处理能力 ;

横向扩展：通过添加机器来满足大型网站服务的处理能力

这里面涉及到两个重要的角色分别是 “ 应用集群 ” 和 “ 负载均衡器

应用集群：将同一应用部署到多台机器上，组成处理集群，接收负载均

衡设备分发的请求，进行处理并返回响应的数据。

负载均衡器：将用户访问的请求根据对应的负载均衡算法，分发到集群

中的一台服务器进行处理。

三、负载均衡的作用

解决服务器的高并发压力，提高应用程序的处理性能；

提供故障转移，实现高可用；

通过添加或减少服务器数量，增强网站的可扩展性；

在负载均衡器上进行过滤，可以提高系统的安全性；

1 、提高系统性能

负载均衡可以扩展网络设备和服务器的带宽，优化访问请求在服务器组之间

的分配，提高系统的反应速度和总体性能。 2 、监控服务器的运行状态

负载均衡能够监控服务器的运行状态，提高整个服务器组的可靠性。

3 、提供服务一致性

负载均衡器具有提供服务一致性的功能，负载均衡器通过读取客户端所发出

请求内的信息，进行重写报头程序然后将请求发送至合适的服务器上，该服

务器会维护着该客户端信息。在 http 通信当中，负载均衡器提供服务一致性

的功能就得到了很好的发挥，但提供该服务的途径并不是非常安全。但若将

消息加密后，负载均衡器就无法读取隐藏其中的信息了。

4 、摆脱停机时间

服务器托管公司可能会在维护期间将服务器关闭一段时间，这可能发生在业

务的高峰期。在基于云服务器中，可以在将流量引导到另一台服务器的资源

之后进行维护，前提是它们不在维护中，从而可以消除网站的停机时间。

5 、管理服务器故障

由于它具有根据需要添加或删除实例的功能，因此可以跨云平台拥有多个数

据中心。如果其中一台服务器发生故障，则可以快速移动流量，将故障服务

器的流量流入到另一台服务器中。

6 、转发功能

按照一定的算法，将客户端请求转发到不同应用服务器上，减轻单个服务器

压力，提高系统并发量。

7 、恢复添加

如检测到发生故障的应用服务器恢复工作，自动将其添加到处理用户请求队

伍中。

8 、分发流量

分发流量、请求到不同的服务器。使流量平均分配，提高整个集群的响应速

度、服务的高可用性。 四、负载均衡常用处理方式

负载均衡分为四层负载均衡和七层负载均衡。

1. 四层负载均衡是工作在 OSI 七层协议的第四层 —— 传输层，基于

IP+PORT 的负载均衡，主要工作是转发。

2. 它在接收到客户端的流量以后通过修改数据包的地址信息（目标地址和

端口和源地址）将流量转发到应用服务器。

3. 实现四层负载均衡的方式：

硬件： F5 、 BIG-IP 、 Radware 等 ;

软件： LVS 、 Nginx 、 Haproxy 等。

1. 七层负载均衡是工作在七层协议的第七层 - 应用层，基于虚拟的 URL 或主

机 IP 的负载均衡，主要工作是代理。

2. 它首先会与客户端建立一条完整的连接并将应用层的请求流量解析出

来，再按照调度算法选择一个应用服务器，并与应用服务器建立另外一

条连接将请求发送过去。

3. 实现七层负载均衡的方式：

软件： Nginx 、 Hayproxy 等。

五、四层和七层负载均衡的区别

1. 四层负载均衡数据包是在底层就进行了分发，而七层负载均衡数据包则

在最顶端进行分发，所以四层负载均衡的效率比七层负载均衡的效率要

高；

2. 四层负载均衡不识别域名，而七层负载均衡识别域名。

3. 除了四层和七层负载均衡以外其实还有二层、三层负载均衡。二层负载

均衡是在数据链路层基于 MAC 地址来实现负载均衡，三层是在网络层一

般采用虚拟 IP 地址的方式实现负载均衡。

4. 实际环境采用的方式：四层负载 (LVS) + 七层负载 (Nginx) 六、 nginx 七层负载均衡

1 、七层负载均衡基础配置

2 、负载均衡状态

[root@server] # vim /usr/local/nginx/conf/nginx.conf

worker_processes 1 ;

event {

worker_connections 1024 ；

}

http { # 七层负载均衡支持 http 、 ftp 协议

include mime.types;

default_type application/octet-stream;

sendfile on;

keepalive_timeout 65 ;

upstream qicengzu { # 服务器组，组名 qingcengzu

server 192 .168.33.11:8080; # 组内服务器 1

server 192 .168.33.22:8080; # 组内服务器 2

}

server { # 虚拟服务器

listen 80 ; # 虚拟服务器端口

server_name localhost; # 虚拟服务器名

location { # 虚拟服务器的 url 跳转

proxy_pass http://qicengzu;

# 当访问本机的 80 端口时，跳转到服务器组

}

3 、负载均衡策略

（ 1 ）轮询

（ 2 ） weight 加权

（ 3 ） ip_hash

当对后端的多台动态应用服务器做负载均衡时， ip_hash 指令能够将某

个客户端 IP 的请求通过哈希算法定位到同一台后端服务器上。

这样，当来自某一个 IP 的用户在后端 Web 服务器 A 上登录后，再访问该

站点的其他 URL ，能保证其访问的还是后端 web 服务器 A 。

注意 : 使用 ip_hash 指令无法保证后端服务器的负载均衡，可能导致有些

后端服务器接收到的请求多，有些后端服务器接受的请求少，而且设置

后端服务器权重等方法将不起作用

（ 4 ） least_conn

least_conn ：最少连接，把请求转发给连接数较少的后端服务器。轮询

算法是把请求平均地转发给各个后端，使它们的负载大致相同；但是，

有些请求占用的时间很长，会导致其所在的后端负载较高。这种情况

下， leastconn 这种方式就可以达到更好的负载均衡效果。

（ 5 ） url_hash

按访问 url 的 hash 结果来分配请求，使每个 url 定向到同一个后端服务

器，要配合缓存命中来使用。同一个资源多次请求，可能会到达不同的

服务器上，导致不必要的多次下载，缓存命中率不高，以及一些资源时

间的浪费。而使用 ur_hash ，可以使得同一个 url ( 也就是同一个资源请

求 ) 会到达同一台服务器，一旦缓存住了资源，再次收到请求，就可以从

缓存中读取。

七、 nginx 四层负载均衡

四层使用 stream 模块，与七层的 http 模块同级。

[root@localhost ~] # nginx -V # 查看版本及安装模块

nginx version: nginx/1.22.1

built by gcc 8 .5.0 20210514 (Red Hat 8 .5.0-16) (GCC)

built with OpenSSL 1 .1.1k FIPS 25 Mar 2021TLS SNI support

enabled

configure arguments: --prefix = /usr/local/nginx --

user = nginx --group = nginx--with-httpssl module --with

http_stub status_module --with-http_realip module

[root@localhost ~] # cp /usr/local/nginx/sbin/nginx

/usr/local/nginx/sbin/nginxbak # 将原

有 /usr/local/nginx/sbin/nginx 进行备份

[root@localhost ~] # cd /usr/src/nginx-1.22.1/

[root@localhost nginx-1.22.1] # Is

auto CHANGES CHANGES.ru configure html Makefile objs

conf contrib LICENSE man README src

[root@localhost nginx-1.22.1] # ./configure --

prefix=/usr/local/nginx --user=nginx --group=nginx --with

http_ssl_module --with-http_stub_status_module --with

http_realip_module --with-stream # 安装指定模块

[root@localhost nginx-1.22.1] # make # 进行编译

[root@localhost nginx-1.22.1] # cp ./objs/nginx

/usr/local/nginx/sbin/ # 将 obis 下面的 nginx 移动

到 /usr/local/nginx/sbin 下

[root@localhost nginx-1.22.1] # nginx -V # 模块添加成功

nginx version: nginx/1.22.1

built by gcc 8 .5.0 20210514 (Red Hat 8 .5.0-16) (GCC)

built with OpenSSL 1 .1.1k FIPS 25 Mar 2021TLS SNI support

enabled configure arguments: --prefix = /usr/local/nginx --

user = nginx --group = nginx--with-httpssl module --with

http_stub status_module --with-http_realip module --with

stream

[root@server ~] # vim /usr/local/nginx/conf/nginx.conf

events {

worker_connections 1024 ;

}

stream {

upstream dongtai { # 配置 dongtai 服务器组

server 192 .168.33.11:8080; # 动态资源走 tomcat 的

8080 端口

server 192 .168.33.22:8080;

}

server {

listen 81 ; # 设置监听端口

proxy_pass dongtai; # 当请求访问到本机的 81 端口时，

将请求转发到 dongtai 组

}

upstream jingtai { # 配置 jingtai 服务器组

server 192 .168.33.33:80; # 静态资源走 nginx 或

tomcat 的 80 端口

server 192 .168.33.44:80;

}

server {

listen 82 ;

proxy_pass jingtai;

}

:wq

（三）Nginx软件平滑升级

不停用业务，使用平滑升级

需要有 kill 命令的支持

kill 不仅仅用于杀死进程，还可以向软件进程发送信号

常用的 -9 和 -15 一个是强杀，一个是正常杀

kill 信号进程编号

-USR2

平滑启动一个进程，平滑升级

-WINCH 优雅关闭子进程

-QUIT

优雅关闭主进程

步骤

1. 不停止原有服务，但是必须使用原生方式启动或者更改 nginx 脚本（会创

建一个新的进程）

2. 重新编译 nginx 新版本

3. 使用 kill -USR@ 启动新版本

4. 把旧的 Nginx 子进程全部退出

5. 优雅的退出 Nginx 的老进程系统就只剩下新的 nginx 了

使用原生方式启动 nginx

# 重新加载 nginx 配置文件

sbin/nginx -c /usr/local/nginx/conf/nginx.conf 查看进程，分主进程和 work 进程

# 查看进程

[root@front logs]# ps -aux|grep nginx

root 1277 0.0 0.1 46128 1156 ? Ss 7 月 29

0:00 nginx: master process /usr/local/nginx/sbin/nginx

nginx 1278 0.0 0.2 46584 2148 ? S 7 月 29

0:00 nginx: worker process

root 1405 0.0 0.0 112828 988 pts/1 R+ 00:10

0:00 grep --color=auto nginx

上传新的版本并且解压

root@front logs] # cd

[root@front ~] # ls

anaconda-ks.cfg initserver.sh nginx-1.26.1 nginx-

1.26.1.tar.gz

[root@front ~] # wget https://nginx.org/download/nginx-

1.27.0.tar.gz

--2024-07-30 00 :16:33-- https://nginx.org/download/nginx-

1.27.0.tar.gz

正在解析主机 nginx.org (nginx.org)... 52 .58.199.22,

3 .125.197.172, 2a05:d014:5c0:2601::6, ...

正在连接 nginx.org (nginx.org)|52.58.199.22|:443... 已连接。

已发出 HTTP 请求，正在等待回应 ... 200 OK

长度： 1244887 (1.2M) [application/octet-stream]

正在保存至 : “nginx-1.27.0.tar.gz”

100 %

[ =========================================================

============= >] 1 ,244,887 115KB/s 用时 7 .6s

2024 -07-30 00 :16:42 (160 KB/s) - 已保存 “nginx-

1.27.0.tar.gz” [1244887/1244887])

[root@front ~] # ls anaconda-ks.cfg initserver.sh nginx-1.26.1 nginx-

1.26.1.tar.gz nginx-1.27.0.tar.gz

[root@front ~] # tar -zxvf nginx-1.27.0.tar.gz

nginx-1.27.0/

... 省略

nginx-1.27.0/man/nginx.8

[root@front ~] # ls

anaconda-ks.cfg initserver.sh nginx-1.26.1 nginx-

1.26.1.tar.gz nginx-1.27.0 nginx-1.27.0.tar.gz

对新版本进行编译安装，安装目录必须和旧版本一致

[root@front ~] # cd nginx-1.27.0/

[root@front nginx-1.27.0] # ./configure --

prefix=/usr/local/nginx --user=nginx --group=nginx --with

http_ssl_module --with-http_stub_status_module --with

http_realip_module --with-stream

[root@front nginx-1.27.0] # make && make install

使用 kill -USR2 启用新版本的 Nginx 的软件

kill -USR2 老版本的 pid 编号

主要功能会根据上一次的启动方式再重新运行一次之前的启动命令

重装新的版本以后，会出现新的启动工具

[root@front nginx-1.27.0] # /usr/local/nginx/sbin/nginx -v

nginx version: nginx/1.27.0

[root@front nginx-1.27.0] # /usr/local/nginx/sbin/nginx.old

-v

nginx version: nginx/1.26.1

再次查看进程，找到老版本的 pid

[root@front nginx-1.27.0] # ps -ef|grep nginx

root 1277 1 0 7 月 29 ? 00 :00:00 nginx:

master process /usr/local/nginx/sbin/nginx

nginx 1278 1277 0 7 月 29 ? 00 :00:00 nginx:

worker process

root 4412 1281 0 00 :33 pts/1 00 :00:00 grep --

color = auto nginx

# 使用老的 nginx 进程创建新的进程

[root@front nginx-1.27.0] # kill -USR2 1277

[root@front nginx-1.27.0] # ps -ef|grep nginx

root 1277 1 0 7 月 29 ? 00 :00:00 nginx:

master process /usr/local/nginx/sbin/nginx

nginx 1278 1277 0 7 月 29 ? 00 :00:00 nginx:

worker process

root 4413 1277 0 00 :34 ? 00 :00:00 nginx:

master process /usr/local/nginx/sbin/nginx

nginx 4414 4413 0 00 :34 ? 00 :00:00 nginx:

worker process

root 4418 1281 0 00 :34 pts/1 00 :00:00 grep --

color = auto nginx

此时会出现两套 master 进程，这个时候处理客户请求的就是新的 nginx 服务

了

关闭老版本的所有子进程

关闭老版本的主进程 [root@front nginx-1.27.0] # kill -WINCH 1278

[root@front nginx-1.27.0] # kill -QUIT 1277

[root@front nginx-1.27.0] # ps -ef|grep nginx

root 4413 1 0 00 :34 ? 00 :00:00 nginx:

master process /usr/local/nginx/sbin/nginx

nginx 4414 4413 0 00 :34 ? 00 :00:00 nginx:

worker process

root 4424 1281 0 00 :40 pts/1 00 :00:00 grep --

color = auto nginx

使用 curl 查看当前服务器的版本

[root@front nginx-1.27.0] # curl -I localhost

HTTP/1.1 403 Forbidden

Server: nginx/1.27.0

Date: Mon, 29 Jul 2024 16 :42:32 GMT

Content-Type: text/html; charset = utf-8

Content-Length: 153

Connection: keep-alive

冬冬的狼外婆

关注

2
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
Nginx企业实战，负载聚能以及软件平滑升级

（1）修改配置进⼊ nginx 主配置⽂件（yum 和编译安装的⽂件路径不⼀样）。找到“server { }”，添加⼀个“location { }”，也就是虚拟主机。（2）访问测试浏览器访问 192.168.33.110/status，查看 nginx 状态信息。
复制链接

扫一扫