【3】nginx正向代理和反向代理

279 阅读5分钟

反向代理、正向代理模型

反向代理

描述:反向代理是指以代理服务器来接受连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给请求连接的客户端,此时代理服务器对外就表现为一个反向代理服务器,而且整个过程对于客户端而言是透明的。

隧道式代理:一进一出一个口

正向代理

描述:正向代理意思是一个位于客户端和原始服务器(origin server)之间的服务器,为了从原始服务器取得内容,客户端向代理发送一个请求并指定目标(原始服务器),然后由代理向原始服务器转交请求并将获得的内容返回给客户端。

简单的说类似于采用VPN来访问google:

区别正向代理、反向

都是站在客户端的角度,看代理服务器是帮客户端代理,还是帮服务端代理

lvs(DR模型)

lvs嵌套在CentOS中

反向代理在系统架构中的应用场景

负载均衡

描述:负载均衡也是Nginx常用的一个功能。简单而言就是当有2台或以上服务器时,根据规则随机的将请求分发到指定的服务器上处理,负载均衡配置一般都需要同时配置反向代理,通过反向代理跳转到负载均衡。

而Nginx目前支持自带3种负载均衡策略还有2种常用的第三方策略。

使用proyx_pass进行代理配置

浏览器访问localhost就会跳转到 www.atguigu.com,同时域名没有变化(不支持https)

可以有多个server。然后根据策略、调度。

负载均衡基本配置(轮询案例)

httpds,负载均衡的name?,通过name匹配upstream?

访问(localhost)192.168.44.101,反复刷新界面即可看到效果(雨露均沾)

负载均衡策略

  • weight:权重
  • down : 当前server暂不参与负载均衡
  • backup : 预留的备份服务器; 其它所有的非backup机器down或者忙的时候,请求backup机器。
  • max_fails : 请求失败次数限制
  • fail_timeout : 经过max_fails后服务暂停时间
  • max_conns : 限制最大的连接数

简单实例:

upstrem weiyigeek {
  server weiyigeek.top:8080 down;
  server weiyigeek.top:8081 backup;
  server weiyigeek.top:8082 max_fails=1 fail_timeout=10s max_conns=1024;
  server weiyigeek.top:8083 weight=1
  server weiyigeek.top:8084 weight=2
  server unix:/tmp/backend3;
} 

负载均衡调度算法

  • 轮询:默认算法按时间顺序逐一分配到不同的后端服务器;
  • 加权轮询:Weight值越大,分配到访问几率越高;
  • ip_hash:为每一个请求访问的IP的hash结果分配,可以将来自一个IP的固定访问一个后端服务器;
  • url_hash:需要安装模块安装访问的URL的hash结果来分配,这样每个URL定向到同一个后端服务器
  • least_conn:按照某台机器最少连接数的进行分配访问;
  • hash关键数值: hash 自定义 KEY

方式1: 轮询

RR(默认轮询)每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉能自动剔除。

upstream test {
  server weiyigeek.top:8080;
  server weiyigeek.top:8081;
}

server {
  listen  81;
  server_name  weiyigeek.top;
  client_max_body_size 1024M;
  location / {
    proxy_pass http://test;
    proxy_set_header Host $host:$server_port;
  }
} 

方式2:权重

权重指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。 例如

upstream test {
  server weiyigeek.top:8081 weight=1;
  server weiyigeek.top:8080 weight=9;  #那么10次一般只会有1次会访问到8081,而有9次会访问到8080
} 

方式3: ip_hash

ip_hash 会话粘连, 上面的2种方式都有一个问题,那就是下一个请求来的时候请求可能分发到另外一个服务器,当我们的程序不是无状态的时候(采用了session保存数据),这时候就有一个很大的很问题了,比如把登录信息保存到了session中,那么跳转到另外一台服务器的时候就需要重新登录了,所以很多时候我们需要一个客户只访问一个服务器,那么就需要用iphash了,iphash的每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。

# 会话粘粘可以理解为用户持续访问一个后端机器
upstream test {
  ip_hash;
  server weiyigeek.top:8080;
  server weiyigeek.top:8081;
} 

方式4:fair

fair(第三方)按后端服务器 的响应时间来分配请求,响应时间短的优先分配。

upstream backend {
  fair;
  server weiyigeek.top:8080;
  server weiyigeek.top:8081;
} 

方式5:url_hash

url_hash(第三方):按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。

在upstream中加入hash语句,server语句中不能写入weight等其他的参数,hash_method是使用的hash算法

upstream backend {
  hash $request_uri;
  hash_method crc32;
  server weiyigeek.top:8080;
  server weiyigeek.top:8081;
} 

方式6:url_hash

描述: 将请求分配到连接数最少的服务上。

upstream  dalaoyang-server {
  least_conn;
  server    weiyigeek.top:10001;
  server    weiyigeek.top:10002;
} 

以上6种负载均衡各自适用不同情况下使用,所以可以根据实际情况选择使用哪种策略模式,不过fair和url_hash需要安装第三方模块才能使用.

动静分离

动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来,动静资源做好了拆分以后,我们就可以根据静态资源的特点将其做缓存操作,这就是网站静态化处理的核心思路;

upstream test{
  server weiyigeek.top:8080;
  server weiyigeek.top:8081;
}

server {
  listen       80;
  server_name  weiyigeek.top;
  location / {
      root   e:wwwroot;//文件夹路径
      index  index.html;
  }

  # 所有静态请求都由nginx处理,存放目录为nginx中的html
  location ~ .(gif|jpg|jpeg|png|bmp|swf|css|js)$ {
      root    e:wwwroot;
  }
  # 例子,比如
  #location /css{
  	#root html;
    #index index.html index.htm;
  #}
  

  # 所有动态请求都转发给tomcat处理
  location ~ .(jsp|do)$ {
      proxy_pass  http://test;
  }
  error_page   500 502 503 504  /50x.html;
  location = /50x.html {
      root   e:wwwroot;
  }
} 

HTML以及图片和css以及js放到wwwroot目录下,而tomcat只负责处理jsp和请求,

例如当我们后缀为gif的时候,Nginx默认会从wwwroot获取到当前请求的动态图文件返回,当然这里的静态文件跟Nginx是同一台服务器,我们也可以在另外一台服务器,然后通过反向代理和负载均衡配置过去就好了,只要搞清楚了最基本的流程,很多配置就很简单了

location匹配顺序

  • 多个正则location直接按书写顺序匹配,成功后就不会继续往后面匹配
  • 普通(非正则)location会一直往下,直到找到匹配度最高的(最大前缀匹配)
  • 当普通location与正则location同时存在,如果正则匹配成功,则不会再执行普通匹配
  • 所有类型location存在时,“=”匹配 > “^~”匹配 > 正则匹配 > 普通(最大前缀匹配)
location ~*/(css|img|js) {
  root /usr/local/nginx/static;
  index index.html index.htm;
}

URLRewrite

rewrite语法格式及参数语法

rewrite是实现URL重写的关键指令,根据regex (正则表达式)部分内容,
重定向到replacement,结尾是flag标记。 

rewrite 	<regex> 	<replacement> 	[flag];
关键字 		正则 				替代内容 			flag标记

关键字:其中关键字error_log不能改变

正则:perl兼容正则表达式语句进行规则匹配

替代内容:将正则匹配的内容替换成replacement

flag标记:rewrite支持的flag标记

rewrite参数的标签段位置: server,location,if

flag标记说明: l

ast #本条规则匹配完成后,继续向下匹配新的location URI规则

break #本条规则匹配完成即终止,不再匹配后面的任何规则

redirect #返回302临时重定向,浏览器地址会显示跳转后的URL地址 (防爬虫)

permanent #返回301永久重定向,浏览器地址栏会显示跳转后的URL地址

例子

rewrite ^/([0-9]+).html/index.jsp?pageNum= /index.jsp?pageNum=1 break;

负载均衡+URLRewrite

(此时nginx:网关服务器)

这里面是101通过负载均衡代理配置,rewrite 404:8080(tomcat)

  1. 打开防火墙

systemctl start firewalld

  1. 指定端口和ip访问

firewall-cmd --permanent --add-rich-rule="rule family="ipv4" source address="192.168.44.101" port protocol="tcp" port="8080" accept"

查看已配置规则

firewall-cmd --list-all

  1. 重启防火墙

systemctl restart firewalld

重载规则

firewall-cmd --reload

完成以上步骤后,发现无法访问192.168.44.104:8080端口,但是可以通过101(这里的localhost)访问104:8080

且URLrewrite把动态资源的地址隐藏起来了。

防盗链

http协议中的 referrer

nginx防盗链配置

使用浏览器或curl检测

返回错误码

返回错误页面

整合rewrite返回报错图片

高可用

高可用介绍

安装Keepalived

下载地址

www.keepalived.org/download.ht…

使用 ./configure 编译安装

如遇报错提示

configure: error:
!!! OpenSSL is not properly installed on your system. !!!
!!! Can not include OpenSSL headers files. !!!

安装依赖

yum install openssl-devel

yum安装

yum install keepalived

  • 配置后

使用yum安装后,配置文件在

/etc/keepalived/keepalived.conf

  • 最小配置