业务分析:我们上午做了图片的上传功能(上传到本地的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/
效果是: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)
修改配置文件:
加上这段代码()这样当访问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:
现在终于实现了图片上传的回显:
步骤:
1.通过通过域名请求获取图片信息 image.jt.com/abc.jpg
2.通过hosts文件将请求发往本机
3.Nginx通过监听及服务项拦截请求,之后根据配置文件中配置的代理原则.将image.jt.com替换为本地磁盘路径d:file这样的路径,之后由Nginx实现
图片的获取.(反向代理技术)
4.通过物理的磁盘路径找到请求的图片
5.将图片的信息进行返回给nginx
6.nginx将图片信息返还给浏览器
7.浏览器接收到图片信息后进行页面展现.
业务要求:不使用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
业务要求:打成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的插件时,修改了参数进行了设置.
org.apache.tomcat.maven
tomcat7-maven-plugin
2.2
8091
/
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的启动和重启的速度特别的快,几乎秒开秒关
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能连接了,那么就恢复之前的配置.