Java：75-Nginx介绍

Nginx介绍

什么是Nginx（最后有对应前后端项目地址）：

Nginx（发音同 engine x）是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器

并在一个BSD-like 协议下发行，由俄罗斯的程序设计师Igor Sysoev（伊戈尔·西索夫）所开发

供俄国大型的入口网站及搜索引擎Rambler（漫步者）（俄文：Рамблер）使用

其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好

中国大陆使用nginx网站用户有：新浪、网易、 腾讯等

优点：

占用内存少，并发能力强

Nginx专为性能优化而开发，在高连接并发的情况下，能够支持高达 50000 个并发连接数的响应

Nginx支持热部署，可以在不间断服务的情况下，对软件版本进行升级

应用场景

http服务器：Nginx是一个http服务可以独立提供http服务，可以做网页静态服务器

虚拟主机：可以实现在一台服务器虚拟出多个网站，例如个人网站使用的虚拟主机

反向代理，负载均衡：当网站的访问量达到一定程度后，单台服务器不能满足用户的请求时

需要用多台服务器集群可以使用nginx做反向代理，并且多台服务器可以平均分担负载

不会因为某台服务器负载高宕机而某台服务器闲置的情况

Nginx安装：

下载nginx，官方网站：http://nginx.org/

我们使用的版本是1.17.8版本

Nginx在Linux下安装，只提供了源代码，所以我们需要进行编译（需要C语言的环境）

安装环境配置：

因为Nginx是C语言编写的，所以需要配置C语言编译环境

一定要在联网状态下安装，因为接下来我们要到Linux里面使用yum命令安装，即需要联网

#需要安装gcc的环境，执行命令: 
yum install gcc-c++  # 注意root用户运行，安装C的编译环境

可能会出现以下情况：

解决办法：

/*
问题是 yum在锁定状态中，强制关掉yum进程即可
rm -f /var/run/yum.pid
*/

一般的不会出现这种情况，因为我们刚刚开启也不会锁定，即被使用

第三方的开发包，在编译之前需要安装这些第三方包，否则也就没有对应的操作了

当然，你不安装也行，只是最后创建的Mikefile文件可能编译不了（第三个可以不用安装，也可以编译，即第三个可有可不有）

PCRE：

nginx的http模块使用pcre来解析正则表达式，所以需要在linux上安装pcre库

#安装命令:
yum install -y pcre pcre-devel #创建文件时，这个错误先出来

zlib：

nginx使用zlib对http包的内容进行gzip，所以需要在linux上安装zlib库

#安装命令:
yum install -y zlib zlib-devel

openssl：

OpenSSL 是一个强大的安全套接字层密码库，nginx不仅支持http协议，还支持https，所以需要在linux安装openssl库

#安装命令:
yum install -y openssl openssl-devel

安装Nginx 步骤：

将Nginx的源码包上传到 Linux

解压Nginx

tar -xvf nginx-1.17.8.tar   
#使用zxvf也可以，因为解压时对应的z并不会起作用，只是看x就可以了
#但是在压缩时，z代表支持对应的gzip后缀的压缩，所以我们使用zcvf和cvf是不同的
#具体查看不同之处，只需要使用file 文件名即可
#可以看到使用cvf的提示：POSIX tar archive (GNU)
#使用zcvf的提示：gzip compressed data, from Unix, last modified: Thu May 26 06:09:14 2022
#这就是不同之处
#最后注意：无论是压缩还是解压缩都是一个对文件的操作形式，使得文件变得小，也有可能变大
#举个例子：假如我们的数据是AAAABBBCCCCC，那么压缩后变成了4A3B5C，发现的确变小了
#而解压时他一次读取两个数来解压
#即但读到4A时，解压成AAAA，这就是一个压缩和解压的算法
#但是若对应的数据只有ABC，那么压缩后变成了1A1B1C，那么就变大了
#当然上面也只是一个简单例子而已，实际上压缩和解压比上面要复杂
#且注意：使用-r的rm时，如果不是目录，那么就当成普通文件删除
#实际上-可以去掉

解压好后，看如下：

进入到解压之后的目录 nginx-1.17.8：

执行命令 configure，生成Mikefile文件（多次的执行就是覆盖，也可以认为是先删除Mikefile文件然后创建Mikefile文件）

./configure \
--prefix=/usr/local/nginx \
--pid-path=/var/run/nginx/nginx.pid \
--lock-path=/var/lock/nginx.lock \
--error-log-path=/var/log/nginx/error.log \
--http-log-path=/var/log/nginx/access.log \
--with-http_gzip_static_module \
--http-client-body-temp-path=/var/temp/nginx/client \
--http-proxy-temp-path=/var/temp/nginx/proxy \
--http-fastcgi-temp-path=/var/temp/nginx/fastcgi \
--http-uwsgi-temp-path=/var/temp/nginx/uwsgi \
--http-scgi-temp-path=/var/temp/nginx/scgi

#将上面的命令直接复制粘贴执行即可

执行命令后，生成了Makefile文件（多次的执行就是覆盖该文件，也可以认为是先删除Makefile文件然后创建Makefile文件）

创建临时文件目录：

mkdir /var/temp/nginx/client -p   #启动nginx需要这个，否则启动不了
#注意：root用户，但凡会操作文件的一般都需要root用户
#-p检查是否存在，存在则不添加，即不会出现报错提示，但基本只会操作目录，即mkdir，其中touch没有-p

执行make命令，进行编译

make命令是操作MakeFile文件的，即它从MakeFile文件中读取指令，所以编译需要的东西需要存在或者编译的步骤不能错

若指定目录没有，则会有报错提示，这里是当前目录，即这个文件就使得编译

make #编译，注意他是全局的，有些操作，比如./make.sh则是自己的命令
#而不是操作MakeFile文件（在FastDFS里面就是），即他们是不一样的
#全局的才会操作当前目录的MakeFile文件，否则通常就是执行的命令而已

安装（将编译后的文件进行复制，一般默认复制到/usr/local/里面）：

make install

一般会将编译后的执行文件复制放在某个文件里，可以根据安装复制过程查看，一般在/usr/local/里面出现了nginx文件了

若多次的操作，对应的nginx文件不会变，即不会覆盖（但会添加或者删除，在82章博客就有对应的操作体现），所以通常只有第一个（第一次安装的nginx）的nginx可以操作

启动并访问 Nginx：

进入到nginx 安装目录：

cd /usr/local/nginx/

进入到 sbin目录，执行 nginx 命令

./nginx #启动，一般不指定文件启动的话，默认/usr/local/nginx/conf/nginx.conf对应的配置文件，需要"-c 文件"，对应的82章博客就有操作
./nginx -s stop #关闭
ps aux | grep nginx #查看进程

通过浏览器进行访问，默认端口 80 （注意：是否关闭防火墙，记得关闭）

出现下面的界面，说明访问完毕（自己虚拟机的地址）：

配置虚拟主机：

虚拟主机指的是，在一台服务器中，我们使用Nginx，来配置多个网站

如何区分不同的网站：

端口不同

域名不同 ，其中不同域名对应的ip地址可以是相同的（一般域名可以随便设置，但只是对于本机来说，其他域名一般都会有规则）

具体情况看后面的介绍

通过端口区分不同的虚拟主机：

Nginx配置文件：

Nginx配置文件的位置：

cd /usr/local/nginx/conf
#nginx.conf 就是Nginx的配置文件

Nginx核心配置文件说明：

worker_processes  1; #work的进程数，默认为1
#配置 影响nginx服务器与用户的网络连接
events {
    worker_connections  1024; #单个work 最大并发连接数
}

# http块是配置最频繁的部分 可以嵌套多个server，配置代理，缓存，日志定义等绝大多数功能
http {
	# 引入mime类型定义文件
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65; # 超时时间
	
	#server 配置虚拟主机的相关参数 可以有多个,一个server就是一个虚拟主机
    server {
		# 监听的端口
        listen       80; 
		#监听地址
        server_name  localhost;         

		# 默认请求配置
        location / {
            root   html; # 默认网站根目录
            index  index.html index.htm; # 欢迎页
        }

		# 错误提示页面
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
    
    #注意：我们一般操作的是server这个相关参数
    #其中他监听的是80端口，地址的域名是localhost
    #一般先从本机找域名，通常在对应配置文件，即C:\Windows\System32\drivers\etc下的hosts里面设置本机域名配置
    #一般都是这个路径
    #若没有找到，然后才去DNS服务器，若还是没有，则对应的ip地址则没有，浏览器自然会显示网页找不到的界面
    #location标识对应的默认访问，这里就是/
    #这里对应的nginx目录下的html下的index.html找到就是这个，要找到才行
    #没有，就自然不会有对应的界面
    #即/就代表者nginx，一般在/usr/local/nginx/就是/
    #一般root也默认html，不写的话，就是相当于写了root html;
    #当没有url匹配时（即没有url匹配loaction），那么就是默认/（前提是匹配了端口，否则一般是不会拦截的）
    #一般访问的location的值路径，最终路径是加在root值后面，形成的总的路径，可以自行测试
    #当然你也可以手动操作50x.html，他会去html里面找，若是对于的静态资源，那么返回
    #否则，若是目录，那么默认访问该目录下的index.html文件，若不存在，返回错误页面
    #否则就是返回下载界面，使得可以下载文件，可以自己进行操作
    #若有进行index，
    #那么由于/50.html不是/，即index没有起作用
    #因为不是目录，若是目录，那么就是访问该目录下的index的对应文件，从左到右（都可以的话，不可以的，跳过）
    #都不可以报错
    #当然不写，也就是默认index.html
    #即index相当于设置该路径下的访问，但他只会操作/目录，其他目录不起作用
    #也就是说你在50x.html下设置，那么访问的任然是50x.html（这里是这样）
}

使用notepad++，连接Linux，因为我们在Linux里面使用vi或者vim来进行文件的修改太麻烦了，所以为了简便一点

我们使用记事本的操作来修改，但需要连接，而notepad++这个记事本就有这样的功能

下载地址：

链接：https://pan.baidu.com/s/1S5IFFD1Zm69Pmnxl9uOgIA

提取码：alsk

使用notepad++来连接linux，好处是使用notepad++来编辑linux中文件的批量文字，会比直接在linux中操作方便快捷很多

Notepad 插件中安装NppFTP：

将文件使用notepad++打开，点击插件，点击插件管理，找到NppFTP进行安装即可

再次回到插件，就多出来NppFTP选项了，点击：

打开后，会出现一个界面：

进行设置，操作如下：

点击后出现一个选项，如何到如下界面：

注意：要先点击Add new来进行创建一个连接，这里创建的连接名称就是nginx名称

这时我们可以直接关闭（因为自动保存的，即添加时就会保存）

然后点击如下：

当我们创建好后，点击左上角的连接操作，会提示出来对应连接名称（若没有连接，则基本是点击不了或者没有提示连接名称）

点击一下就会进行连接了，然后根据是否连接从而出现对应目录，再次点击则是断开

我们双击/，然后出现整体目录，找到对应的如图所示：

其中nginx.conf找到后，接下来说明一下，为什么使用这个notepad++，连接Linux

在寻常的文件操作时，只是对应文件的传递，如xftp（虽然可以改变后进行覆盖，但有点麻烦）

但使用notepad++，连接Linux则可以直接操作文件内容

现在我们双击nginx.conf文件，记得等待，见证奇迹的时刻到了（再次点击会提示你是否加载，用来防止你的操作直接被覆盖）

发现在左边显示了这个文件内容，这里由于是进行连接的

所以改变左边内容，保存后也会顺便更改或者说覆盖（应该是覆盖）虚拟机的文件，注意要保存，否则不会改变

使得vi或者vim的修改到了记事本的手上了

配置nginx.conf：

先删掉对应的注释，使得美观

使用notepad++在nginx.conf中添加一个新的server

 #一个server代表一个虚拟主机，可以配置多个server
 
 #下面是新加上的server----------
 
 #配置新的server
	 server {
        listen       81; #修改端口
        server_name  localhost;

       
        location / {
            root   html81;
            index  index.html index.htm;
        }

       
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
		  #index  index.html index.htm; #这个不起作用，因为不是/目录，可以加上可以不加，这里就注释掉了
        }

      
    }

我们创建将原来的html目录进行复制，复制到当前目录，改成html81

使用命令：

cp -r html html81 #复制目录需要-r参数

重新加载配置文件：

配置文件改变后，我们需要重新加载，就如java运行后，只会操作内存里面的运行后的class文件

实际上nginx里面的文件改变都一般需要重新加载一下，可以理解为将他们放在一个文件里面，重新加载就是覆盖过去

./nginx -s reload #注意到相应的目录，因为nginx命令他不是全局的

访问：

使用路径访问，在自己虚拟机地址后面加上80端口和81端口进行测试，若界面一样，那么就配置成功

通过域名区分不同的虚拟主机：

什么是域名：

网址就是域名，是一个网站的地址，由域名提供商提供，一般需要购买

www.baidu.com

www.taobao.com

www.jd.com

域名级别

一级域名：

比如 .com .org .cn

二级域名：

二级域名是在一级域名前加一级

二级域名：baidu.com , zhihu.com

三级域名：

www.baidu.com

image.baidu.com

域名绑定

一个域名对应一个ip地址，一个ip地址可以被多个域名绑定（这就是多个网站

通过 DNS服务器去解析域名

配置域名映射：

本地测试可以修改hosts文件，修改window的hosts文件：（C:\Windows\System32\drivers\etc）

可以配置域名和ip的映射关系，如果hosts文件中配置了域名和ip的对应关系，不需要走dns服务器

#在上面的hosts文件里面配置（加上）一下nginx的映射
192.168.164.128 www.ng.com
#其中192.168.164.128是我的对应虚拟机的ip，这里要加上你自己的虚拟机的ip

注意：若修改不了，一般是权限的问题，可以在文件上右键，点击属性，找到安全的选项

我们点击其中组和用户名那里（点击你登录的用户），可以看到对应的权限，点击编辑

可以选择对应权限（这里选择修改权限），并进行确定

然后这个用户就可以进行修改了，（一般操作自己所在用户，也就是登录进该电脑的用户）

接下来我们继续在浏览器访问，现在我们可以将原来的192.168.164.128改成www.ng.com，发现出现了对应页面，说明改变成功

但也要注意：虽然浏览器会对域名进行检查的，也就是说，当我们访问的域名是这些搜索的域名时（大多数已经存在的）

若本机配置了同样的域名，那么会使用本机的对应的地址

即浏览器会请求该地址

如www.baidu.com，你在hosts文件设置了www.baidu.com的操作，就会使用其映射的地址

所以说，当你访问某个具体网站时，若被拒绝请求，可以看看这个hosts文件是否有对应的映射域名

使用SwitchHosts，修改hosts：

下载地址：

链接：https://pan.baidu.com/s/1kPJRtIHeHR-UPrysTunAGg

提取码：alsk

在看过使用方法后，我们进行操作，进入后可以看到这个界面

介绍：上图中左下角的+号，代表创建一个文件，如下图显示

在前面的图片中，我添加了一个nginx文件，每个文件后面有个开关

只要你开启这个开关那么对应的hosts文件就会被这个开启的文件覆盖，也就是说该文件右边的内容覆盖了hosts文件

且开启后，会实时进行更新，也就是说当你改变一下，那么对应的文件就改变了，当然更新也是有速度的

你可以来回切换System Hosts这个（他就是系统的hosts文件的实时映射，即可以看成他的内容就是系统文件的hosts）

来知道对应的更新速度，当然这只是一个实验而已

若开启两个，则他们是根据顺序的添加，从上到下，第一个先覆盖，第二个添加到覆盖的对应文件内容的后面，具体自己测试

注意：当运行其他的同样的exe文件时，一般会自动退出上一个文件，然后再执行

接下来说明一下nginx的虚拟主机的真正作用：

我们先再原来的基础上进行配置，即重新操作nginx.conf文件

先删除81端口的server配置，修改本来的server，看下面的配置：

这里给出总体图（方便给您介绍，看注释，主要看server里面的注释）

worker_processes  1; #work（工作）的进程数，默认为1

#配置 影响nginx服务器与用户的网络连接
events {
    worker_connections  1024; #单个work 最大并发连接数
}

#http块是配置最频繁的部分，可以嵌套多个server，配置代理，缓存，日志定义等绝大多数功能
http {
    #引入mime类型定义文件
    include       mime.types;
	
    default_type  application/octet-stream;

    sendfile        on;
	
    keepalive_timeout  65; # 超时时间
	
    #一个server代表一个虚拟主机，可以配置多个server
    server {
        #监听的端口
        listen       80;
        
        #监听地址
        server_name  www.t1.com; 
		
        #默认请求配置
        location / {
            root   html-t1; #请求的文件夹，默认去操作安装后的nginx里面进行访问
            index  index.html index.htm; 
            #请求的文件夹里面的文件，即这里就是页面，根据文件来看对应的index.htm是可以删掉的
            #实际上删掉也无影响
        }    
        
        #错误提示页面
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        } 
    }
	
	#设置新的域名，不同的虚拟主机
	server {
        listen       80;
		
        server_name  www.t2.com; #可以直接是ip的
		
        location / {
            root   html-t2;
            index  index.html index.htm;
        }    
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        } 
    }
    
}

#注意：若端口和域名（这个可以直接是ip）都相同，重新加载或者启动一般会出现提示（其他的操作可能也会出现，如关闭nginx）
#但是并不会影响访问和端口的占用以及关闭占用，或者说不会影响他们的命令操作
#只是给你提示而已（实际上提示的对应的地方不会加载到内存）
#其中配置在后面的server不起作用了，因为不会加载到内存（重新部署会重新加载内存），所以只会执行前面的相同配置

根据上面的配置，我们需要进行两个文件的拷贝：

在nginx里面进行操作如下命令：

cp -r html html-t1
cp -r html html-t2

再次重新加载，命令：

./nginx -s reload

这里要说明一下，寻常的服务器我们在操作资源时，是进行同一处理的，而我们改变资源时（文件）

一般需要重新部署进行操作，如你改变html文件，那么就需要重新部署，使得对应的真正访问的文件资源是最新的，然后放入内存

而nginx当你改变对应的文件时，如配置文件，然后重新加载

与重新部署一样，但他是在原来的基础上进行修改，然后部署，然后放入内存

并没有像服务器一样，是统一放在访问的文件资源里的，但结果都是一样的

注意：可能会出现的一个问题，你重新加载时，可能浏览器会保存你上一次记录

即当我们第一次访问时，还是原来的页面，被访问后就没了

所以会出现需要浏览器刷新两次才会显示真正的页面，一般我们可以清除浏览器的记录，使得不会出现这种情况

这种情况一般是很少见的，可能与你大幅度的访问有关

我们发现，明明域名对应的ip是一样的，但是访问的资源却不一样，这就要看域名的路径名称了

一般的我们需要进行三次握手确定客户端和服务端的连接（接收和发送能力都互相知道）

我们在连接的过程中，就会考虑域名到ip的变化

我们一般是使用解析后进行对这个ip（这时客户端，即主机会进行DNS的服务器访问），即解析的ip进行三次握手连接

但其中连接后，我们进行访问资源

这时，由于ip的变化是三次握手时，进行变化的，所以我们访问资源时对应的网址并不是真正的变化，即到达请求头中了

而对应的虚拟主机，或者说nginx的多个配置，当其中一个的配置

如server的配置的对应域名正好与这个请求头对应的域名匹配时，那么就使用这个配置，或者说虚拟主机，端口自然也是如此

但是要注意：域名只是大致区分，也就是说，在端口相同的情况下，就看域名（在对应配置也可以直接是ip），端口不同的情况下

就看端口（这时就出现了不同域名资源一样），即监听端口，若不是对应端口，自然不会走这个配置，所以无论是直接的还是域名的间接的，最终ip要正确，才可进行这样操作

所以将上面第二个server的80改成81端口时，然后www.t1.com域名访问81端口后，出现的资源显示是第二个server的资源

即优先看端口，然后看域名，因为虽然说是不同域名，但对应的ip却是一样的，只是用来区分不同资源而已

而端口则真正的表示不同的主机了，就如前后端分离一样是不同端口，但由于域名使得资源不一样，所以也就被称作不同的主机

因为不同的服务器主要就是资源的差异，即nginx的虚拟主机就一般让端口和域名联系

这也使得不同的域名出现不同的网站

虽然对应ip是一样的，且要注意，对应ip要存在，否则这些操作是对应ip的服务器操作

若没有的话，或者没有配置这些操作，自然是操作不了的

即看起来是不同的网站了，实际上是资源的分配

由原来端口不同的分配，加上了域名的分配了，使得域名和端口的对资源的作用是一样的了

所以虽然只有一台服务器，但是这台服务器上运行着多个网站

访问不同的域名或者端口（端口一般不变，因为在实际情况中一般都是80端口）

所以就出现了不同的域名（实际上与端口同级作用），就可访问到不同的网站内容

反向代理：

什么是代理：

代理其实就是一个中介，A和B本来可以直连，中间插入一个C，C就是中介

刚开始的时候，代理多数是帮助内网client访问外网server用的

客户机在发送请求时，不会直接发送给目的主机，而是先发送给代理服务器

代理服务接受客户机请求之后，再向主机发出，并接收目的主机返回的数据再发送给客户机

正向代理：

比如我们国内访问谷歌，直接访问访问不到，我们可以通过一个正向代理服务器

先将请求发送到到代理服务器，代理服务器能够访问谷歌，将代理服务器称为a，谷歌称为b，我们称为i

这样由a去b取到返回数据，再返回给i（我们），这样我们就能访问b了

正向代理代理的是客户端，服务端不知道实际发起请求的客户端（因为收到的请求不是客户端发送的，而是代理服务器发送的），而反向就是客户端不知道对应接收的服务端是谁

反向代理：

反向代理和正向代理的区别就是：正向代理代理客户端，反向代理代理服务器

正向代理来解决原来客户端访问不到的地址，因为代理服务器可以访问得到，即由代理服务器来发送请求

反向代理来解决请求的地址

然后根据已有的要操作的服务器来进行请求服务器（如后面的负载均衡，和代理模式下的资源访问）

由代理服务器来接收请求并请求对方服务器

反向代理是指用代理服务器接收客户端的请求

然后将请求转发，不是服务器的转发，相当于服务器去请求，服务器之间也可以进行访问，就如客户端和服务器端互相访问一样，只是一般我们没有接触而已，都是协议相关的操作

给网站内部应用服务器（可以看成前后端分离的访问）

一般都是内部的，所以一般都是先配置好的

并将从服务器上得到的结果返回给客户端

可能你会有疑惑：如果按照对应参照来看，实际上他们都是差不多的，或者是一模一样的

实际上他们的差别就在于中间的这个服务器是干什么的

正向代理是用来帮助请求（实现远程请求），而反向代理，是用来处理请求（将合适的请求进行请求）

而正是因为一个服务客户端，一个服务服务器，所以我们一般将前者称为正向代理，后者就叫做反向代理

注意：客户端与正向代理服务器之间一般是需要配置客户端访问的正向代理服务器的地址的

而反向代理服务器由于是与要操作的服务器一起，一般使用时通常都会配置好的

所以我们一般需要在使用正向代理时才会进行配置

Nginx实现反向代理：

Nginx作为反向代理服务器安装在服务端，Nginx的功能就是把请求转发给后面的应用服务器

配置步骤（来配置反向代理）：

第一步：简单的使用2个tomcat实例模拟两台http服务器，分别将tomcat的端口改为8080和8081

复制，解压操作自己去完成

回顾端口号改变：

我们首先到一个tomcat里面，再进入conf里面，打开server.xml文件：

找到8005改成8006，8080改成8081，8443改成8444，找到这些数字，然后改变，之后保存退出，这都是修改端口，避免冲突的

第二步：启动两个tomcat

在这之前，你也可以修改tomcat里面的webapps的ROOT目录下的index.jsp文件

使得区别，当然也可以不修改，因为只是用来区分的，在底行模式下

可以输入"/对应名称"

注意，没特别说明的，分号一般是进行包括的，即不会写上，即这里就是/对应名称，分号只是用来分开的作用

可以进行查找对应名称

只会找光标后面行对应第一个名称，光标在他前面

执行后（其他执行也是如此），则默认在命令行模式下了，即按下esc是没用的）

./bin/startup.sh #到每个tomcat里进行启动
#访问两个tomcat
http://192.168.164.128:8080/
http://192.168.164.128:8081/ 

第三步：反向代理服务器的配置（在前面的nginx.conf文件下添加如下）

#反向代理的配置	
	upstream lagou1{	
	#用server定义http地址
	server 192.168.164.128:8080;
	}
	
	server {
        listen       80;
        server_name  www.lagou1.com;	
        location / {
		    #proxy可以将我们的请求代理到对应的upstream
			#root   html-t2;  这个可以写上，因为代理模式优先于这个，即写上相当于没有作用
			proxy_pass http://lagou1;  #替换一般并不会替换匹配后的路径，所以如果是www.lagou1.com/a，那么a在后面，如http://192.168.164.128:8080/a
			#转发的地址，自然需要注明协议，将读取到的lagou1使用上面的反向代理配置的进行替换
			#使得就是请求地址了，即http://192.168.164.128:8080
			#当然了，我们也可以直接输入http://192.168.164.128:8080
			#因为代理没用起到对应作用时，是不会进行转发的
            index  index.html index.htm; #在代理时，这个写上也是没有用的
        }    
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        } 
    }
	upstream lagou2{
	#用server定义http地址
	server 192.168.164.128:8081;
	}	
	server {
        listen       80;	
        server_name  www.lagou2.com;	
        location / {
		    #proxy可以将我们的请求代理到对应的upstream
			proxy_pass http://lagou2; #转发的地址
            index  index.html index.htm;
        }    
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        } 
    }
    
    #注意：http://是固定格式，否则这一行是不会加载到内存的，重新加载就会使得内存重新加载
    #他会根据后面的名称，找到对应的upstream lagou2，然后访问对应的地址，将获得的响应信息返回给自己
    #然后再返回给我们，中间有一个标识，用来确定客户端的
    #这就相当于一个中间服务器了

第四步：nginx重新加载配置文件（这一步不要忘记）

./nginx -s reload

第五步：配置域名，在hosts文件中添加域名和ip的映射关系

要识别对应域名，到对应的虚拟主机才行，这里修改一下前面的配置域名，如下：

通过浏览器输入域名，访问Nginx代理服务器，Nginx根据域名将请求转发给对应的目标服务器

作为用户我们看到的是服务器的响应结果页面，在整个过程中目标服务器相对于客户端是不可见的

服务端向外暴露的就是Nginx的地址

负载均衡：

什么是负载均衡：

当一个请求发送过来的时候，Nginx作为反向代理服务器，会根据请求找到后面的目标服务器去处理请求

这就是反向代理与正向代理的主要区别

那么，如果目标服务器有多台的话，找哪一个服务器去处理当前请求呢 ?

这个合理分配请求到服务器的过程就叫做负载均衡，所以我们一般可能会出现两个问答：如反向代理和负载均衡的区别

实际上负载均衡只是一种方案，对应请求的方案，可以说是他是在反向代理上的一种方案

所以说，就算不是反向代理服务器，如果其他服务器也有这样的操作，那么也能叫那个服务器为负载均衡服务器

但通常情况下，一般只有反向代理才好操作负载均衡

所以一般情况下，反向代理和负载均衡是结合起来使用的

为什么用负载均衡：

当系统面临大量用户访问，负载过高的时候，通常会使用增加服务器数量来进行横向扩展（使得不会全部访问一个服务器）

负载均衡主要是为了分担访问量，将请求合理分发给不同的服务器，避免临时的网络堵塞，这就体现了代理服务器的作用了

但这里你可能会有疑问，所有的请求都给代理服务器，那么代理服务器不就像没有使用负载均衡一样集中在一个服务器吗

首先要知道在传统的情况下，我们所有的资源，都放在一个服务器里面，这时用户的所有请求都是在一个服务器里面

当请求过多时，这是肯定不行的，万一服务器出现故障，那么所有的用户基本都不能请求了

所以我们需要将资源进行分开（一般都是复制服务器），就如分成多个网站一样，这时一般需要域名的变化了，也就是反向代理

也就是前面说的使用域名来访问不同的网站，之所以端口不操作，因为用户一般都是固定端口，也就是80端口（http默认80端口）

但是我们虽然分成了多个网站，即其中几个出现故障了，其他网站还是可以操作的，实际上一般都不会完全分开

也就是直接复制，使得不同域名的网站功能齐全

但可以发现，实际上相当于重新创建一个网站一样

但并不能完全的决定其请求的多少，如果用户多次在同一个地方进行请求（同一个域名的地方）

因为我们也不能完全使得用户知道其他域名

那么也就相当于那个网站还是被多次请求的，虽然也可以提升服务器性能，但是就与传统的操作一样了

很显然这还是有问题，若可以自动的分配就好了，而负载均衡就是这样，而正是因为可以自动分配

使得域名统一，且不会到固定的服务器，用户只需要一个域名即可，且对应的网站也实现了分配得到请求

这时我们回到最初的问题，代理服务器如何处理多次请求，通过前面的分析我们知道，我们要防止单个服务器出现故障

一般都会采用代理，而不是自动分配的代理，一般就与传统的服务器类似，所以虽然使用负载均衡的这个代理

被多次请求，但是却比前面的两种方案要更加的好操作，因为反正都是同样的请求，也基本都是给一个服务器

但是负载均衡却可以处理更多的请求，其他的一般是对原始服务器进行处理，若出现了故障，那么就危险了

所以我们就使用了负载均衡来使得其中一个没有（宕机），可以自动到另外一个（机器或者服务器），根据上面的说明，我们也不难知道，负载均衡器本身也可能成为性能瓶颈的情况，这是可能发生的（因为他也是服务器，你不也是多次访问他吗，这与你多次访问其他服务器有什么区别呢），负载均衡器也需要处理大量的请求，并将它们转发到后端服务器，如果负载均衡器的处理能力有限或配置不当，它可能成为系统的瓶颈，导致请求延迟或性能下降，所以一般情况下我们会有如下解决方案：

即为了避免负载均衡器成为瓶颈，可以采取以下措施：

1：引入多个负载均衡器：使用多个负载均衡器形成负载均衡器集群，将负载均衡的任务分摊到多个负载均衡器上（他们互相联系），这样可以增加整个系统的负载均衡能力，提高容错性和可用性，

2：升级硬件或增加资源：如果负载均衡器的性能达到瓶颈，可以考虑升级硬件（如增加处理器、内存等）或增加资源（如使用更高性能的网络设备）来提高其处理能力

3：使用专用负载均衡器：针对高负载场景，可以选择使用专用的硬件负载均衡器或高性能的软件负载均衡器，它们具有更强大的处理能力和更高的吞吐量。

4：优化配置和算法：对负载均衡器进行适当的配置和调优，选择合适的请求分发算法（如轮询、加权轮询、最小连接数等），以提高负载均衡器的性能和效率

需要注意的是，负载均衡器本身也需要被适当地进行扩展和优化，以满足系统的需求，并且，系统的整体架构和后端服务器的处理能力也需要与负载均衡器相匹配，以确保整个系统的性能和可伸缩性

综上所述，尽管负载均衡器可能成为性能瓶颈，但通过采取合适的措施和策略，可以减轻负载均衡器的压力，并提高整个系统的性能和可用性

由此看来负载均衡的主要操作就是将请求进行分开处理，并且根据这个请求来使得到某个服务器，即主要是解决目标服务器宕机的问题，而非解决请求负担，所以如果说，负载均衡是为了解决请求的负担，这一般是错误的，因为负载均衡器自身就存在负担，一般情况下，负载均衡器在负担的情况，设置的集群是一个整体，具体的思路有很多，比如通过时间来确定主体等等（判断主体的时间是极少，就算是千万，也可以忽略，比如说，如果一千个用户给服务器的一个变量加1，会导致服务器宕机吗，答：一般不会，因为处理的少，负担少，即通常来说，减少对资源的操作可以降低服务器的负载，但是他还是存在操作的，这也就为什么在双11时，就算是非常好的软件公司，也会存在响应慢的情况，甚至是宕机，当然，现在的技术基本可以满足全人类，但是有个临界点，当然，随着时间的推移，技术的发展，这个临界点也会越来越大，以当前的人类数量或者对应访问网络的物体，一般还不足以超过这个临界点，使得直接宕机，所以在当前来看，只要你使用好的架构策略，基本就能满足请求而不会发生宕机的情况，当然，前提是请求导致的宕机，因为宕机有很多情况，比如网络等等，所以这里有个前提，就是请求导致的宕机），具体可以百度

负载均衡策略：

轮询：

默认策略，每个请求按照时间顺序逐一分配到不同的服务器，如果某一个服务器下线，访问时能自动剔除

当访问到时，一般需要访问很久，因为剔除需要时间或者超时时间跳过，他自己剔除（做个标记，后面不经过他了），然后继续到正常的轮询，即到下一个，当然可能也是需要配置

之所以会自动剔除，是因为每隔一段时间会检查对应操作的地址是否出现宕机，比如ping命令进行操作等等

这也基本使得不会指向宕机的服务器，当然，如果是访问时，出现宕机，那么自然会轮询到后面去（即上面说明的：剔除需要时间或者超时时间跳过，他自己剔除）

#配置负载均衡
	upstream lagouedu{
	#用server定义http地址
	server 192.168.164.128:8080;
	server 192.168.164.128:8081;
	}	
	server {
        listen       80;	
        server_name  www.lagouedu.com;	
        location / {
		    #proxy可以将我们的请求代理到对应的upstream
			proxy_pass http://lagouedu; #转发的地址
            index  index.html index.htm;
        }    
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        } 
    }
    
    #可以发现，实际上就是多加了一个server在对应的地址变化里
    #这是nginx自带的负载均衡默认策略，因为nginx封装了对应操作
    #所以我们的nginx也可以叫做代理负载服务器

注意：记得加上对应域名

你在测试时，由于是按照时间顺序分配的，这个时间是看后面一个时间是否比前面一个时间大，若大，则操作下一个server

所以，会先执行8080端口的资源，然后执行8081端口的资源，在然后执行8080端口的资源（到最后一个时，下一个就是第一个）

以此类推，这样请求就被平均分配了

可能你在测试时，不会出现这样的情况，那么应该是缓存的缘故，可以清除缓存

还有一个更好的办法，那就是无痕的浏览，如谷歌的，右上角点击后，出现的打开新的无痕式窗口选项

则会打开无痕没用缓存的窗口，这样就更好操作了

但是平均分配的缺点有一个，那就是服务器的性能是不同的，若有些内存小的，可能处理不了这么多请求（平均下来也是）

那么就需要合理的分配了

weight：

可以根据服务器的实际情况调整服务器权重，权重越高分配的请求越多，权重越低，请求越少，默认是都是1

实际上是根据算法来进行权重的比例，来决定概率性的分配

修改上一个的部分配置，如下

server 192.168.164.128:8080 weight=1;
server 192.168.164.128:8081 weight=10;

这是当我们重新加载测试时，可以发现，多次的刷新，8081的出现几率要大很多

那么到这里，你会发现nginx这个服务器是非常优秀的服务器，现在一般使用nginx服务器

那么接下来我们使用这个服务器来操作前后端的部署

项目部署与发布：

后台项目部署：

Linux环境准备：

需要安装的软件：

软件	版本
JDK	11
Tomcat	8.5
MySQL	5.7
Nginx	1.17.8

记得关闭防火墙

使用SQLYog连接Linux上的MySQL，导入SQL脚本，创建项目所需的数据库

上面的操作自己进行，不知道的可以看看55章博客和60章博客

sql脚本地址：

链接：https://pan.baidu.com/s/1kmi4h6WmJx724sKMv8P1Zg

提取码：alsk

项目打包发布：

在平常开发的过程中，不同的环境中项目的相关配置也会有相关的不同

我们在不同的环境中部署就要手动修改为对应环境的配置，这样太麻烦了以及这样也会很容易出错

接下来我们就通过maven的相关配置来在打包时指定各个环境对应配置文件

修改ssm_dao 子模块：

第一步：创建配置文件

在项目的src/main/resources 下面创建filter目录，再创建development.properties，product.properties两个文件

development是开发配置内容，没有部署时的配置（即打包时的配置）：

jdbc.driver=com.mysql.jdbc.Driver
jdbc.url=jdbc:mysql:///ssm_lagou_edu?characterEncoding=utf8&useSSL=false
jdbc.username=root
jdbc.password=123456

product是正式配置内容，也就是部署时使用的配置（即打包时的配置）：

jdbc.driver=com.mysql.jdbc.Driver
jdbc.url=jdbc:mysql://192.168.164.128:3306/ssm_lagou_edu?characterEncoding=utf8&useSSL=false
jdbc.username=root
jdbc.password=QiDian@666

第二步：配置jdbc.properties 文件

jdbc.properties中的内容不再写死，而是从上面两个文件中获取

jdbc.driver=com.mysql.jdbc.Driver
jdbc.url=${jdbc.url}
jdbc.username=${jdbc.username}
jdbc.password=${jdbc.password}

注意：${jdbc.url} 直接对应上面配置的development.properties或product.properties文件中的名称

第三步：配置dao模块的的 pom.xml文件（使得去哪个配置文件里读取）

添加如下配置：

<profiles>
        <profile>  <!--指定环境配置文件-->
            <id>dev</id> <!--设置名称-->
            <properties>
                <!-- 开发环境 -->
                <env>development</env> <!--指定文件名称-->
            </properties>
            <activation>
                <activeByDefault>true</activeByDefault>
                <!--没指定环境时，默认取设置了这个为true的环境，即这里默认是开发环境-->
            </activation>
        </profile>
        <profile>
            <id>prod</id>
            <properties>
                <!-- 正式（生产）环境 -->
                <env>product</env>
            </properties>
        </profile>
    </profiles>

    <build>
        <finalName>web</finalName> 
        <!--设置打包后，对应的包名，只是当前pom.xml所在的项目，而不是所有的项目-->
        <filters>
            <filter>src/main/resources/filter/${env}.properties</filter>
            <!--操作对应路径的配置文件，在什么环境下，对应的env就变成对应环境的文件名称-->
        </filters>
        <resources>
            <resource>
                <!--指定目录-->
                <directory>src/main/resources</directory>
                <excludes>
                 <!--指定上面的目录下的，如src/main/resources目录，并指定下面配置目录下的文件不进行打包--> 
                    <exclude>filter/*.properties</exclude>

                </excludes>
               <!--
指定配置文件之间是否可以进行变量替换，默认为false
这里要使得配置文件之间进行变量替换，那么这里就需要是true-->
                <filtering>true</filtering>
            </resource>
        </resources>
    </build>

配置完后记得刷新

这里可能会出现两个问题：

第一个问题：当我们设置了< filtering>true< /filtering>为true时，对应的编码方式则使用了idea或者系统的编码方式，一般都是idea

即我们在配置文件中，原来的< ?xml version=“1.0” encoding=“UTF-8”?>中UTF-8的这个字符编码在进行编码后

一般由idea的对应编码进行解码显示，但是当设置了true时，对应的解码由idea的对应编码来解释

而这个编码一般是根据最近的来解释（通常是GBK），使得编码出现问题

你可以去设置中找到FIle Encodings里全部进行UTF-8的操作，主要还是看距离（如直接指定文件），当然GBK也并非不能操作

只要对应的编码和解码一样即可

当然也可以在pom.xml里面的< properties>标签里加上<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

也可以在< ?xml version=“1.0” encoding=“UTF-8”?>中的UTF-8改成GBK也可，来进行编码的设置

第二个问题：我们使用了true，那么就会进行变量替换，在替换的过程中，可能有些符号不会被识别，或者需要特殊处理

最好先启动进行测试，然后再进行打包操作，防止出现上面两个问题

使得部署了，但启动时对应的包却有些没有操作，使得报错，即访问不了

如&符号，这时我们就需要将：

//&变成&
//使得可以被操作

只要是使用上面的替换，一般会这样，所以这个时候，无论是开发环境的替换，还是生产环境的替换，对应都需要这样操作

当然了，如果报错，后续的放入内存，就基本不会操作了，所以这就会出现两种情况

当使用idea服务器直接的启动时（一边编译，一边放入内存，基本一起操作），那么对应的在替换时的放入内存会出现问题

所以发现并没有进行替换（将包复制出来，可以看到）

而直接打包，是只会编译，而不放入内存，所以不会出现问题，即可以发现替换了，但实际上只要执行就会出错

对应的maven出现：

可以选择，但是若都没选择，那么对应的${env}里面的env标签就没有，所以刷新时，就会有报错，一般都默认dev

设置了< activeByDefault>true< /activeByDefault>的，一般当你取消勾勾时

若没有其他勾选，那么就会出现还没有完全取消，需要在取消一下才可完全取消（即有隐藏的勾选），你可以通过实验来观察

profile说明：

profile可以让我们定义一系列的配置信息，然后指定其激活条件

这样我们就可以定义多个profile，然后每个profile对应不同的激活条件和配置信息，从而达到不同环境使用不同配置信息的效果

默认启用的是dev环境配置：

 <profiles>
        <profile>
            <id>dev</id>
            <properties>
                <!-- 开发环境 -->
                <env>development</env>
            </properties>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
        </profile>
        <profile>
            <id>prod</id>
            <properties>
                <!-- 正式（生产）环境 -->
                <env>product</env>
            </properties>
        </profile>
    </profiles>

定数据库配置文件路径，此路径可以自定义：

<filters>
	<filter>src/main/resources/filter/${env}.properties</filter>
</filters>

指定资源目录路径：

<resources>
    <resource>
        <directory>src/main/resources</directory>
        <!-- 资源根目录排除各环境的配置 -->
        <excludes>
        	<exclude>filter/*.properties</exclude>
        </excludes>
        <filtering>true</filtering>
    </resource>
</resources>

第四步：打包

命令打包：

在这之前先clear一下，最好这样操作（因为可能不会覆盖，但大多数情况下会覆盖）

#打本地（开发环境下的）包（-Pdev）
mvn -Pdev install
#或者
mvn install #因为本例activeByDefault配的为true
#打产品（生产环境下的）包（-Pprod）
mvn -Pprod install
#结果：src/main/resources/config/jdbc.properties根据 mvn -P 参数决定值

#若要看看区别，可以复制对应的包，看看jdbc.properties的结果

这里有如下情况：

都没有选择（maven的选择）：无论是打包还是安装都会报错

选择一个：根据配置顺序来说，当选择的那一个是最后配置的，那么打包和安装都是选择的那一个

若不是后配置的，则mvn install打包安装选择的，其他的mvn -Pdev install是开发环境的打包，mvn -Pprod install是生产环境的打包

选择多个：与选择一个类似的，也是根据后配置来决定，而多个则按照多个里面的后配置，这时mvn install也会按照后配置的了

发布：

将打包好的war包放在一个服务器（tomcat）里面

如图所示：

这里我们重新创建一个tomcat了，并命名为ssm-tomcat

我们将ssm_web-1.0-SNAPSHOT.war改一下名称，并创建一个upload文件夹

因为后端是需要这个文件来保存图片的（当然了，后台也设置了没有对应目录也会进行创建的，所有删掉也是没问题的）

启动一下，要注意，先关闭前面的tomcat才可，虽然你启动时，没有报错

但实际上由于冲突问题，并没有进行完全启动，只是给你初始化而已，比如，自动帮你进行解压war包

具体可以到上面的logs里面，使用命令

tail -f catalina.out

若看到出现的日志最后出现如下（或者类似于这样的形式）：

那么一般就启动成功

若出现了如下：

这个一般就是端口被占用出现的错误，即前面启动时虽然没用报错，但日志其实已经出现错误了

启动后进行访问：

http://192.168.164.128:8080/ssm_web/courseContent/findCourseByCourseId?courseId=7

注意：启动后服务器若是自动的操作war包解压的话，那么当你删除war包时，对应的目录文件也会删除

但删除要时间，所有当你删除war包时，可以当时看得到该文件，过一会就没了，这是在启动的时候，若关闭后则没用这些操作

若响应出数据，那么就部署成功了

前端项目部署：

修改配置文件：

生产环境配置文件，配置后台URL

这两个上面一个是开发环境，下面一个是生产环境

我们将生产环境替换对应的属性如下：

VUE_APP_NAME = Edu Boss
VUE_APP_TITLE = Lagou Edu Boss (Dev)

VUE_APP_STORAGE_PREFIX = lagou_edu_boss_dev

#VUE_APP_API_FAKE = /front
VUE_APP_API_FAKE = http://192.168.164.128:8080/ssm_web

#VUE_APP_API_BASE = /boss
VUE_APP_API_BASE = http://192.168.164.128:8080/ssm_web

#VUE_APP_API_BASE = http://localhost:3000

#注意：其他同样的记得注释掉，否则后面的覆盖前面的，除非你放在最后面，那么就可以

当然测试时，也可以使用修改开发环境

将下面内容拷贝到 vue.config.js（配置打包的信息）：

module.exports = {
  publicPath: process.env.NODE_ENV === "production" ? "/edu-boss/" : "/",
  indexPath: "index.html", //入口文件
  assetsDir: "static", //文件放置位置
  lintOnSave: process.env.NODE_ENV !== "production",
  productionSourceMap: false,
  devServer: {
    open: true,
    port: 8081
  }
};

打包测试操作：

打包命令：

npm run build #打包时，使用的是生产环境的配置

在项目下会生成一个 dist 目录：

当然，再次进行打包时，一般都会删掉该目录，然后创建

在本地tomcat的webapps目录下，创建一个edu-boss文件夹

之所以创建这个名称，是因为对应打包的项目就是edu-boss，即其中的资源一般都会使用到这个名称，所以这个名称需要一致

将dist目录中的文件拷贝到里面

测试：启动本地tomcat，访问前端项目，路径为：

http://localhost:8081/edu-boss/ 
#注意：若没有设置的话，那么端口是操作8080的，最好改成8081，因为一个端口基本只能操作一个项目

上面也就相当于我们在vs code里面运行时出现的http://localhost:8081/

只是他放在一个项目里了，而vs code将实际上也是执行，但我们一般在项目下执行，也就没有对应名称了

发布前端项目：

在这之前，首先说明一下tomcat的一些细节以及跨域的细节：

tomcat的细节：

若配置了tomcat的环境变量，且名称是CATALINA_HOME

该tomcat的环境变量的配置，无论对于Windows的环境配置还是Linux的环境配置，基本都有如下的解释：

CATALINA_HOME这个名称基本不能改变，虽然Path设置的是全局的命令参数

但使用全局的启动时（对应目录要正确，否则全局找不到对应命令），是需要这个名称的，也就是说

虽然你设置了全局命令参数，但是使用全局命令参数时，若不是这个名称，那么就不会执行

所以启动时会先判断是否是全局启动，若是，如果不是这个名称，那么不执行

若不是全局启动，若有这个名称，那么就操作这个名称所对应的tomcat的启动，若不是这个名称，那么就是对应的tomcat的启动

若是这个名称，但是对应的目录的最终指向，不是对应的存在的tomcat的目录（里面就是tomcat的文件了）

那么就会直接退出启动，但要知道，他们只是针对我们手动的执行，因为我们手动的执行，是按照对应配置的

若是idea的执行，则会使得对应配置不同，则不会操作这个名称，即idea操作哪个tomcat，那么基本就是哪个tomcat

其中只是对应的副本而已，所以只会操作副本的资源，即一般没有传统的tomcat主界面，即一般只操作你编写的资源

但是也要注意，虽然idea是操作对应的tomcat的副本，但是他启动后，对应的主要tomcat也就不能再次启动了

最后都会因为该tomcat被占用而退出（副本占用）

跨域的细节：前面说过，当协议，域名，端口不同时，那么就是跨域

跨域一般只有在浏览器之间会进行操作（基本只操作浏览器，即浏览器的跨域，为了保护浏览器的安全的，一般针对某些标签或者操作等等，一般url不受限制，即跨域是浏览器对某些操作的约束，有些标签不考虑跨域，如link，script，img等等），其他的基本没有跨域，就如nginx可以访问我们，我们也可以访问nginx（实际上是因为nginx的反向代理的原因导致的，反向代理，也就是转发的操作，一般情况下，servlet的转发和重定向，是没有跨域问题的，虽然前端的js操作可能会，但是，我们访问时的url是没有的，所以当我们访问nginx时，他的转发，并不会出现跨域，即我们并不需要设置跨域的问题，因为他是服务器的行为，而不是浏览器，当然无论是前端没有设置跨域，还是后端没有设置跨域，出现的问题提示基本都在前端，要么后端返回对应信息，或者前端自己返回对应信息，总而言之，跨域基本只会出现在第一次访问的时候）

一般的前端有些操作需要设置可以跨域，使得可以携带cookie，但是这只是携带，为什么这样说，看如下的解释：

当我们进行请求时（实现了跨域的设置），一般会得到对应服务器的cookie

这个cookie一般也就是session对应的独特id，即JSESSIONID（小写是jsessionid），当然还有你设置的cookie，前提是你设置了

这个id是用来确定对应session的，这里简称为jid

一般情况下，当我们接收到这个jid时，可以根据jid来得到对应session，但是这里有一个点需要注意

在根据jid得到session之前，需要判断对应的ip地址是否相同，或者域名是否相同

换言之，就是看端口前面的是否相同（因为会在请求里，即可以操作）

若不相同，那么对应cookie就不会得到，那么也就不会根据这个jid来得到对应的session了，相当于没有cookie过去一样

即会创建一个新的session，即会有新cookie响应回去（同样的value会覆盖）

也就是说，当出现这种情况时，即不同ip直接的访问时，你会发现，每次的访问，在对应使用的session时，也就是在对应程序里时

对应得到session的值一般都为null，当然对应的cookie也是null，因为已经是新的session了，所以跨域也只是解决了可以携带cookie

但没有解决是否同ip，使得cookie不同，当然若要解决的话，我们也可以根据全局的ServletContext来解决

如将存放的对应信息不放在session里面或者cookie里面（也是null）

而全局的ServletContext里面，根据他们的value来操作对应的值

最后：有些命令一般都是有进程的，如grep

所以当你进行对应模糊查询进程时，会发现，始终剩下一个进程，那个进程一般就是grep进程

且使用补齐时，需要确定保证当前用户可以访问到该文件，否则不会补齐

若tomcat与前端项目端口冲突，那么虽然启动时，启动了，但是实际上并没有完全启动

执行时并没有如何操作对前端的冲突而已，所以你会看到对应的窗口没有关闭，但他还是会占用除了对应前端端口的其他端口的

即其他同样的tomcat对应端口会冲突，使得自动关闭（tomcat之间会直接关闭），当然对应的前端端口就可以是一样的了

但前端与tomcat冲突时，会直接换一个端口，基本都是+1执行

接下来我们操作前端项目：

解压一个新的tomcat，修改端口号

edu-tomcat是前端项目存放处，ssm-tomcat是后端项目存放处

#解压
tar -zxvf apache-tomcat-8.5.55.tar.gz
#改名
mv apache-tomcat-8.5.55 edu-tomcat

#修改端口号
cd edu-tomcat/conf/
vim server.xml 

上传前端项目到 webapps：

#压缩edu-boss
edu-boss.zip 
#上传edu-boss.zip，并解压，注意：我们先创建edu-boss文件夹，然后将该压缩包放入里面并解压
unzip edu-boss.zip 
#删除edu-boss.zip
rm -rf edu-boss.zip

运行前端项目，并访问

./bin/startup.sh #前后端服务器都运行
#动态查看日志，当有新的日志时，会实时的刷新，即会发现出现了新的日志给你看 -f的作用
#没有参数默认显示最后10行，显示时会受窗口，变成多行
tail -f logs/catalina.out 
#访问
http://192.168.164.128:8081/edu-boss/

修改tomcat默认访问项目：

使用notepad++打开前端tomcat的配置文件server.xml，找到Host标签

在Host标签内加入：

<Context path="" docBase="edu-boss" reloadable="true" debug="0" privileged="true"></Context>
#配置/目录默认到edu-boss，即可以不用写edu-boss了
#直接写http://192.168.164.128:8081/

重新启动并访问前端项目，这个时候只需要直接访问 8081即可

注意：tomcat自己也会有冲突的，并不会因为自己启动后，再次启动会关闭之前的

所以在改变配置文件时，最好是先关闭，再启动

配置反向代理：

使用notepad++打开nginx的配置文件nginx.conf

配置反向代理：

先将前面的对应server都删除，不删除也可以，但为了方便，就删除

#配置ssm项目 反向代理
	upstream lagouedu{
		server 192.168.164.128:8081;
	}
	
	server {
        listen       80;
        server_name  www.edu-boss.com;

        location / {
			
            proxy_pass http://lagouedu;  #转发的地址
            index  index.html index.htm;
        }
    }

记得刷新：

./nginx -s reload

修改本地hosts文件，配置域名映射

接下来可以直接访问www.edu-boss.com这个了

对应前端和后端的代码地址如下（自行配置）：

链接：https://pan.baidu.com/s/15iFqDYg0o9q_V37dgYA1zw

提取码：alsk