如果要支持健康检查需要开启health_check(好吧,这个是nginx plus版本才有的功能,plus是付费版)
还有一点,Windows的nginx不支持udp等协议,所以有一些测试还必须用linux环境测试;
对于Tcp的负载均衡简易配置:
tcp { # 如果自己写的话最好不用这个,还是用stream好,它可以同时代表tcp和udp upstream xxx-service { # 注意,无论是tcp/udp/http什么的,这里都是upstream clusterName server localhost:9000; server localhost:9001; #check interval 健康:检查时间间隔,单位为毫秒 #rise 检查几次正常后,将server加入以负载列表中 #fall 检查几次失败后,从负载队列移除server #timeout 检查超时时间,单位为毫秒 check interval=3000 rise=2 fall=5 timeout=1000; } server { # 对于TCP/UDP这样的协议不存在location的说法 listen 8786; proxy_pass xxx-service; } }
HTTP协议的:(和tcp或udp的不同的是,tcp里面一个upstream对于一个server[listen]配置,而http里是多个upstream可以对应一个server[listen]配置,也可以对应多个server配置,
而不同的server的listen端口是可以一样的【这种情况其实就可以用一个server,当然也可以用两个】)
http { include conf/mime.types; default_type application/octet-stream; keepalive_timeout 120; tcp_nodelay on; upstream www.s135.com { # 这里可以用标识符而非域名,比如upstream uuu {...};而所有的web访问到nginx网关的时候都是指定了对应的server server 192.168.1.2:80; server 192.168.1.3:80; server 192.168.1.4:80; server 192.168.1.5:80; } upstream blog.s135.com { server 192.168.1.7:8080; server 192.168.1.7:8081; server 192.168.1.7:8082; } server { listen 80;
# 这个server_name一般要么是nginx所在主机的ip地址,要么就是这台主机绑定的域名(一台主机可以绑定多个域名,这个时候就会用到多个server,但是没有绑定多个域名也是可以配置多个server的【最好不要会产生warn】) server_name www.s135.com; # 下面的http://www.s135.com对应的是upstream里的名字,和server_name是没有关系的,但是如果一个请求是通过www.s135.com请求过来,那么header里Host值就会是www.s135.com这样就能被nginx识别并由这个server去处理,所以这个东西在多域名访问时还是有用的,但是如果是nginx集群只处理一个域名 或者 不以域名为转发标识只与url有关 或者 是内部系统的网关直接用的ip那么多个upstream用一个server即可,这里域名处理的作用是为了假设两个server监听的同一个地址,然后两个server里的location存在一样的配置,那么请求过来匹配上该一样的location,如果没有域名处理那么这里就无法知道到底转发给哪个server的该location【当然是先匹配server然后才是location】) location / { proxy_pass http://www.s135.com; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } log_format www_s135_com '$remote_addr - $remote_user [$time_local] $request ' '"$status" $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /data1/logs/www.log www_s135_com; } server { listen 80; server_name blog.s135.com; location / { proxy_pass http://blog.s135.com; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } log_format blog_s135_com '$remote_addr - $remote_user [$time_local] $request ' '"$status" $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /data1/logs/blog.log blog_s135_com; } }
官方的HTTP协议配置里不需要listen,默认就是80端口,如果是https则要listen后面有个ssl后缀:
http { upstream backend { server backend1.example.com; server backend2.example.com; server 192.0.0.1 backup; } server { location / { proxy_pass http://backend; } } }
自己测试通过的Http协议负载均衡配置:#user nobody;
worker_processes 1; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid 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; tcp_nodelay on; #gzip on; # 【重要,这里的cluster_name必须是一个可访问的ip或者是域名,它不是key的意思(是key,之前用cluster_servers这个key有下划线所以失败); # 但经过测试用cluster_servers提示400,用mmm则可以,难道是下划线的原因?(对,确实是下划线的原因,真坑啊,一般不都应该支持下划线吗?反倒是-支持,不过最好也不要有指不定什么时候不支持了) upstream clusterservers { server 127.0.0.1:8891 down; # max_fails=3 fail_timeout=60s weight=1 server 127.0.0.1:8892 weight=1; # 注意,weight的值不能是0(可能低版本可以),如果要软卸载单个server可以配置为down然后reload; # server localhost:8080 backup; # 注意,backup也是会转发的,由于之前转发到上面两个主机一直失败,所以就转发到backup机里了; } server { listen 80; # 如果是80是可以省略的
# 其实对于HTTP协议而言,location才是相当于tcp/udp这种协议的server,而且一个upstream可以对于多个location; server_name uuuu; # 这个配置可以不用,注意它描述的是nginx开启的server的server_name【错,它对应的其实是requestHeader中的Host的值,即域名,当两个server都绑定的同一个地址时,请求过来到底转发到哪个server里的location就可以进一步通过这个来判断】,即listen 80中的这个server,而不是upstream里的被代理服务的server_name charset utf-8; access_log logs/cluster_servers.access.log main; location / { proxy_pass http://clusterservers; # health_check; # 开启健康检查 } # redirect server error pages to the static page /50x.html error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } }
UDP协议的:
stream { # UDP的居然是叫stream(好吧,貌似TCP也能是这个,只不过后面的server的listene不需要udp后缀) # 可以有多个upstream upstream dns { server 101.89.134.11:8989; server 101.89.134.12:8989; server 101.89.134.13:8989; } # 可以有多个server对应上面的upstream server { listen 8989 udp; # 注意这里有udp proxy_responses 1; proxy_timeout 20s; proxy_bind $server_addr:$remote_port; proxy_pass dns; } }
官方文档里的TCP和UDP共同的例子(注意,虽然是官方的例子,但是还是不要用下划线比较好,自己测试的时候下划线死活无法转发):
stream { upstream stream_backend { least_conn; server backend1.example.com:12345 weight=5; server backend2.example.com:12345 max_fails=2 fail_timeout=30s; server backend3.example.com:12345 max_conns=3; } upstream dns_servers { least_conn; server 192.168.136.130:53; server 192.168.136.131:53; server 192.168.136.132:53; } server { # TCP的集群服务 listen 12345; proxy_pass stream_backend; proxy_timeout 3s; proxy_connect_timeout 1s; } server { # UDP的集群服务 listen 53 udp; proxy_pass dns_servers; } server { # 这个就是没有配置集群,普通的转发; listen 12346; # 注意,这里的server和下面的proxy_pass你可以理解为docker容器和内部应用的关系 proxy_pass backend4.example.com:12346; } }