1.Nginx代理服务基本概述
代理一词往往我们并不陌生，该服务我们常常用到。（比如：代理理财、代理租房、代理收货等）
在没有代理模式的情况下，都是客户端直接请求服务端，服务端直接响应客户端。而有了代理，客户端表面看是直接访问服务端，实则会通过代理代为办理然后连接服务端。代理不同于转发。
代理代为办理，以下为加上代理之后抓包的结果。1为客户端5为代理7为服务端。
nginx代理抓包.png
1.1正向代理
正向代理不用，我们主要用的是反向代理。
正向代理，内部上网，主要用来科学上网的，路由代替。它是面向客户端主要是给客户端提供服务。
客户端<--->代理--->服务端
1.2反向代理
反向代理，用于公司集群架构中。它是面向服务端主要是给服务端提供服务。
客户端--->代理<--->服务端
1.3正向与反向代理的区别
区别在于形式上服务的对象不一样
正向代理代理的对象是客户端，为客户端服务
反向代理代理的对象是服务端，为服务端服务
2.Nginx代理服务
2.1Nginx代理服务支持的协议
nginx反向代理支持的协议.png
2.2Nginx常用的反向代理模块
| 反向代理模式 | Nginx反向代理模块 |
|---|---|
| http、websocket、https | ngx_http_proxy_module |
| fastcgi（PHP） | ngx_http_fastcgi_module |
| uwsgi（Python） | ngx_http_uwsgi_module |
| grpc | ngx_http_v2_module |
3.Nginx反向代理场景实践
3.1Nginx反向代理场景
反向代理场景.png
3.2Nginx反向代理配置
3.2.1代理端的配置
[root@lb01 conf.d]# cat proxy_web.oldxu.com.conf
server {
listen 80;
server_name web.oldxu.com;
location / {
proxy_pass http://10.0.0.7:80;
proxy_http_version 1.1; #指定http传输的协议为1.1版本
proxy_set_header Host $http_host; #客户端传输时带头部
#显示真实的IP地址 也就是显示客户端的IP地址
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
3.2.2后端web配置
[root@web01 conf.d]# cat web.oldxu.com.conf
server {
listen 80;
server_name web.oldxu.com;
location / {
root /html;
index index.html;
}
}
4.Nginx反向代理参数
[root@lb01 ~]# cat /etc/nginx/proxy_params
proxy_http_version 1.1; #http协议的版本
proxy_set_header Host $http_host; #传输时加上头部(zh.wang.com)
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #传输时显示客户端真实IP
proxy_connect_timeout 30; #连接的超时时间
proxy_send_timeout 60; #发送的超时时间
proxy_read_timeout 60; #读取的超时时间
proxy_buffering on; #边传边收
proxy_buffer_size 32k; #边传边收的大小
proxy_buffers 4 128k; #边传边收的个数大小
nginx反向代理参数.png
额外扩展知识:
服务器默认有65535个端口，通常系统服务需要占用部分端口:1~10000
配置一台主机作为nginx代理服务，最多支持5w的tcp连接，因为端口数受限
配置一台后端的应用服务，最多能支持2w-3w左右的tcp连接，因为当一个请求过来
nginx代理通过随机端口--请求-->nginx应用服务--通过-->随机端口--请求-->php动态程序--通过-->随机端口-->mysql
5.Nginx负载均衡基本概述
5.1什么是负载均衡？
负载均衡Load Balance，其含义就是指将负载（工作任务）进行平摊、分担。
5.2为什么使用负载均衡？
反向代理只能给一台服务端进行代为传输，因为支持一个服务的可能是一个集群，反向代理只能针对一台服务端，所以就引入了负载均衡进行平摊流量，使得进行轮询的方式来访问web服务器。
6.负载均衡的应用场景
四层负载均衡：转发 快 传输层
转发：改写数据包 源IP 源端口 改写为 目标IP 目标端口 真实的目标IP 目标端口
七层负载均衡：代理多台 应用层
代理：代为办理，效率比四层慢，可是功能比四层多，更贴近于生活
6.1七层与四层区别
七层负载均衡效率没有四负载均衡高。
四层负载均衡没有七层负载均衡支持的功能多,比如 url匹配 设置头部信息负载均衡是基于代理实现的一种形式
7.七层负载均衡配置
1.负载配置
[root@lb01 conf.d]# cat proxy_web.oldxu.com.conf
upstream web { #创建一个虚拟池，命名为web
server 172.16.1.7:80; #通过80端口，服务由那台web服务器提供
server 172.16.1.8:80;
}
server {
listen 80;
server_name web.oldxu.com;
location / {
proxy_pass http://web; #引用虚拟池
include proxy_params; #包含剩余其余的代理参数，默认引用/etc/nginx/下
}
}
2.后端web配置 (为了区分,将两台web的站点配置的不一样,以便测试效果)
[root@web01 conf.d]# cat web.oldxu.com.conf
server {
listen 80;
server_name web.oldxu.com;
location / {
root /html;
index index.html;
}
}
编写proxy_params的配置
创建在/etc/nginx/下，默认从该目录下调用
#参数含义去翻nginx反向代理参数
[root@lb01 conf.d]# vim /etc/nginx/proxy_params
proxy_http_version 1.1;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 30;
proxy_send_timeout 60;
proxy_read_timeout 60;
proxy_buffering on;
proxy_buffer_size 32k;
proxy_buffers 4 128k;
8.七层负载均衡调度算法
负载均衡如何分配流量？
- 强与弱
- 平均
| 调度算法 | 概述 | 适用环境 |
|---|---|---|
| 轮询(平均) | 按时间顺序逐一分配到不同的后端服务器(默认) | 机器的配置一致 (web集群 硬件环境 一致) |
| weight | 加权轮询,weight值越大,分配到的访问几率越高 | 机器硬件不一致的情况下使用 (硬件 pc机) |
| ip_hash | 每个请求按访问IP的hash结果分配,这样来自同一IP的固定访问一个后端服务器 | 解决问题:能解决会话保持的问题带来新的问题:会造成后端负载不均衡 |
| url_hash | 按照访问URL的hash结果来分配请求,是每个URL定向到同一个后端服务器 | |
| least_conn | 最少链接数,那个机器链接数少 就分发 |
#示范
[root@lb01 conf.d]# cat proxy_web.oldxu.com.conf
upstream web {
ip_hash; #会随机指定一个web固定访问，不与权重同时出现，导致负载
server 172.16.1.7:80 weight=10; #它权重高，先访问它
server 172.16.1.8:80 weight=5;
}
。。。。。。。。。
9.七层负载均衡后端状态?
| 状态 | 概述 |
|---|---|
| down | 当前的server暂时不参与负载均衡 |
| backup | 预留的备份服务器 |
| max_fails | 允许请求失败的次数 |
| fail_timeout | 经过max_fails失败后, 服务暂停时间，例max_fails=2 fail_timeout=10s一起出现 |
| max_conns | 限制最大的接收连接数 |
#示范
[root@lb01 conf.d]# cat proxy_web.oldxu.com.conf
upstream web {
server 172.16.1.7:80 max_fails=2 fail_timeout=10s; #10s内请求失败两次就宕机
server 172.16.1.8:80 backup; #备胎，好的时候不用，坏了就用你
}
。。。。。。。。。
企业案例:使用nginx负载均衡时，如何将后端请求超时的服务器流量平滑的切换到另一台上？
如果后台服务连接超时，Nginx是本身是有机制的，如果出现一个节点down掉的时候，
Nginx会更据你具体负载均衡的设置，将请求转移到其他的节点上，
但是，如果后台服务连接没有down掉，但是返回错误异常码了如:504、502、500，应该如何处理。
可以在负载均衡添加如下配置：
proxy_next_upstream http_500 | http_502 | http_503 | http_504 |http_404;
意思是，当其中一台返回错误码404,500...等错误时，可以分配到下一台服务器程序继续处理，提高平台访问成功率。
出现502的原因：
nginx本身是有剔除机制, 指的是 后端的nginx没有正常工作
proxy_next_upstream nginx是正常工作,只不过后端的php或者其他程序出现问题 502
[root@lb01 conf.d]# cat proxy_web.oldxu.com.conf
upstream web {
server 172.16.1.7:80;
server 172.16.1.8:80;
}
server {
listen 80;
server_name web.oldxu.com;
location / {
proxy_pass http://web;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
}
}
10.七层负载均衡实现Redis会话共享
1、粘性session
粘性session是指Ngnix每次都将同一用户的所有请求转发至同一台服务器上，及Nginx的 IP_hash。2、session复制
即每次session发生变化时，创建或者修改，就广播给集群中的服务器，使所有的服务器上的session相同。3、session持久化 ( 慢 )
将session存储至数据库中，像操作数据一样操作session。4、session共享
缓存session至内存数据库中，使用redis ( 内存-->刷到磁盘 )，memcached (内存数据库)。
10.1解决方案
1.在 172.16.1.8 和 172.16.1.7 安装 phpmyadmin
分别进行测试-->测试登录
#1.安装phpmyadmin（web01和web02上都装）
[root@web01 conf.d]# cd /code
[root@web01 code]# wget https://files.phpmyadmin.net/phpMyAdmin/4.8.4/phpMyAdmin-4.8.4-all-languages.zip
[root@web01 code]# unzip phpMyAdmin-4.8.4-all-languages.zip
#2.配置phpmyadmin连接远程的数据库
[root@web01 code]# cd phpMyAdmin-4.8.4-all-languages/
[root@web01 phpMyAdmin-4.8.4-all-languages]# cp config.sample.inc.php config.inc.php
[root@web01 phpMyAdmin-4.8.4-all-languages]# vim config.inc.php
/* Server parameters */
$cfg['Servers'][$i]['host'] = '172.16.1.51';
chown -R www.www /var/lib/php/session
--------------------------------------------------------------------------
2.接入负载均衡 ---> 代理至后端2台主机
[root@lb01 conf.d]# cat proxy_php.oldxu.com.conf
upstream php {
server 172.16.1.7;
server 172.16.1.8;
}
server {
listen 80;
server_name php.oldxu.com;
location / {
proxy_pass http://php;
proxy_set_header Host $http_host;
}
}
--------------------------------------------------------------------------
3.发现无法正常登陆
1.解决方法:
在负载均衡上配置 ip_hash 会话保持 ( 造成用户仅访问后端的某一台主机 )
[root@lb01 conf.d]# cat proxy_php.oldxu.com.conf
upstream php {
ip_hash;
server 172.16.1.7;
server 172.16.1.8;
}
server {
listen 80;
server_name php.oldxu.com;
location / {
proxy_pass http://php;
proxy_set_header Host $http_host;
}
}
--------------------------------------------------------------------------
4.既希望能够实现流量的均摊,又希望会话的问题得以保持, 所以引入了redis
1)安装redis
[root@db01 ~]# yum install redis -y
2)配置redis
[root@db01 ~]# sed -i '/^bind/c bind 127.0.0.1 172.16.1.51' /etc/redis.conf
3)启动redis
[root@db01 ~]# systemctl enable redis
[root@db01 ~]# systemctl start redis
4) 改造php, session写本地修改为写入redis中 (所有的web上都需要配置)
前提: 已经安装过了redis的模块---> php71w-pecl-redis
1.修改php存储session至redis中
[root@web01 ~]# vim /etc/php.ini
session.save_handler = redis
session.save_path = "tcp://172.16.1.51:6379?weight=1"
2.修改php-fpm 注释默认存储session的位置
[root@web01 ~]# vim /etc/php-fpm.d/www.conf
;php_value[session.save_handler] = files
;php_value[session.save_path] = /var/lib/php/session
3.将修改后的配置文件,推送至172.16.1.8 保持一致
[root@web01 ~]# scp /etc/php.ini root@172.16.1.8:/etc/
[root@web01 ~]# scp /etc/php-fpm.d/www.conf root@172.16.1.8:/etc/php-fpm.d/
4.重启172.16.1.7 172.16.1.8两台服务器的php-fpm
[root@web02 conf.d]# systemctl restart php-fpm
5) 测试效果
1.浏览器登录测试 (ok)
2.查看redis的sessionID和 浏览器cookie中提交的sessionID是否一致
[root@db01 ~]# redis-cli
127.0.0.1:6379> keys *
1) "PHPREDIS_SESSION:38ecc8696c70a7252d943e7cb9b20f70"
查看数据库是否连接正常：
[root@web01 ~]# mysql -uall -poldxu.com -h172.16.1.51
