Nginx实战-后端应用健康检查

原文链接：http://nolinux.blog.51cto.com/4824967/1594029?utm_source=tuicool&utm_medium=referral

最近由于服务经常崩掉，所以打算做一个负载均衡，使用nginx，前两篇总结了nginx的使用，这个主要总结下健康检查

1：windows下nginx使用健康检查

windows下的nginx没有linux下的nginx社区环境好，故这里主要使用的是nginx自带的健康检查

ngx_http_proxy_module 模块和ngx_http_upstream_module模块（自带）

配置如下：

#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;
proxy_next_upstream http_502 http_504 http_404 error timeout invalid_header;
proxy_connect_timeout 3s;
proxy_read_timeout 10s;
#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 estore_server {
server 127.0.0.1:8088 max_fails=1 fail_timeout=21600s;
server 127.0.0.1:8089 max_fails=1 fail_timeout=21600s;
server 127.0.0.1:8090 max_fails=1 fail_timeout=21600s;
server 127.0.0.1:8091 max_fails=1 fail_timeout=21600s;
}
server {
listen 8181;

location / {
proxy_pass http://estore_server;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}

# 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自带是没有针对负载均衡后端节点的健康检查的，但是可以通过默认自带的ngx_http_proxy_module 模块和ngx_http_upstream_module模块中的相关指令来完成当后端节点出现故障时，自动切换到健康节点来提供访问。

       这里列出这两个模块中相关的指令：

ngx_http_proxy_module 模块中的 proxy_connect_timeout 指令、proxy_read_timeout指令和proxy_next_upstream指令

1 2 3

语法: proxy_connect_timeout time; 默认值:proxy_connect_timeout 60s; 上下文:http, server, location

定义从后端服务器读取响应的超时。此超时是指相邻两次读操作之间的最长时间间隔，而不是整个响应传输完成的最长时间。如果后端服务器在超时时间段内没有传输任何数据，连接将被关闭。

1 2 3

语法: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 |http_404 | off ...; 默认值:    proxy_next_upstream error timeout; 上下文:    http, server, location

指定在何种情况下一个失败的请求应该被发送到下一台后端服务器：

1 2 3 4 5 6 7 8 9

error      # 和后端服务器建立连接时，或者向后端服务器发送请求时，或者从后端服务器接收响应头时，出现错误 timeout    # 和后端服务器建立连接时，或者向后端服务器发送请求时，或者从后端服务器接收响应头时，出现超时 invalid_header  # 后端服务器返回空响应或者非法响应头 http_500   # 后端服务器返回的响应状态码为500 http_502   # 后端服务器返回的响应状态码为502 http_503   # 后端服务器返回的响应状态码为503 http_504   # 后端服务器返回的响应状态码为504 http_404   # 后端服务器返回的响应状态码为404 off        # 停止将请求发送给下一台后端服务器

需要理解一点的是，只有在没有向客户端发送任何数据以前，将请求转给下一台后端服务器才是可行的。也就是说，如果在传输响应到客户端时出现错误或者超时，这类错误是不可能恢复的。

范例如下：

1 2 3

http { proxy_next_upstream http_502 http_504 http_404 error timeout invalid_header; }

ngx_http_upstream_module模块中的server指令

1 2 3

语法: server address [parameters]; 默认值:    — 上下文:    upstream

范例如下：

1 2 3 4

upstream name {                 server 10.1.1.110:8080 max_fails=1 fail_timeout=10s;                 server 10.1.1.122:8080 max_fails=1 fail_timeout=10s;         }

下面是每个指令的介绍：

1 2 3 4 5 6

max_fails=number      # 设定Nginx与服务器通信的尝试失败的次数。在fail_timeout参数定义的时间段内，如果失败的次数达到此值，Nginx就认为服务器不可用。在下一个fail_timeout时间段，服务器不会再被尝试。 失败的尝试次数默认是1。设为0就会停止统计尝试次数，认为服务器是一直可用的。 你可以通过指令proxy_next_upstream、fastcgi_next_upstream和 memcached_next_upstream来配置什么是失败的尝试。 默认配置时，http_404状态不被认为是失败的尝试。 fail_timeout=time       # 设定服务器被认为不可用的时间段以及统计失败尝试次数的时间段。在这段时间中，服务器失败次数达到指定的尝试次数，服务器就被认为不可用。默认情况下，该超时时间是10秒。        在实际应用当中，如果你后端应用是能够快速重启的应用，比如nginx的话，自带的模块是可以满足需求的。但是需要注意。如果后端有不健康节点，负载均衡器依然会先把该请求转发给该不健康节点，然后再转发给别的节点，这样就会浪费一次转发。        可是，如果当后端应用重启时，重启操作需要很久才能完成的时候就会有可能拖死整个负载均衡器。此时，由于无法准确判断节点健康状态，导致请求handle住，出现假死状态，最终整个负载均衡器上的所有节点都无法正常响应请求。由于公司的业务程序都是java开发的，因此后端主要是nginx集群和tomcat集群。由于tomcat重启应部署上面的业务不同，有些业务启动初始化时间过长，就会导致上述现象的发生，因此不是很建议使用该模式。        并且ngx_http_upstream_module模块中的server指令中的max_fails参数设置值，也会和ngx_http_proxy_module 模块中的的proxy_next_upstream指令设置起冲突。比如如果将max_fails设置为0，则代表不对后端服务器进行健康检查，这样还会使fail_timeout参数失效（即不起作用）。此时，其实我们可以通过调节ngx_http_proxy_module 模块中的 proxy_connect_timeout 指令、proxy_read_timeout指令，通过将他们的值调低来发现不健康节点，进而将请求往健康节点转移。        以上就是nginx自带的两个和后端健康检查相关的模块。

这就是windows下关于nginx自带的模块进行配置健康检查，其实在linux下也可以使用，其余的高级功能在这暂不介绍。