@toc
Nginx概念
Nginx是一款高性能的HTTP服务器,反向代理服务器及电子邮件(IMAP/POPP3)代理服务器.由俄罗斯的Igor Sysoev所开发,Nginx可能撑持5万并发链接,并且CPU,内存等资源耗费非常低,运行十分稳固
Nginx利用场景
- HTTP服务器,虚拟主机: Nginx是一个HTTP服务能够独立提供HTTP服务,能够做网页动态服务器,能够实现在一台服务器上虚构出多个网站,例如集体网站应用的虚拟主机
- 反向代理: 当网站的访问量达到肯定水平后,单台服务器不能满足用户申请时,须要用多台服务器集群时能够应用Nginx做反向代理
负载平衡: 多台服务器能够均匀分担负载,不会因为某台服务器负载高宕机而某台服务器闲置的状况
HTTP服务器,虚拟主机
应用Docker装置运行Nginx,在./conf 里创立nginx.conf文件,配置docker-compose.yml
version: '3.1'services: nginx:restart: alwaysimage: nginxcontainer_name: nginxports: - 80:80volumes: - ./conf/nginx.conf:/etc/nginx/nginx.conf - ./wwwroot:/usr/share/nginx/wwwroot- 虚拟主机: 虚拟主机是一种非凡的软硬件技术.能够将网络上每一台计算机分成多个虚拟主机,每个虚拟主机能够独立对外提供www服务,这样就能实现一台主机对外提供多个web服务,每个虚拟主机之间是独立的,互不影响的
通过Nginx能够实现虚拟主机的配置,Nginx反对三种类型的虚拟主机的配置:
- 基于IP的虚拟主机
- 基于域名的虚拟主机
- 基于端口的虚拟主机
Nginx配置文件构造: 其中每个server就是一个主机
events {}http { server{ } server{ }}基于域名的虚拟主机配置
需要:
- 两个域名指向同一台Nginx服务器,用户拜访不同的域名显示不同的网页内容
- 两个域名是admin.service.itoken.oxford.com和admin.web.itoken.oxford.com
- Nginx服务器应用虚拟机192.168.32.255
配置 Windows Hosts文件:
- 批改window的hosts文件(C:/Windows/System32/drivers/etc)-SwitchHosts
- 通过host文件指定admin.service.itoken.oxford.com和admin.web.itoken.oxford.com对应192.168.32.255虚拟机
- 创立目录及文件: 在 /usr/local/docker/nginx/wwwroot目录下创立htmlservice和htmlweb两个目录,并别离创立index.html文件
配置虚拟主机: 批改 /usr/local/docker/nginx/conf目录下的nginx.conf配置文件
user nginx;worker_processes 1;events { worker_connections 1024;}http{ include mime.type; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server{ listen 80; server_name admin.service.itoken.oxford.com # 所有的申请都是以 / 开始,所有的申请都能够匹配此location location / { root /usr/local/docker/nginx/wwwroot/htmlservice; # 指定欢送页面,按从左到右程序查找 index index.html index.htm; } } server{ listen 80; server_name admin.web.itoken.oxford.com location / { root /usr/share/nginx/wwwroot/htmlweb; index index.html index.htm; } } }基于端口的虚拟主机配置
需要:
- Nginx对外提供80和8080两个端口监听服务
- 申请80端口则申请html80目录下的html
- 申请8080端口则申请html8080目录下的html
- 创立目录及文件: 在 /usr/local/docker/nginx/wwwroot目录下创立html80和html8080两个目录,并别离创立两个index.html文件
配置虚拟主机: 批改 /usr/local/docker/nginx/conf目录下的nginx.conf配置文件
worker_processes 1;events { worker_connections 1024;}http{ include mime.type; default_type application/octet-stream; sendfile on; keepalive_timeout 65; # 配置虚拟主机 192.168.32.255 server{ # 监听的IP和端口,配置192.168.32.255:80 listen 80; # 虚拟主机名称,这里配置IP地址 server_name 192.168.32.255; # 所有的申请都是以 / 开始,所有的申请都能够匹配此location location / { # 应用 root 指令指定虚拟主机目录即网页寄存目录 # 例如:拜访 http://ip/index.html 将找到 /usr/local/docker/nginx/wwwroot/html80/index.html # 例如:拜访 http://ip/item/index.html 将找到 /usr/local/docker/nginx/wwwroot/html80/item/index.html root /usr/share/nginx/wwwroot/html80; # 指定欢送页面,按从左到右程序查找 index index.html index.htm; } } # 配置虚拟主机 192.168.32.255 server{ listen 8080; server_name 192.168.32.255; location / { root /usr/share/nginx/wwwroot/html8080; index index.html index.htm; } }}Nginx 反向代理
代理服务器
客户端在发送申请时,不会间接发送给目标主机.而是先发给代理服务器,代理服务器接管客户端申请后,再向主机收回,并接管目标主机返回的数据,寄存在代理服务器的硬盘中,再发送给客户机
代理服务器作用
- 进步访问速度: 因为指标主机返回的数据寄存在代理服务器的硬盘中,因而下一次客户在拜访雷同的站点数据时,会间接从代理服务器的硬盘中读取,起到了缓存的作用,尤其对于热门站点能明显提高申请速度
- 防火墙作用: 因为所有客户机申请都必须通过代理服务器拜访近程站点,因而可在代理服务器上设限,过滤掉某些不平安信息
通过代理服务器访问不能拜访的指标站点: 互联网上有许多凋谢的代理服务器,客户机在拜访受限时,可通过不受限的代理服务器拜访指标站点
正向代理
架设在客户机和指标主机之间,只用于代理外部网络对Internet的连贯申请,客户机必须指定代理服务器,并将原本要间接发送到web服务器上的http申请发送到代理服务器中
反向代理
反向代理服务器架设在服务器端,通过缓冲常常被申请的页面来缓解服务器的工作量,将客户机申请转发给外部网络上的指标服务器,并将从服务器上失去的后果返回给Internet上申请连贯的客户端,此时代理服务器与指标主机一起对外体现为一个服务器
反向代理利用
- 避免外网对内网服务器的恶性攻打
- 缓存以缩小服务器压力
- 拜访安全控制
进行负载平衡,将用户申请调配给多个服务器
Nginx反向代理Tomcat
启动Tomcat容器: 启动两个Tomcat容器,映射端口为9090和9091,配置docker-compose.yml
version: '3'services: tomcat1:image: tomcatcontainer_name: tomcat1ports: - 9090:8080 tomcat2:image: tomcatcontainer_name: tomcat2ports: - 9091:8080配置Nginx反向代理: 批改 /usr/local/docker/nginx/conf 目录下的nginx.conf配置文件
user nginx;worker_processes 1;events { worker_connection 1024;}http { include mime.type; default_type application/octet-stream; sendfile on; keepalive_timeout 65; # 配置一个tomcat1代理服务器 upstream tomcat_server1 { server 192.168.32.255:9090; } # 配置一个tomcat2代理服务器 upstream tomcat_server2{ server 192.168.32.255:9091; } server { listen 80; server_name admin.service.itoken.oxford.com # 所有的申请都是以 / 开始,所有的申请都能够匹配此location location / { # 域名 admin.service.itoken.oxford.com的申请全副转发到tomcat_server1,即tomcat1服务器上 proxy_pass http://tomcat_server1; # 欢送页面,依照从左到右的程序查找页面 index index.jsp index.html index.htm; } } server{ listen 80; server_name admin.web.itoken.oxford.com location / { # 域名 admin.web.itoken.oxford.com的申请全副转发到tomcat_server2,即tomcat2服务器上 proxy_pass http://tomcat_server2; index index.jsp index.html index.htm; } } }Nginx负载平衡
负载平衡
- 负载平衡建设在现有网络结构之上,提供了一种便宜无效通明的办法扩大网络设备和服务器的带宽,减少吞吐量,增强网络数据处理能力,进步网络的灵活性和可用性
负载平衡(Load Balance),摊派到多个操作单元上进行执行,例如Web服务器,FTP服务器,企业要害应用服务器和其它要害工作服务器等,从而共同完成工作工作
Nginx 实现负载平衡
需要:
- nginx作为负载平衡服务器,用户申请先达到nginx,再由nginx依据负载平衡配置将申请转发到tomcat服务器
- nginx负载平衡服务器:192.168.32.255:80
- tomcat服务器:192.168.32.255:9090
Nginx配置负载平衡: 批改 /usr/local/docker/nginx/conf下的nginx.conf配置文件
user nginx;worker_processes 1;events { worker_connection 1024;}http { include mime.type; default_type application/octet-stream; sendfile on; keepalive_timeout 65; upstream myapp { server 192.168.32.255:9090 weight=10; server 192.168.32.255:9091 weight=10; } server{ listen 80; server_name nginx.oxford.com; location / { proxy_pass http://myapp; index index.jsp index.html index.htm; } }}Nginx 解决跨域问题
跨域问题
- 在浏览器端进行Ajax申请时会呈现跨域问题
跨域: 浏览器不能执行其它网站的脚本.是因为浏览器的同源策略造成的,是浏览器对JavaScript施加的平安限度
同源
同源: 域名,协定,端口均雷同
解决跨域问题形式
应用CORS(跨资源共享)解决跨域问题
- CORS是W3C规范,全称"跨资源共享"(Cross-origin resource sharing),容许浏览器向跨源服务器收回XMLHttpRequest申请,从而克服了Ajax只能同源应用的限度
- CORS须要浏览器和服务器同时反对
- 目前,所有浏览器都反对该性能,IE浏览器不能低于IE10.
- 整个CORS通信过程,都是通过浏览器主动实现,不须要用户参加.对于开发者来说,CORS通信与同源Ajax通信没有差异,代码齐全一样.
- 浏览器一旦发现Ajax申请跨源,就会主动增加一些附加的头信息,有时还会多出一次附加 的申请,但用户不会有感觉
- 实现CORS通信的要害是服务器,只有服务器实现了CORS接口,就能够跨域通信
在header中设置:Access-Control-Allow-Origin(在服务器申请控制器中的controller类标注 @CrossOrigin(value="*") 注解)
应用JSONP解决跨域问题
- JSONP:(JSON with Padding),JSON的一种"应用模式:,可用于解决支流浏览器的跨域数据拜访问题
- 因为同源策略,个别server1.example.com的网页无奈与server2.example.com的服务器进行拜访,而HTML的< script>元素是个例外
- 利用< script>元素这个凋谢策略,网页能够失去从其它起源动静产生的JSON材料,而应用的这种模式就叫JSONP
- 用JSONP抓到的材料不是JSON,而是任意的JavaScript,用JavaScript直译器执行而不是用JSON解析器解析
须要指标服务器配合一个callback函数
CORS与JSONP比拟:
- CORS与JSON应用的目标雷同,然而比JSONP更弱小
- CORS反对所有类型的HTTP申请
JSONP只反对GET申请, JSON的劣势在于反对老式浏览器,以及能够向不反对CORS的网站申请数据
Nginx反向代理解决跨域问题
当服务器无奈设置header或提供callback函数时就能够采纳Nginx反向代理解决跨域问题
Nginx配置跨域
在 /usr/local/docker/nginx/conf中的nginx.conf里的location中减少配置(Get:字体跨域):
add_header Access-Control-Allow-Origin *或域名;add_header Access-Control-Allow-Headers X-Requested-with;add_header Access-Control-Allow-Methods GET,POST,OPTIONS;配置 /usr/local/docker/nginx/conf中的nginx.conf配置文件(POST:上传文件):
user nginx;worker_processes 1;events { worker_connection 1024;}http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name upload.myshop.com; add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-with,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range'; location / { proxy_pass http://192.168.32.255:8888; if($request_method = 'OPTIONS'){ add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Headers X-Requested-with; add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,PATCH,OPTIONS; # 解决假申请问题,如果是简略申请则没有这个问题,这里是上传文件,首次申请为OPTIONS形式,理论申请为POST形式 add_header Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-with,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range; return 200; } } }}