nginx
2019年11月12日
14:32
-
- nginx安装
将文件解压到没有中文没有空格的路径即可安装完毕
-
- 目录结构
conf: 启动加载的核心配置文件nginx.conf,需要手动编辑,其他的副本.back都是nginx.conf的测试版本文件
logs:
error.log : 输出启动停止运行的各种错误信息,定位问题的首先要观察的文件
access.log: 运行的访问日志,通过什么浏览器,http协议访问的nginx,nginx转发了哪些内容
-
- 启动和停止
start.bat: 双击启动
观察任务管理器是否存在两个nginx进程
master: 主进程,管理nginx其他工作的唯一
workers: 工作进程,树妖负责并发的处理,默认配置workers的数量是1
stop.bat: 双击停止
重启nginx需要先运行stop.bat,必须确认是否正确停止,观察任务管理器nginx进程是否全部消失,如果不能正确停止,就不能运行start.bat
-
- 入门案例
- 实现功能
- 入门案例
通过浏览器http://www.os.com/user/query/points?userId=1能够访问到一个后台服务器(在8090端口启动的Tomcat)
-
- nginx配置文件的编写(注意{}内的结构)
http
http{
默认配置了当前nginx的http服务器的各种属性
虚拟服务器端server
server {} //虚拟服务器,可以接收http请求,定义接收域名,监听的端口,接收请求地址等等
server {}
server {}
}
server {
#三个关键字 listen 多个server监听同一个端口
#一旦nginx监听了80端口,其他软件tomcat不能占用80了
listen 80;
#server_name 请求域名 request HOST的头中的域名
#当前server虚拟服务器在满足80端口访问监听
#后判断的域名是否满足条件,不同的server
#不同同时监听一个端口一个域名
server_name www.os.com;
#locatoin 定义处理请求的具体过程
#将当前请求转发给 127.0.0.1:8090的tomcat容器
#"/" locatoin 匹配域名端口后的url地址字符串
#/ 的意思是任何字符串都能匹配上
#http://www.os.com/user/query/points?userId=1
location / {
#定义转发和负载均衡逻辑
proxy_pass http://127.0.0.1:8090/;
}
}
server {
listen 80;
server_name www.os.com;
location /{
proxy_pass http://127.0.0.1:8090/;
}
}
确定: http://www.os.com/ 先要访问到nginx才有server的作用
配置host文件
验证:
-
- 验证配置是否正确,启动nginx,停止nginx是否能正常
- 8090的服务器启动
http://localhost:8090/user/query/point?userId=1
直接访问后端tomcat进程,并获取返回结果
http://www.os.com/user/query/point?userId=1
通过nginx实现的代理转发逻辑请求地址
-
- 流转逻辑
- 浏览器发起请求 http://www.os.com/user/query/point?userId=1
- 域名解析,通过host文件: www.os.com--->127.0.0.1
- 流转逻辑
即 http://127.0.0.1:80/user/query/point?userId=1
-
- nginx接收到请求,server判断监听逻辑
- 实现了监听80端口监听域名www.os.com的server处理这个请求
- 进入server的逻辑,匹配location
location / 匹配到 user/query/point?userId=1
匹配成功进入location
-
- proxy_pass生效,拼接匹配后的剩余字符串
user/query/point?userId=1
http://127.0.0.1:8090/user/query/point?userId=1
-
- tomcat处理请求返回数据到nginx
- nginx返回数据给客户端
-
- location的匹配原则
- 原则和优先级关系
- location的匹配原则
从上到下的优先级是由高到低的,多个location不同的匹配规则在同一个server下需要通过优先级的原则实现处理请求的决定
精确匹配 =/image:url除了域名和端口完全等于这里/image
由修饰的前缀字符串匹配(支持匹配多级)
^~/image
^~/image/test
以前缀匹配的字符串开始的url地址
没有修饰的前缀字符串匹配(不支持多级)
/image
满足前缀开始的所有url都匹配成功
正则匹配
~正则表达式
~.png$ 以png结尾的所有请求url
~.(png|jpg|gif)$
包含关系的优先级
-
- 有修饰的字符串匹配:以最大匹配长度的优先最高原则判断多个包含的前缀字符串修改
- 配置在上的location的正则表达式优先级更高
-
- 测试案例
listen 80;
server_name locahost;
location =/image { return 200;}
location ^~/image { return 201;}
location /image { return 202;}
location ^~/image/test { return 203;}
location ~.png$ { return 204;}
locatoin ~.(png|jpg|gif)$ { return 205;}
location / { return 206;}
http://localhost/ 返回206;
http://localhost/image 返回200;
http://localhost/image/tes 返回201
http://localhost/image/test/haha.png 返回203
http://localhost/haha/kaka.png 返回204
Nginx的负载均衡
2019年11月12日
15:36
-
- 负载均衡的结构
2.准备后端服务器
使用标示内容显示当前请求nginx转发给哪个后端服务器,启动多个后端服务器,多个服务器启动端口不同,被访问的页面带有不同的标识可以显示出访问到了不同的服务器
2.1SSM-DEMO02拷贝成多个
2.2修改maven的tomcat插件的端口号
8090 8091 8092
2.3index.html
分别编写一些标识字符串
3.负载均衡配置
-
- 轮询方式(轮着访问)
在配置文件中添加一个关键字,与server同级
upstream orderuserserver{
#根据后端服务器的访问地址编辑元素内容
server 127.0.0.1:8090;
server 127.0.0.1:8091;
server 127.0.0.1:8092;
}
相同于一个对象,List<Server>
Server对象作为元素记录的时候服务器的ip:port,orderserver的变量指向了一个内存中包含了三个服务器信息的list对象
server中修改proxy_pass
负载均衡的流转逻辑
-
- 浏览器发起请求 http://www.os.com/index.html
- host文件找映射127.0.0.1
即 http://127.0.0.1:80/index.html
-
- server监听80端口,域名www.os.com满足
- location/ /index.html 匹配/
- proxy_pass http://orderuserserver/index.html
- 拦截请求发送: 判断orderuserserver的对象是否存在
- upstream orderuserserver
- 127.0.0.1:8090
- 127.0.0.1:8091
- 127.0.0.1:8092
- 拦截规则: 获取orderuserserver中真正的ip:port
- 权重(权衡比重)
权重的意义: 根据服务器的性能按照比例分配所有的并发请求到不同的服务器,性能低的处理的并发少,反之亦然
轮询配置中的upstream的基础上添加两个关键字: weight=权重整数值或者down
upstream orderuserserver{
#根据后端服务器的访问地址编辑元素内容
server 127.0.0.1:8090 weight=1;
server 127.0.0.1:8091 weight=20;
server 127.0.0.1:8092 down;
}
上述配置造成了8091所在服务器承担了绝大部分的负载均衡的请求,同时nginx不会讲任何请求发送到8092中
再集群中容易出现故障,对于长时间不能恢复的集群节点可以采用down的处理方式
-
- ip黏着
session的集群共享问题(用户登录状态访问)
ip黏着解决的问题: session无法在集群中共享
session共享的问题描述:
如果在集群中使用session存储域属性(以登录逻辑为例)会造成登录时访问一个负载均衡的后端服务器,跳转首页是访问一个负载均衡的后端服务器,跳转首页显示xxx,欢迎回来从session访问负载均衡的另外节点导致服务器间的session不能共享
nginx提供的ip_hash黏着问题解决session共享问题
原理: 客户端ip地址不变(10.9.115.116)判断是否是同一个客户端,将会对ip做hash处理(hash取余),IP地址不变,绑定的后端负载均衡的服务器就不会变,使用ip_hash黏着,无法体验到集群的高可用效果,配置如下
upstream orderuserserver{
#根据后端服务器的访问地址编辑元素内容
ip_hash;
server 127.0.0.1:8090 ;
server 127.0.0.1:8091 ;
server 127.0.0.1:8092 ;
}
nginx动静分离
2019年11月12日
16:29
-
- nginx访问静态文件的server配置
http://www.image.com/1.jpg 访问nginx管理的一张静态图片资源
-
- server监听80端口 www.image,com
nginx服务器的磁盘 存放在一个静态文件夹中1.jpg的图片
server {
listen 80;
server_name www.image.com;
#/1.jpg
location /{
#需要引入一个关键字指定静态文件的根目录
#c://根目录
root c://;
#c://1.jpg
流转逻辑:
-
- hosts文件找域名映射
- 127.0.0.1:80/1.jpg
- server监听端口 监听端口域名成功
- location匹配 /1.jpg 匹配 / 剩余1.jpg
- 拼接location root c://
- c://1.jpg
- host文件配置ip和域名映射关系
127.0.0.1 www.image.com
-
- easymall图片资源的静态资源配置
访问方式
-
- hosts映射地址 127.0.0.1 image.jt.com
- location /{
root c://;
}
-
- 在c盘中准备upload/1/0/c/f/1/d/1/6/图片文件名称的数据
2.动静分离处理订单用户demo中所有的静态文件
2.1动静分离的实际应用
由于nginx可以处理静态文件,后端服务器可以不再做静态资源的维护工作了,相同的静态文件,提取到nginx来处理
easymall就有 在nginx的根目录的easymall的文件夹有静态文件
-
- 修改nginx配置
http://www.ssm.com/index.html; 访问静态资源
http://www.ssm.com/user/query/point?userId=1;
server {
listen 80;
server_name www.ssm.com;
location /user {
proxy_pass http://orderuserserver/user;
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Credentials' 'true';
}
location /order {
proxy_pass http://orderuserserver/order;
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Credentials' 'true';
}
location /{
root easymall;
index index.html;
} }
-
- 添加hosts配置
127.0.0.1 |
-
- user查询为例看流转逻辑
http://www.ssm.com/user/query/point
-
- hosts找到ip映射地址
- nginx接收请求server监听80 www.ssm.com
- locatoin /user 匹配
- 匹配到的都会过滤掉 /query/point
- proxy_pass http://127.0.0.1:8090/user;
- 从浏览器看到的js发起的请求url地址未必是后端接收的地址
- nginx向后端发起的请求地址
http://127.0.0.1:8090/user/query/point;
3.nginx的总结
掌握:
server的配置,可以根据请求的url路径,匹配自定义的server中的location
nginx引入到当前结构中后,访问流转逻辑
hosts映射
nginx监听
location匹配过滤
拼接location中的逻辑
知识点:
负载均衡的方式
轮询
权重
iphash黏着
session在集群中的无法共享数据的问题
动静分离
实现测试案例中order user系统所有的静态文件访问nginx
单体项目的拆分
1.回顾单体项目问题
1.1单机tomcat并发不高
nginx 负载均衡
1.2单体项目功能强耦合并发集中
功能强耦合导致开发学习更广范围的业务逻辑
并发集中导致系统大部分功能受限制于一个或2个具体功能
2.项目拆分
2.1横向拆分
根据开发的不同模块将一个项目横向拆分给多个人员并发开发,提升项目的开发速度,最终都会整合到一起实现单体项目的运行(横向拆分并没有解决单体项目的功能强耦合和并发集中的问题)
2.2纵向拆分
不拆分controller-server-mapper,根据不同的功能和不同的业务逻辑(购物车,订单,用户,商品,秒杀,微服务序列号,搜索等等),对项目的功能进行拆分--纵向拆分
纵向拆分的结果,就是将一个运行的系统,最终保持多个独立运行的系统的同时使用.
纵向拆分后解决2个问题
- 系统间的通信问题(代码解决)
做纵向拆分的结果,是实现了一个小的微服务集群
- SSM框架会导致纵向拆分的功能系统越多,重复配置就越多--独立的配置环境(框架解决--springboot)