Nginx实现反向代理,负载均衡和tomcat的高可用

Nginx的使用

业务分析:我们上午做了图片的上传功能(上传到本地的d:file文件夹下),现在需要做的是图片上传之后,easyUI根据服务端返回的url实现图片的回显:
url:http://image.jt.com/2018/05/07/5a353b62b40d4ad3888f63616f384f2040.jpg  (服务端发送的请求)
d:/file/2018/05/07/5a353b62b40d4ad3888f63616f384f2040.jpg (实际的文件的位置)

现在我们需要做的是,当用户发送url请求时,我们需要把url请求的image.jt.com换成d:/file

要实现上面的功能就需要使用Nginx实现方向代理

分析:我试着将urlPre也换成d:/file这样url请求是用的就不是虚拟路径,而直接是本地磁盘,但是发现,并无法实现图片的回显操作:

这里写图片描述

这种实现回显失败,但是直接在浏览器地址栏输入又是直接可以访问的:

这里写图片描述

我猜可能是浏览器无法解析,但是nginx能够实现反向代理,能够将虚拟路径换成本地磁盘的路径

Nginx的介绍:

这里写图片描述

1.特点说明:

1.实现反向代理
2.实现负载均衡
3.Nginx主要实现了请求的转发以及响应.Nginx的开发的语言C语言开发.Nginx可以实现秒开秒关

2.Nginx的下载官网:

http://nginx.org/en/download.html

3.Nginx的安装:

3.1把老师给的压缩文件解压到d:/software/nginx/

这里写图片描述

3.2一管理员的身份运行nginx:
这里写图片描述

效果是:nginx启动速度非常快,启动一闪而过

3.3:nginx启动的说明:

cmd操作:
1.启动   start nginx
2.停止   nginx -s stop
3.重启   nginx -s reload  (配置文件错误会有提示)
说明:如果通过命令启动Nginx则要求必须在nginx的可执行文件夹下运行命令(根目录)
E:\software\jt\1712\nginx-1.9.0

这里写图片描述

3.41.3.4Nginx关于线程的说明

说明:Nginx的启动会每次启动2个进程.一个是主进程 一个是守护进程.
主进程是提供服务的主要的程序,守护进程是为了防止主进程意外关闭的.
主进程占用资源较多,守护相对较少.

要是守护进程没有关闭的情况下,去直接关闭主进程,是关闭不了的,关闭之后守护进程优会启动主进程

这里写图片描述

2.如何实现nginx的反向代理:

2.1修改nginx的配置文件(conf/nginx.conf)

Nginx配置文件的介绍:
这里写图片描述

修改配置文件:

加上这段代码()这样当访问image.jt.com就会转向到具体的图片文件夹下d:/file/….下

# 图片服务器
server {
    # 监听的端口 需要回显图片用的端口是默认的80端口
    listen 80;

    # 拦截的服务名称  (名字不同 就不会跟localhost冲突)
    server_name image.jt.com;

    # 请求拦截后做的具体操作  根据要求转发到具体的文件夹中
    location / {
        root D:\file;
    }
}

注意启动tomcat使用的端口可能是8091,但是在nginx里面配置反向代理是,监听的端口一定是80端口,因为是浏览器访问的端口,默认是80,就不需要在地址栏
加上端口号了,此时是跟tomcat的端口无关的.

配置完了需要重启nginx

这里写图片描述

但是此时仍然没有实现图片的回显功能
这里写图片描述

原因:

浏览器发送请求是,访问的是http://image.jt.com,会找host文件里面有没有配置对应的域名,如果没有的话,那么就去找DNS(域名解析器)去找对应的ip地址.
由于我们并没有这个域名,我们都是在本机操作,所以在本机上,应该配置这个image.jt.com对应的ip地址,指向本机,

使用老师的工具:SwitchHosts:

这里写图片描述

现在终于实现了图片上传的回显:

这里写图片描述

Nginx的反向代理:

这里写图片描述

步骤:

    1.通过通过域名请求获取图片信息  image.jt.com/abc.jpg
    2.通过hosts文件将请求发往本机
    3.Nginx通过监听及服务项拦截请求,之后根据配置文件中配置的代理原则.将image.jt.com替换为本地磁盘路径d:file这样的路径,之后由Nginx实现
        图片的获取.(反向代理技术)
    4.通过物理的磁盘路径找到请求的图片
    5.将图片的信息进行返回给nginx
    6.nginx将图片信息返还给浏览器
    7.浏览器接收到图片信息后进行页面展现.

Nginx实现请求的代理:

业务要求:不使用localhost:8091去访问,而使用虚拟的域名去访问:

需要在nginx.conf里面做配置(配置之后重启nginx)

#京淘后台管理系统
server {
    listen 80;
    server_name manage.jt.com;

    #编辑拦截后的任务 转发请求 http://localhost:8091
    location / {

        #转发请求 协议://ip地址:端口号
        proxy_pass  http://localhost:8091;
    } 
}

这样当访问manage.jt.com的时候其实访问的就是http://localhost:8091,注意仍然需要在host文件里面配置manage.jt.com对应127.0.0.1
要不然浏览器找不到会去找DNS

这里写图片描述


使用Nginx搭建tomcat集群:

业务要求:打成war包的文件放置在多台服务器中

1.把老师给的无缓存的tomcat压缩文件复制到d:software/tomcat下:解压三份:
这里写图片描述

2.每个服务器的三个端口都要修改(依次加1)

8005 8091 8009  -- tomcat-8091
8006 8092 8010  -- tomcat-8092
8007 8093 8011  -- tomcat-8093

3.将manager项目打包:maven-install

这里写图片描述

打成的war包再target下,将这个war包复制到桌面

4.修改这个war文件的名字改成 ROOT.war - 注意是大写

这样放在tomcat的webapps里面就可以直接不带项目名访问了
注意我们之前在eclipse下发布项目也没哟使用项目名访问,是因为我们在项目中的pom.xml配置tomct的插件时,修改了参数进行了设置.
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.tomcat.maven</groupId>
            <artifactId>tomcat7-maven-plugin</artifactId>
            <version>2.2</version>
            <configuration>
                <port>8091</port>
                <path>/</path>  <!-- 不需要项目名就可以直接访问 -->
            </configuration>
        </plugin>
    </plugins>
</build>

5.把修改后的ROOT.war放在每一个tomcat的webapps下面,原先的ROOT文件修改名字(或者删除)

6.使用Nginx实现负载均衡:

6.1 轮询机制:

说明:轮询机制根据配置文件的顺序,依次调用tomcat服务

1.配置轮询

upstream jt {
    server 127.0.0.1:8091 ;
    server 127.0.0.1:8092 ;
    server 127.0.0.1:8093 ;
}

2实现的配置

# 京淘的后台管理系统  (域名的反向代理)
server {
    # 无论端口是多少都得是80 
    listen 80;

    server_name manage.jt.com;

    # 编辑拦截后的任务  转发一个请求 http://localhost:8091
    location / {
        # 引用了配置的upstream
        proxy_pass http://jt;  
    }

}

这样就实现了轮询机制的负载均衡,每台tomcat都轮个访问:

6.2 权重方式:

说明:如果公司的服务器的规格层次不齐,这时采用轮询的机制可能会造成不合理的现象,(撑死和饿死),根据公司的服务器的规格,指定负载压力.采用权重的配置

upstream jt {
    # 语法规则  server表示服务  ip:端口
    server 127.0.0.1:8091 weight=6 ;
    server 127.0.0.1:8092 weight=3 ;
    server 127.0.0.1:8093 weight=1 ;
}

说明:配置的数值是任意的.通过数据的大小决定负载的压力.数值越大,将来的承担的压力就越多.

6.3 IP_hash:

说明:由于业务中需要实现Session共享,在集群部署时,一般Session不会多台共享Session.
解决方法:使用Nginx中Iphash实现Session共享,根据用户的IP地址,进行hash运算.最终算出特定的一台机器进行数据的转发

同一个ip只会永远访问同一台服务器,不会出现刷新请求之后访问到别的服务器,这样session都是在同一台服务器中

# 实现tomcat集群的部署
upstream jt {
    # 实现session共享(特定的)
    ip_hash;
    # 语法规则  server表示服务  ip:端口
    server 127.0.0.1:8091 weight=6 ;
    server 127.0.0.1:8092 weight=3 ;
    server 127.0.0.1:8093 weight=1 ;
}

总结:如果配置文件中使用IP_hash那么权重和轮询将不起作用.岁根据ip地址分配一台服务器,不受权重的影响

6.4备用机制:
说明:通常的服务器配置不会100%都参与服务.有些处于空闲状态,当主服务正忙或者断电或者宕机时,这时备用才会起作用.

备用机机制一般的服务器性能较低.

# 实现tomcat集群的部署
upstream jt {
    # 语法规则  server表示服务  ip:端口
    server 127.0.0.1:8091 weight=6 ;
    server 127.0.0.1:8092 weight=3 backup;
    server 127.0.0.1:8093 weight=1 ;
}

服务上限部署的步骤:

1.根据上线服务器情况,分批上线(根据公司业务要求上线3点左右)是一台一台服务器分批部署
2.将需要上线的服务器在nginx中进行下线处理.作用将不会再有请求发往该机器(假设先将项目部署到tomct-8091),就需要在nginx中配置,使得tomcat-8091是
不会接受到请求的(停掉这台服务器)  (配置了down)

    # 实现tomcat集群的部署
    upstream jt {
        server 127.0.0.1:8091 weight=6 down;
        server 127.0.0.1:8092 weight=3 backup;
        server 127.0.0.1:8093 weight=1 ;
    }

3.这样请求就不会到达tomcat-8091了,然后把tomcat-8091服务器关闭,接着,把项目发布到tomcat-8091上,

upstream jt {
        server 127.0.0.1:8091 weight=6 ;
        server 127.0.0.1:8092 weight=3 backup;
        server 127.0.0.1:8093 weight=1 down;
}

4.tomcat-8091的down去掉,把tomcat-8093配置成down,(请求就到不了tomcat-8093了),接下来跟上面的操作一样

每一次都停掉一个:或者说至少要保证项目在上线是,至少是有服务器时能处理用户请求的,一个一个部署.
每一次修改配置文件之后,nginx都需要重启,但是nginx速度非常快,可以实现秒开,秒关,所以影响比较小.

使用Nginx时,它的性能特别的高能够支持50000/秒的并发量.并且由于底层是C语言编辑.所以nginx的启动和重启的速度特别的快,几乎秒开秒关


Nginx实现tomcat高可用

1.需求分析:

说明:有时服务器可能会出现意外宕机的现象.这时不能修改nginx的配置文件,使之将请求转发到可用的机器中.如果想实现tomcat高可用的处理,应
当进行高可用的配置.

2.修改nginx的配置文件:

server  127.0.0.1:8091 weight=6 max_fails=1 fail_timeout=60s;
说明:
max_fails=1 表示最大的失败次数.
fail_timeout=60s 表示健康检测的周期.

在nginx连接服务器期间,nginx会自动的向连接的服务器发送健康检查机制(ping/发起一次请求)----redis心跳检测.如果服务器的失败次数达到规定的最大值,
这时在这个检测周期中,不会再将服务器发送到该机器.直到下一次检测周期,如果服务器经过运维人员的抢修服务器正常的启动,则在下一个检测周期后,会将请求
发往该服务器,一切都是动态的

#实现tomcat集群的部署
upstream jt {
    #ip_hash;
    #语法规则   server表示服务  ip:端口;
    server  127.0.0.1:8091 weight=6 max_fails=2 fail_timeout=10s;
    server  127.0.0.1:8092 weight=3 backup;
    server  127.0.0.1:8093 weight=1 max_fails=2 fail_timeout=10s;
}

# 京淘的后台管理系统  (域名的反向代理)
server {
    # 无论端口是多少都得是80 
    listen 80;

    server_name manage.jt.com;

    # 编辑拦截后的任务  转发一个请求 http://localhost:8091
    location / {
        proxy_pass http://jt;
        # 定义超时策略
        proxy_connect_timeout       5; 
        proxy_read_timeout          5;  
        proxy_send_timeout          5;  
    }
}

分析:

如果tomcat-8091宕机或者断电了,客户端访问不到了,nginx会自动连接2次tomcat-8091,发现2次之后,还是连接不了tomcat-8091,那么10s内,
nginx是不会再测试是否能连接tomcat-8091的,在tomca-8091不能访问之后,nginx一方面会对tomcat-8091做健康检测,并且5秒之后,会连接可以用的服务器
tomcat-8093(没有宕机)
如果tomcat-8091能连接了,那么就恢复之前的配置.

猜你喜欢

转载自blog.csdn.net/qq_38200548/article/details/80232922