nginx反向代理,负载均衡,动静分离,rewrite地址重写介绍

一.rewrite地址重写

地址转发后客户端浏览器地址栏中的地址显示是不变的,而地址重写后地址栏中的地址会变成正确的地址。
在一次地址转发过程中只会产生一次网络请求,而一次地址重写产生两次请求。
地址转发一般发生在同一站点项目内,而地址重写则没有限制。
地址转发到的页面可以不用全路径名表示,而地址重写到的页面必须使用完全的路径名表示。
地址转发过程中,可以将客户端请求的request范围内的属性传递给新的页面,但地址重写不可以。
地址转发的速度比地址重写的速度快。
rewrite指令:通过正则表达式的匹配来改变URI,可以同时存在一个或多个指令,按照顺序依次对URI进行匹配
redirect:将重写后的URI返回给客户端,状态码为302,指明是临时重定向URI,主要用在replacement变量不是以http或https开头的情况下
vi conf/vhost/www.abc.com.conf

#vi编辑虚拟主机配置文件
文件内容
server {
      listen
80;
      server_name abc.com;       rewrite
^/(.*) http://www.abc.com/$1 permanent; } server {       listen 80;       server_name www.abc.com;     location / {       root /data/www/www;       index index.html index.htm;       }
    error_log logs
/error_www.abc.com.log error;     access_log logs/access_www.abc.com.log main; } 或者 server {     listen 80;     server_name abc.com www.abc.com;     if ( $host != 'www.abc.com' ) {         rewrite ^/(.*) http://www.abc.com/$1 permanent;
    }     location / {       root /data/www/www;       index index.html index.htm;         }     error_log logs/error_www.abc.com.log error;     access_log logs/access_www.abc.com.log main;     }
2)重启服务 确认无误便可重启,操作如下: nginx -t #结果显示ok和success没问题便可重启 nginx -s reload
3)查看跳转效果 打开浏览器访问abc.com 页面打开后,URL地址栏的abc.com变成了www.abc.com说明URL重写成功。

rewrite的组要功能是实现RUL地址的重定向。Nginx的rewrite功能需要PCRE软件的支持,即通过perl兼容正则表达式语句进行规则匹配的。默认参数编译nginx就会支持rewrite的模块,但是也必须要PCRE的支持

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

rewrite语法格式及参数语法说明如下:

rewrite    <regex>    <replacement>    [flag];

    关键字    正则      替代内容       flag标记

 

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

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

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

flag标记:rewrite支持的flag标记

flag标记说明:

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

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

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

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

rewrite参数的标签段位置

server,location,if

例子:rewrite ^/(.*) http://www.czlun.com/$1 permanent;

rewrite为固定关键字,表示开始进行rewrite匹配规则

regex部分是 ^/(.*) ,这是一个正则表达式,匹配完整的域名和后面的路径地址

replacement部分是http://www.czlun.com/$1 $1,是取自regex部分()里的内容。匹配成功后跳转到的URL

flag部分 permanent表示永久301重定向标记,即跳转到新的 http://www.czlun.com/$1 地址上

 

rewrite 企业应用场景

 

  Nginx的rewrite功能在企业里应用非常广泛:

可以调整用户浏览的URL,看起来更规范,合乎开发及产品人员的需求。

 

为了让搜索引擎搜录网站内容及用户体验更好,企业会将动态URL地址伪装成静态地址提供服务。

 

网址换新域名后,让旧的访问跳转到新的域名上。例如,访问京东的360buy.com会跳转到jd.com

根据特殊变量、目录、客户端的信息进行URL调整等

二.nginx的动静分离

静态资源放在 A 主机的一个目录上,将动态程序放在 B 主机上,同时在 A 上安装 Nginx 并且在 B 上安装Tomcat。配置 Nginx,当请求的是 html、jpg 等静态资源时,就访问 A 主机上的静态资源目录;当用户提出动态资源的请求时,则将请求转发到后端的 B 服务器上,交由 Tomcat 处理,再由 Nginx 将结果返回给请求端。

提到这,可能有您会有疑问,动态请求要先访问 A,A 转发访问 B,再由 B 返回结果给 A,A 最后又将结果返回给客户端,这是不是有点多余。初看的确多余,但是这样做至少有 2 点好处。第一,为负载均衡做准备,因为随着系统的发展壮大,只用一台 B 来处理动态请求显然是是不够的,要有 B1,B2 等等才行。那么基于图 2 的结构,就可以直接扩展 B1,B2,再修改 Nginx 的配置就可以实现 B1 和 B2 的负载均衡。第二,对于程序开发而言,这种结构的程序撰写和单台主机没有区别。我们假设只用一台 Tomcat 作为服务器,那么凡是静态资源,如图片、CSS 代码,就需要编写类似这样的访问代码:<img src=”{address of A}/a.jpg”>,当静态资源过多,需要扩展出其他的服务器来安放静态资源时,访问这些资源就可能要编写这样的代码:<img src=”{address of C}/a.jpg”>、<img src=”{address of D}/a.jpg”>。可以看到,当服务器进行变更或扩展时,代码也要随之做出修改,对于程序开发和维护来说非常困难。而基于上面的结构,程序都只 要 <img src=”a.jpg”>,无需关心具体放置资源的服务器地址,因为具体的地址 Nginx 为帮您绑定和选择。

 

# 转发的服务器,upstream 为负载均衡做准备
 upstream tomcat_server{
        server 192.168.8.23:8099;
 }
    server {
        listen       80;
        server_name  localhost;
       # 静态资源存放目录
        root  /im;

        location / {
            root   html;
            index  ak47.html index.html index.htm;
        }
       # 动态请求的转发
        location ~ .*.jsp$ {
            proxy_pass http://tomcat_server;
            proxy_set_header Host $host;
        }
 # 静态请求直接读取
 location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|css)$ {
          expires      30d;
 } 

 

其目的和我们预期的一样,动态的请求(以 .jsp 结尾)发到 B(192.168.8.23:8099,即 tomcat_server)上,而静态的请求(gif|jpg 等)则直接访问定义的im目录

三.反向代理加负载均衡

反向代理(Reverse Proxy)实际运行方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器

反向代理的作用:

1.1 保证内网的安全,隐藏原始服务器

1.2 负载均衡。反向代理多个服务器

nginx 的 upstream默认是以轮询的方式实现负载均衡,这种方式中,每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。 另外一种方式是ip_hash:每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。

upstream myvic{
             #ip_hash;
             server 192.168.1.251 weight=1 fail_timeout=20s;
             server 192.168.1.252 weight=2 fail_timeout=20s;;
             server 192.168.1.247 weight=3 fail_timeout=20s;;#可以给服务器加权重
        }
server {

        listen       80;
        server_name  www.myvick.cn;
        location / {
             #反向代理的地址
             proxy_pass http://myvic;     
        }
}

第二种配置:ip_hash轮询方法,不可给服务器加权重

upstream myvic {
       server 192.168.196.130 fail_timeout=20s;
       server 192.168.196.132 fail_timeout=20s;
     ip_hash;
 }
 server {
         listen 80;
         server_name www.myvick.cn;
      index index.html index.htm index.php;
      location / {
              proxy_pass http://myvic;
          proxy_next_upstream http_500 http_502 http_503 error timeout invalid_header; #当其中一台返回错误码404,500...等错误时,
                    #可以分配到下一台服务器程序继续处理,提高平台访问成功率,多可运用于前台程序负载,设置proxy_next_upstream
        

         proxy_next_upstream off;#关闭请求下一个服务器

         include proxy.conf; 
      } 
基于ip hash实现session

Nginx基础入门之proxy反向代理常用配置项说明:

 

http://blog.51cto.com/blief/1739178

  

猜你喜欢

转载自www.cnblogs.com/fengzhongzhuzu/p/9101261.html
今日推荐