Nginx+Tomcat负载均衡、动静分离

YCyjs

已于 2024-08-19 22:24:57 修改

阅读量352

点赞数 4

分类专栏：云效能文章标签： nginx tomcat 负载均衡运维 linux

于 2024-08-19 16:56:08 首次发布

本文链接：https://blog.csdn.net/YCyjs/article/details/141323259

版权

云效能专栏收录该内容

7 篇文章 0 订阅

订阅专栏

一、Nginx 应用

Nginx是一款非常优秀的HTTP服务器软件

支持高达50 000个并发连接数的响应（根据配置最多可能有10w）
拥有强大的静态资源处理能力
运行稳定
内存、CPU等系统资源消耗非常低

目前很多大型网站都应用Nginx服务器作为后端网站程序的反向代理及负载均衡器，提升整个站点的负载并发能力

1.1、正向代理和反向代理

① 正向代理

正向代理：代理的是客户端去访问服务器 加快访问速度
当客户端访问一台服务器有障碍，访问不到的时候，这时候就可以找一台可以访问到该服务器的另外一台服务器去代替他去访问，这台代替他去访问的服务器称之为代理服务器。

然后客户端就可以把请求发送给代理服务器，然后通过代理服务器去访问目标服务器。

由代理服务器将目标服务器的返回数据返回给客户端，客户端可以清楚目标服务器的地址，但是目标服务器并不清楚来自哪个客户端，他只知道来自哪个代理服务器。所以，正向代理可以屏蔽或者说隐藏掉客户端的信息。
它的工作原理就像一个跳板,简单的说,我是一个用户,我访问不了某网站,但是我能访问一个代理服务器，这个代理服务器呢,他能访问那个我不能访问的网站，于是我先连上代理服务器,告诉他我需要那个无法访问网站的内容，代理服务器去取回来,然后返回给我，从网站的角度,只在代理服务器来取内容的时候有一次记录，有时候并不知道是用户的请求,也隐藏了用户的资料,这取决于代理告不告诉网站

正向代理的过程隐藏了真实的请求客户端，服务器不知道真实的客户端是谁，客户端请求的服务都被代理服务器代替请求

访问目标服务器（不知道代理）屏蔽客户端（取决于代理告不告诉）

② 反向代理(单级)

反向代理：代理的是服务端 负载均衡

从代理中我们得知代理服务器是给客户端做代理的，他和客户端是一伙的。而反向代理呢其实就是和正向代理反过来，他和服务器是一伙的，它屏蔽掉了服务器的信息，经常用在多台服务器的分布式部署上，像一些大的网站，由于访问人数很多，就需要多台服务器来解决人数多的问题，这时这些服务器就由一个反向代理服务器来代理，客户端发来请求，先由反向代理服务器，然后按一定的规则分发到明确的服务器，而客户端不知道是哪台服务器。常常用nginx来作反向代理。

反向代理的过程隐藏了真实的服务器，客户不知道真正提供服务的是谁，客户端请求的服务都被代理服务器处理。反向代理代理的是响应方，也就是服务端

访问代理（不知道服务器）屏蔽服务端

最大的区别

正向代理中代理的对象是客户端。
反向代理中代理的对象是服务端。

1.2、负载均衡模式

以下是 Nginx 支持的几种常见的分流算法：

轮询（Round Robin）：

轮询算法是 Nginx 的默认分流算法。它按顺序将请求依次分配给每一台后端服务器，直到最后一台服务器，然后重新从第一台服务器开始。这种方法简单且均匀地分配了流量。

数据流向：每个请求依次被分配到下一个服务器。假设有三台服务器（Server A、Server B、Server C），第一个请求被分配到 Server A，第二个请求分配到 Server B，第三个请求分配到 Server C，第四个请求又回到 Server A，依此类推。

特点：请求均匀分布，无视服务器的当前负载和响应时间。

配置示例：

http下

   upstream backend {
       server backend1.example.com;
       server backend2.example.com;
       server backend3.example.com;
   }
#backend是自定义名称

最少连接数（Least Connections）：

最少连接数算法将请求分配给当前活动连接数最少的服务器。这种算法适用于请求处理时间不均匀的情况，可以有效平衡服务器的负载。

数据流向：每个请求被分配到当前连接数最少的服务器。例如，Server A 有 2 个连接，Server B 有 5 个连接，新的请求会被分配到 Server A。
特点：动态均衡负载，适用于请求处理时间不一的场景。

配置示例：

   upstream backend {
       least_conn;
       server backend1.example.com;
       server backend2.example.com;
       server backend3.example.com;
   }

IP 哈希（IP Hash）：

IP 哈希算法通过计算客户端 IP 地址的哈希值，将请求始终分配给同一台服务器。适用于需要将特定客户端的请求固定在同一台服务器上的场景。

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题，但是ip_hash会造成负载不均，有的服务请求接受多，有的服务请求接受少，所以不建议采用ip_hash模式，session 共享问题可用后端服务的 session 共享代替 nginx 的 ip_hash。

数据流向：每个客户端的 IP 地址被哈希计算，然后根据哈希值将请求固定分配到某一台服务器。假设客户端 X 的哈希值指向 Server A，客户端 Y 的哈希值指向 Server B，则无论多少次请求，X 的请求总是流向 Server A，Y 的请求总是流向 Server B。
特点：同一个客户端总是被分配到同一台服务器，有助于会话保持。

配置示例：

   upstream backend {
       ip_hash;
       server backend1.example.com;
       server backend2.example.com;
       server backend3.example.com;
   }

加权轮询（Weighted Round Robin）：

加权轮询算法允许为每台服务器设置权重，权重越大的服务器将会获得更多的请求。适用于服务器性能不均衡的情况。

数据流向：根据服务器设置的权重值分配请求。假设 Server A 权重为 3，Server B 权重为 1，则 4 个请求中，3 个会被分配到 Server A，1 个会被分配到 Server B。
特点：高权重服务器接收更多的请求，适用于服务器性能差异较大的场景。

配置示例：

   upstream backend {
       server backend1.example.com weight=3;
       server backend2.example.com weight=1;
       server backend3.example.com weight=2;
   }

最少时间算法（Least Time）：

最少时间算法基于请求的响应时间，将请求分配给响应时间最短的服务器。这种算法在 Nginx 1.15.3 及以后版本中可用，适用于需要最大化响应速度的场景。

数据流向：每个请求分配到响应时间最短或平均连接时间最短的服务器。假设 Server A 的响应时间较快，Server B 较慢，则新的请求更可能流向 Server A。
特点：进一步优化了最少连接算法，适用于高负载环境下的动态负载均衡。

配置示例：

   upstream backend {
       least_time header;
       server backend1.example.com;
       server backend2.example.com;
       server backend3.example.com;
   }

一致性哈希（Consistent Hashing）：

一致性哈希算法可以保证当集群中某台服务器故障时，只有部分请求会重新分配到其他服务器，而不是全部重新分配。这在缓存等场景中非常有用。

数据流向：根据请求的某个特定参数（如 URL、Cookie 或其他 Header），进行哈希计算，将请求分配到哈希值对应的服务器。假设 Server A 和 Server B，参数 "foo" 的哈希值指向 Server A，参数 "bar" 的哈希值指向 Server B，则 "foo" 请求总是流向 Server A，"bar" 请求总是流向 Server B。
特点：适应服务器节点变动，减少请求的重新分配，适合缓存敏感的场景。

配置示例（需要第三方模块如 `ngx_http_upstream_hash_module`）：

   upstream backend {
       hash $request_uri consistent;
       server backend1.example.com;
       server backend2.example.com;
       server backend3.example.com;
   }

一些其他的分流算法

rr 负载均衡模式：

每个请求按时间顺序逐一分配到不同的后端服务器，如果超过了最大失败次数后（max_fails，默认1），在失效时间内(fail_timeout，默认10秒)，该节点失效权重变为0，超过失效时间后，则恢复正常，或者全部节点都为down后，那么将所有节点都恢复为有效继续探测，一般来说rr可以根据权重来进行均匀分配。

权重

fair（第三方）负载均衡模式：

按后端服务器的响应时间来分配请求，响应时间短的优先分配，和最少时间差不多。

url_hash（第三方）负载均衡模式：

基于用户请求的uri做hash。和ip_hash算法类似，是对每个请求按url的hash结果分配，使每个URL定向到同一个后端服务器，但是也会造成分配不均的问题，这种模式后端服务器为缓存时比较好。

1.3、动静分离

为了加快网站的解析速度，可以把动态页面和静态页面由不同的服务器来解析，加快解析速度。降低原来单个服务器的压力。简单来说，就是使用正则表达式匹配过滤，然后交给不同的服务器。

1.4、部署负载均衡和反向代理和动静分离

Nginx 服务器：192.168.88.77:80
Tomcat服务器1：192.168.88.78:8080
Tomcat服务器2：192.168.88.79:8080

Tomcat服务器3：192.168.88.80:8080

使用的版本 nginx-1.18.0 tomcat-9.0.16

首先安装tomcat和nginx（在之前的已部署，可以使用前置资源的脚本或者看之前内容）

动静分离配置，正则表达式匹配过滤的

nginx实现负载均衡是通过反向代理实现的

对Tomcat server 配置，在78,79,80配置如下

1.创建一个index.jsp

mkdir /usr/local/tomcat/webapps/test
vim /usr/local/tomcat/webapps/test/index.jsp

内容如下

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>
<html>
<head>
<title>JSP test1 page</title>   
</head>
<body>
<% out.println("动态页面 1,http://www.test1.com");%>
</body>
</html>
//指定为 test1 页面   78,79,80请设置为不同的数字

2.vim /usr/local/tomcat/conf/server.xml

由于主机名 name 配置都为 localhost，需要删除前面的 HOST 配置

     <Host name="localhost"  appBase="webapps"
            unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
           <Context docBase="/usr/local/tomcat/webapps/test" path="" reloadable="true">
        </Context>
      </Host>

3、重启

/usr/local/tomcat/bin/shutdown.sh
/usr/local/tomcat/bin/startup.sh

补充

重复的操作可以scp远程文件拷贝，scp 是linux系统下基于ssh登陆进行安全的远程文件拷贝命令

scp【本地或远程文件的路径】【服务器用户名】@【服务器地址】：【远程或本地文件的路径】

例如：在78机器上可以把文件给79

scp 78的文件用户@远程地址:文件地址

scp /usr/local/tomcat/conf/server.xml root@192.168.88.79:/usr/local/tomcat/conf/server.xml

当然也可以反过来。

Nginx server 配置 77配置如下

mkdir /usr/local/nginx/html/img

在img里放张图片

在配置文件里

vim /usr/local/nginx/conf/nginx.conf

    upstream  tomcat_server {
      server 192.168.88.78:8080 weight=1;
      server 192.168.88.79:8080 weight=1;
    }

     location ~ .*\.jsp$ {
        proxy_pass http://tomcat_server;
        proxy_set_header HOST $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location ~ .*\.(git|jpg|png|css)$ {
        root  /usr/local/nginx/html/img;
        expires 10d;
        }

补充说明

proxy_set_header HOST $host;

设置后端的Web服务器可以获取远程客户端的真实IP
定后端的Web服务器接收到的请求访问的主机名（域名或IP、端口），默认HOST的值为proxy_pass指令设置的主机名。
如果反向代理服务器不重写该请求头的话，那么后端真实服务器在处理时会认为所有的请求都来在反向代理服务器，如果后端有防攻击策略的话，那么机器就被封掉了。

proxy_set_header X-Real-IP $remote_addr;

把$remote_addr赋值给X-Real-IP，来获取源IP

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

在nginx 作为代理服务器时，设置的IP列表，会把经过的机器ip，代理机器ip都记录下来

最后测试
测试静态页面效果
浏览器访问 http://192.168.88.77/
浏览器访问 http://192.168.88.77/game.jpg

测试负载均衡效果，不断刷新浏览器测试，动态
浏览器访问 http://192.168.88.77/index.jsp