跨多个应用程序实例的负载平衡是一种常用技术,用于优化资源利用率、最大化吞吐量、减少延迟和确保容错配置。使用 nginx 作为非常有效的HTTP负载平衡器,将流量分配到多个应用程序服务器,可以提升Web应用程序的性能,提高扩展性和可靠性。
使用 upstream
定义一组服务 。
# 启动ruoyi-admin服务
[root@nginx-dev conf.d]# cd /home/apps
[root@nginx-dev apps]# java -jar ruoyi-admin.jar
# 启动tomcat服务
[root@nginx-dev ~]# /home/apache-tomcat-8.5.81/bin/startup.sh
# 在 /etc/nginx/conf.d文件夹下添加nginx配置文件:8003.conf
[root@nginx-dev ~]# cd /etc/nginx/conf.d
[root@nginx-dev conf.d]# vi 8003.conf
[root@nginx-dev conf.d]# nginx -s reload
8003.conf 配置文件内容:
upstream ruoyi-apps {
#不写,采用轮循机制
server localhost:8080;
server localhost:8088;
}
server {
listen 8003;
server_name ruoyi.loadbalance;
location / {
proxy_pass http://ruoyi-apps;
}
# 请求ie页面
location = /html/ie.html {
root /some/path/static;
}
# 请求字体文件
location ^~ /fonts/ {
root /some/path/static;
}
# css|js|png|jpg|gif|ico 页面
location ~ \.(css|js|png|jpg|gif|ico) {
root /some/path/static;
}
}
upstream ruoyi-apps {
#不写,采用轮循机制
server localhost:8080;
server localhost:8088;
}
轮询策略(Round Robin):默认的负载均衡策略,将请求依次分配给每个后端服务器,循环往复。
例如,当请求 nginx 的 8003 端口时,会将请求轮询转发给 tomcat 和 ruoyi-admin 两个后端服务器,即第1次请求会访问8080端口,第2次请求会访问8088端口,循环往复。
当访问 nginx 的 8003 端口时 ,请求会进入 8088 端口的 ruoyi-admin 服务,当填写完密码以后点击登录,这次请求会进入 8080 端口的 tomcat 服务,因此总是登录不成功。
最少连接策略(Least Connections):将请求分配给当前连接数最少的后端服务器,以达到负载均衡的目的。
upstream backend {
least_conn;
server backend1.example.com;
server backend2.example.com;
}
请注意,使用轮循机制或最少连接的负载平衡,每个客户端的请求都可能分发到不同的服务器。不能保证同一客户端将始终定向到同一服务器。
IP 哈希策略(IP Hash):根据客户端 IP 地址的哈希值来选择后端服务器,同一个客户端的请求总是被分配到同一个后端服务器上。
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
}
此方法可确保来自同一客户端的请求将始终定向到同一服务器,除非此服务器不可用。
通用hash,允许用户自定义hash的key,key可以是字符串、变量或组合。例如,key可以是配对的源 IP 地址和端口,也可以是 URI,如以下示例所示:
upstream backend {
hash $request_uri consistent;
server backend1.example.com;
server backend2.example.com;
}
请注意:基于 IP 的哈希算法存在一个问题,那就是当有一个上游服务器宕机或者扩容的时候,会引发大量的路由变更,进而引发连锁反应,导致大量缓存失效等问题。
假设我们基于 key 来做 hash,现在有 4 台上游服务器,如果 hash 算法对 key 取模,请求根据用户定义的哈希键值均匀分布在所有上游服务器之间。当有一台服务器宕机的时候,就需要重新对 key 进行 hash,最后会发现所有的对应关系全都失效了,从而会引发缓存大范围失效。
consistent
参数启用 ketama 一致哈希算法,如果在上游组中添加或删除服务器,只会重新映射部分键,从而最大限度地减少缓存失效。
加权轮询策略(Weighted Round Robin):根据后端服务器的权重来分配请求,权重越高的服务器被分配到的请求越多。
upstream my-server {
server performance.server weight=3;
server app1.server;
server app2.server;
}
如上所示,每 5 个新请求将按如下方式分布在应用程序实例中:3 个请求将定向到 performance.server,一个请求将转到 app1.server,另一个请求将转到 app2.server。