引言
别问,问就是工作需要。让我把写的一个服务用Nginx负载均衡一下。
正好记录一下。
1. 准备
- 确保你的Nginx已经安装完毕,且可以正常使用。如果还没安装,请看这个链接:https://blog.csdn.net/weixin_52799373/article/details/126029809?spm=1001.2014.3001.5502
- 准备一个测试服务,改改端口,打三个jar包出来方便测试
- 启动三个服务 试一下看能否访问正常,可以的话继续下一步,不可以的话检测你的jar
2. 修改配置文件
我的配置文件所在地为:
/usr/local/nginx/conf/nginx.conf
vim /usr/local/nginx/conf/nginx.conf
- 配置upstream,在http{}里 新增 upstream 指向你启动的那三个后端服务。webservers 可以起一个自己容易辨识的名字,这里仅作演示。
upstream webservers{
server 192.168.169.130:8081;
server 192.168.169.130:8082;
server 192.168.169.130:8083;}
2. 在 server{} 里添加一个location,并且配置 proxy_pass,(注意不要有同名的 比如已经有一个 location / 了,你再添加重启Nginx就会报错)
location / {#转发到负载服务上
proxy_pass http://webservers;}
默认 location / 可以注释掉,也可以在上面修改,我是直接注销掉的。
这里的 webservers 要和你配置 upstream 时起的名字一样。
3. 完整配置文件如下
#user nobody;
worker_processes 1;#error_log logs/error.log;#error_log logs/error.log notice;#error_log logs/error.log info;
pid /usr/local/nginx/logs/nginx.pid;
events {
worker_connections 1024;}
http {
include mime.types;
default_type application/octet-stream;#log_format main '$remote_addr - $remote_user [$time_local] "$request" '# '$status $body_bytes_sent "$http_referer" '# '"$http_user_agent" "$http_x_forwarded_for"';#access_log logs/access.log main;
sendfile on;#tcp_nopush on;#keepalive_timeout 0;
keepalive_timeout 65;#gzip on;
upstream webservers{
server 192.168.169.130:8081;
server 192.168.169.130:8082;
server 192.168.169.130:8083;}
server {
listen 9600;
server_name localhost;#charset koi8-r;#access_log logs/host.access.log main;# location / {#root html;#index index.html index.htm;#}
location / {#转发到负载服务上
proxy_pass http://webservers;}# location /test/api2 {# #转发到负载服务上# proxy_pass http://webservers;# }#error_page 404 /404.html;# redirect server error pages to the static page /50x.html#
error_page 500502503504 /50x.html;
location = /50x.html {
root html;}# proxy the PHP scripts to Apache listening on 127.0.0.1:80##location ~ \.php$ {# proxy_pass http://127.0.0.1;#}# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000##location ~ \.php$ {# root html;# fastcgi_pass 127.0.0.1:9000;# fastcgi_index index.php;# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;# include fastcgi_params;#}# deny access to .htaccess files, if Apache's document root# concurs with nginx's one##location ~ /\.ht {# deny all;#}}# another virtual host using mix of IP-, name-, and port-based configuration##server {# listen 8000;# listen somename:8080;# server_name somename alias another.alias;# location / {# root html;# index index.html index.htm;# }#}# HTTPS server##server {# listen 443 ssl;# server_name localhost;# ssl_certificate cert.pem;# ssl_certificate_key cert.key;# ssl_session_cache shared:SSL:1m;# ssl_session_timeout 5m;# ssl_ciphers HIGH:!aNULL:!MD5;# ssl_prefer_server_ciphers on;# location / {# root html;# index index.html index.htm;# }#}}
- 修改完成后重启Nginx或重新加载配置
# 重新加载(要到Nginx安装目录执行)
./nginx -s reload
# 重新启动服务 (如果你添加了服务)
systemctl restart nginx.service
- 浏览器访问:localhost:9600(我监听的9600,如果你没修改应该是默认80,在listen处修改),多访问几次,你会发现是轮训的(你的三个服务返回的结果记得有点区别)
3. 负载均衡配置说明(借鉴)
默认情况下,直接按照上面的配置后,如果后端有多个服务,采用的是轮询策略;
常用的可选配置包括:
weight 多台机器,可以配置权重值,权重高的服务将会优先被访问
down 某个服务配置down之后,这台服务将不会被访问
backup 配置了这个参数后,除非其他的服务都挂掉了,否则这台服务将不会被访问到
以weight 为例做简单的说明,在上面的配置中,补充weight参数
upstream webservers{
server 192.168.9.134:8081 weight=8;
server 192.168.9.134:8082 weight=2;}
重新加载配置,按照上面的测试步骤再次刷新页面,这时候可以发现,8081对于的这个服务将会被更多的访问到;
其他负载均衡配置策略
默认情况下,nginx采用的是轮询策略,nginx还提供了其他几种常用的负载均衡配置
1、ip_hash
每个请求按访问IP的hash结果进行分配,这样每个访客就可以固定访问一个后端服务,一定程度上可以解决session问题;
upstream webservers {<!--{cke_protected}{C}%3C!%2D%2D%20%2D%2D%3E--> ip_hash; server 192.168.169.130:8081; server 192.168.169.130:8082; server 192.168.169.130:8083;}
2、weight
weight代表权重,默认为1,权重越高,被分配的客户端请求就会越多
upstream webservers{
server 192.168.9.134:8081 weight=8;
server 192.168.9.134:8082 weight=2;}
3、fair(第三方)
按后端服务器的响应时间来分配请求,响应时间短的将会被优先分配
upstream webservers{
server 192.168.9.134:8081;
server 192.168.9.134:8082;
fair;}
4、url_hash
按访问URL的hash结果分配。这样相同的url会被分配到同一个节点,主要为了提高缓存命中率。比如,为了提高访问性能,服务端有大量数据或者资源文件需要被缓存。使用这种策略,可以节省缓存空间,提高缓存命中率
upstream webservers{hash&request_uri;
server 192.168.9.134:8081;
server 192.168.9.134:8082;}
5、least_conn
按节点连接数分配,把请求优先分配给连接数少的节点。该策略主要为了解决,各个节点请求处理时间长短不一造成某些节点超负荷的情况。
upstream webservers{
least_conn;
server 192.168.9.134:8081;
server 192.168.9.134:8082;}
以上不同的负载均衡策略均有各自不同的使用场景,请结合自身的实际情况进行合理的选择,同时,各自配置策略在实际使用的时候也不是孤立的,比如最小连接数可以搭配权重数一起使用。
版权归原作者 七维大脑 所有, 如有侵权,请联系我们删除。