第八天（nginx第二篇）-526互联

4. 正向代理实现在前面的案例中，我们了解了nginx作为静态服务器时的应用，如果作为静态服务器，则nginx也只是起到了运行静态资源的用。如何通过nginx实现正向代理呢？

比如：我想百度点隐私问题- -！，想通过nginx正向代理实现对百度的访问，这样百度向上记录ip的时候就只能记录nginx服务器的ip地址，而不能知道真实访问的ip地址了。

目前访问nginx是这样的，如果访问这个地址直接显示的是百度搜索，那就证明成功了

配置文件

server {
listen 80;
location / {
proxy_pass http://www.baidu.com;
}
}

访问测试 nginx可以作为http的正向代理服务器，但是不能用做https的正向代理服务器。因为http正向代理使用的是 get请求，但是https使用的确实connect请求，而nginx不支持connect请求。所以需要第三方模块 ngx_http_proxy_connect_module 来支持https的正向代理。

5. 反向代理实现我们通过反向代理让nginx代理tomcat服务器，如果tomcat已经有运行的项目，那么我们也可以通过ip+端口直接访问，也可以通过nginx访问，如果通过nginx我们就能隐藏掉真实的项目ip，还可以实现负载均衡。

5.1 安装jdk

1. 将安装包存放在/usr/src 下，并解压 tar -zxvf jdk8.tar.gz

2. 配置Java环境变量 cd /etc/ 找到profile文件,末尾添加

# jdk配置
export JAVA_HOME=/usr/src/jdk1.8.0_144
export JRE_HOME=$JAVA_HOME/jre
export PATH=$JAVA_HOME/bin:$JRE_HOME/bin:$PATH
export CLASSPATH=$CLASSPATH:.:$JAVA_HOME/lib:$JRE_HOME/lib

1. #刷新配置 source /etc/profile

2. #查看JDK版本 java -version

5.2 安装tomcat https://tomcat.apache.org/download-90.cgi 将安装包同样存放在/usr/src 下，并解压 tar -zxvf apache-tomcat-9.0.73.tar.gz 对外开放访问的端口(如果不在window访问可以不用开放)

#开放端口 server { listen 80; location / { proxy_pass http://www.baidu.com; } }

# jdk配置 export JAVA_HOME=/usr/src/jdk1.8.0_144 export JRE_HOME=$JAVA_HOME/jre export PATH=$JAVA_HOME/bin:$JRE_HOME/bin:$PATH export CLASSPATH=$CLASSPATH:.:$JAVA_HOME/lib:$JRE_HOME/lib firewall-cmd --permanent --add-port=8080/tcp

#重启防火墙 firewall-cmd --reload 开启tomcat，在bin目录下，使用命令：./startup.sh cd /usr/src/apache-tomcat-9.0.73/bin/

然后通过http://192.168.31.100:8080/ 访问测试是否启动成功。

5.3 反向代理单台服务器

如果我想隐藏掉http://192.168.31.100:8080/这个真实地址，只希望访问nginx就可以直接代理到这个 tomcat,配置如下：

1. 直接修改nginx配置文件，并重启nginx

server {
listen 80;
server_name 192.168.31.100; #默认80端口
location / {
proxy_pass http://192.168.31.100:8080; #代理的地址
}

此时从window下测试访问192.168.31.100 默认也会访问到tomcat，原理是由地址192.168.31.100:80通过 nginx反向代理到了192.168.31.100:8080 我们可以将linux的8080端口禁止对外开放，查看效果

# 移除端口 firewall-cmd --permanent --remove-port=8080/tcp

#重启防火墙(修改配置后要重启防火墙) firewall-cmd --reload 此时window下直接访问http://192.168.31.100:8080/ 就失败了，如果访问http://192.168.31.100/ 还是可以成功的，那么我们真实tomcat下的应用就通过nginx反向代理被隐藏掉了。

5.4 反向代理多台服务器

如果单台服务器的反向代理是为了隐藏真实的服务器地址，那么代理多台服务器的目的除了隐藏地址还有可能是为了使用一个nginx地址反向代理多个项目，这样我们通过认为干预URL地址进行不同项目的请求，但是对于用户而言，我们的请求地址只有一个，具体操作如下：

1. 多复制一个tomcat文件夹

cp -r apache-tomcat-9.0.73 ./apache-tomcat9090

1. 进入文件夹config目录找到server.xml 修改端口为9090

1. 启动并配置开放端口并访问测试

2. 修改两个tomcat的/webapp/ROOT/index.jsp 区别两个tomcat 创建文件夹v1/v2 把两个文件移动到文件夹中，修改后重启两个tomcat

1. 修改nginx配置文件,并重启nginx

location ~/aaa/ {
proxy_pass http://192.168.31.2:8080;
#root aaa;
#index index1.html;
}
location ~/ww/ {
proxy_pass http://192.168.31.100:8080;
#root aaa;
#index index.html;
}
server {
listen 80;
server_name 192.168.31.100; #默认80端口
location ~/v1/ {
proxy_pass http://192.168.31.100:8080; #代理的地址
}
location ~/v2/ {
proxy_pass http://192.168.31.100:9090; #代理的地址
}
}

= ：用于不含正则表达式的 uri 前，要求请求字符串与 uri 严格匹配，如果匹配成功，就停止继续向下搜索并立即处理该请求。

~：用于表示 uri 包含正则表达式，并且区分大小写。 ~*：用于表示 uri 包含正则表达式，并且不区分大小写。

^~：用于不含正则表达式的 uri 前，要求 Nginx 服务器找到标识 uri 和请求字符串匹配度最高的 location 后，立即使用此 location 处理请求，而不再使用 location 块中的正则 uri 和请求字符串做匹配。

注意：如果 uri 包含正则表达式，则必须要有 ~ 或者 ~*标识。

1. 测试

6. 负载均衡配置

6.1 负载均衡实现我们可以将多台tomcat下的项目看做为一个集群，当我访问一个路径的时候为了分担服务区压力，我们让其通过定义nginx的负载策略实现nginx负载均衡处理

1. 修改nginx配置如下

upstream ww {
server 192.168.31.100:8080;
server 192.168.31.100:9090;
}
server {
listen 80;
server_name 192.168.31.100; #默认80端口
location / {
proxy_pass http://ww; #负载集群
root html;
index index.html index.htm;
}
}

1. 直接访问 http://192.168.31.100/ 测试发现此时已经全部分摊处理请求。

6.2 负载均衡策略 nginx的6种负载均衡策略轮询/加权轮询weight/ip_hash/least_conn/urlhash/fair

6.2.1 轮询策略(默认) 轮询策略其实是一个特殊的加权策略，不同的是，服务器组中的各个服务器的权重都是1

upstream backend {

server 192.168.31.100:8080 weight=1;

server 192.168.31.100:9090 weight=1; }

6.2.2 加权轮询策略weight 通过加入 weight的值进行加权处理，权重值越大，服务器越容易被访问，因此，性能好的服务器应适当加大权重值

upstream backend {

server 192.168.31.100:8080 weight=1;

server 192.168.31.100:9090 weight=2; }

6.2.3 ip 哈希策略 ip_hash 策略能够将某个客户端IP的请求固定到同一台服务器上，例如A用户访问服务器，通过固定算法后，被固定到 192.168.136.136 的web服务器上，那么，用户A下次访问时，依旧会到访问 192.168.136.136 服务器。因此，该策略解决了多台服务器Session不共享的问题【因为不同的客户端会被分到不同的服务器，且之后这种对应关系是不变的】 upstream backend {

ip_hash;

server 192.168.31.100:8080;

server 192.168.31.100:9090; }

该算法不能保证服务器的负载均衡，可能存在个别服务器访问量很大，很小的情况.

6.2.4 least_conn 策略

最少连接，把请求转发给连接数最少的服务器。

轮询算法/轮询加权算法会把请求按照一定比例分发请求到各服务器上，但是，有些请求占用时间长，如果把这些响应占用时间长的请求大比例发送到了某一台服务器，那么这台服务器随着时间的增加会负载比较高【因为响应较长的请求还没处理完，新的请求又来了，在这种情况下，采用 least_conn 的方式是最适合的，它能达到更好的负载均衡

upstream backend {

least_conn; server 192.168.31.100:8080;

server 192.168.31.100:9090; }

此负载策略适合用于，请求处理时间长短不一造成服务器过载的情况

6.2.5 url_hash 策略 url_hash 和 ip_hash 类似，不同的是，客户端ip可能变，但客户端发送的请求URL不同功能模块虽说不同，但同一个功能点的URL是固定不变的，该算法主要是解决缓存命中率的问题

【例如下载文件】 upstream backend {

hash $request_uri;

server 192.168.31.100:8080;

server 192.168.31.100:9090; }

6.2.6 智能的fair 策略 fair nginx默认不支持，需下载第三方模块采用的不是固定的轮询算法进行负载均衡，而是智能的根据页面大小、加载时间长短进行负载计算.

upstream backend {

fair;