nginx反向代理实现资源的动静分离

Posted 2021-02-03

实验拓扑图：

一个网站的资源通常分为动态资源以及静态资源两种，这次我们来配置一下反向代理服务器实现资源的动静分离。
将反向代理服务器配置成一个LNMP平台，让它即充当web网站的动态资源服务器又充当反向代理服务器，所有的动态请求都让代理服务器自身来处理，同时将处理请求缓存下来。后端的upstream server配置成负载均衡的web静态资源服务器同时实现基于cookie的客户端session绑定。

首先准备基础环境

反向代理服务器端配置：
yum install -y nginx    //安装nginx服务
systemctl start nginx
systemctl enable nginx //设置开机自动启动nginx服务
vim /etc/selinux/config
SELINUX=disabled    //关闭selinux功能
systemctl stop firewalld   //关闭防火墙
打开反向代理服务器的路由转发功能
编辑/etc/sysctl.conf文件
添加net.ipv4.ip_forward=1
sysctl -p重读文件
后端upstream server服务器配置：
yum install -y httpd  //两台服务器安装httpd服务
vim /etc/selinux/config
SELINUX=disabled    //关闭selinux功能
systemctl stop firewalld   //关闭防火墙

接下来配置LNMP平台，因为php与nginx只能使用fastcgi协议，所以这里只能使用fastcgi_pass模块与nginx对接。

yum install -y php-fpm  //安装php模块
systemctl restart php-fpm   //启动服务
systemctl enable php-fpm  //设置开机自动启动
配置反向代理功能
location ~ .php$ {
                root  /usr/share/nginx/html;   //定义php程序文件的主目录，所有php资源的请求都会从主目录开始查找
                fastcgi_pass 127.0.0.1:9000;  //指名运行php-fpm程序的服务器是哪一台，因为这里是与代理服务器配置在同一台主机上面所以此时使用本地回环地址。如果php-fpm程序使用的是单独的服务器则需要更改对应的IP地址。
                fastcgi_index  index.php;   //定义访问的主页
                fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_nam;   //调用fastcgi_param配置文件中定义的配置参数
                include fastcgi_params;  //使用fastcgi_params配置文件
        }

重新启动服务器并准备一个测试页面
systemc restart nginx
cd /usr/share/nginx/html
将原来的index.html重命名然后重新创建一个index.php的测试页面
<?php
    phpinfo();
?>
安装mariadb数据库并测试其连接性
安装php-mysql 以及maraidb-server
编辑/usr/share/nginx/html/index.php
<?php
                $conn = mysql_connect(‘127.0.0.1‘,‘root‘,‘‘);
                if ($conn)
                      echo succ;
                else
                        echo fail;
                mysql_close();      
?>

此时我们已经实现了动静分离，php资源的请求被发送到php-fpm服务器，静态资源请求被发往upstream服务器，因为php-fpm跟ngxin安装在同一台服务器上，所以php资源调度请求都被发往负载均衡调度器，如果php-fpm部署在单独的服务器，那么php资源的请求将被发送到单独部署的php服务器上。

配置动态资源的缓存

需要用到fastcgi_cache缓存模块，配置格式同样是定义在http字段中

fastcgi_cache_path  /cache/fastcgi  levels=1:1 keys_zone=fcgicache:10m  inactive=3m max_size=1g; 
在location中调用缓存功能
location ~ .php$ {
                root  /usr/share/nginx/html;  
                fastcgi_pass 127.0.0.1:9000; 
                fastcgi_index  index.php;  
                fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_nam;  
                include fastcgi_params; 
                fastcgi_cache fcgicache;
                fastcgi_cache_vaild 200 301 302 10m;
                fastcgi_cache_valid any 1m;
                fastcgi_cache_use_stale error timeout 404; 
        }
保存重启服务
创建目录
mkdir /cache/fastcgi
更改文件属主属组
chown -R nginx:nginx /cache/fastcgi

进行压力测试：

ab -n 1000 -c 100 http://172.161.1.132/index.php
当逐步提高并发量之后我们可以发现，开启缓存功能跟不开启缓存功能，请求响应的时间有明显的差别。
为了验证客户端获取的资源是从nginx反向代理服务器上获取的，还可以在nginx配置文件中的server字段中定义两个参数

add_header X-via $server_addr; 哪台主机帮忙代理
add_header X-Cache $upstream_cache_status;返回的资源是否为缓存资源

然后使用客户端向服务器请求资源同时打开浏览器的调试台查看

可以看到我们获取的资源确实为反向代理服务器的缓存提供的

接下配置两台静态服务器并实现基于客户端cookie的session绑定

为了验证效果这次两台静态服务器同样使用不同的测试页面
首先在主配置文件的http字段定义upstream负载均衡

upstream upservers {
            server 192.168.153.130 ;
            server 192.168.153.131 ;
            }
在location中进行调度
location /forum    {                    //这里我们使用url重定向来定义
            proxy_pass http://upservers/;
         }

使用客户端发送请求验证


当我们每刷新一次，反向代理服务器就会根据算法调度将请求转发到后端的upstream server服务武器上实现负载均衡。

配置基于cookie的session的会话绑定

因为nginx-sticky-module为第三方模块所以需要将此功能编译进nginx程序

首先安装openssl-devel
yum install -y openssl-devel
解压sticky安装包
tar -zxvf nginx-goodies-nginx-sticky-module-ng-1e96371de59f.tar.gz
重命名目录
mv nginx-goodies-nginx-sticky-module-ng-1e96371de59f nginx-sticky 
cd nginx-sticky
./configure --prefix=/etc/jack/nginx  --add-module=/etc/tools/nginx-sticky/
make编译，然后将原来的/nginx/sbin目录下的nginx程序替换掉
mv /etc/nginx/sbin/nginx    /etc//nginx/sbin/nginx.bak  #备份
cp /etc/tools/objs/nginx    /etc/nginx/sbin/
重新启动服务
在location中定义会话保持参数
location /forum    {   
                        sticky;   //根据具体需求还可以设置expires，domain等信息
            proxy_pass http://upservers/;
         }

配置完成后我们在使用客户端访问的时候发现请求一直被调度到第一次访问的服务器。这样就实现了基于cookie的session会话绑定。