1.通过以下nginx配置提升应用的健壮性
1.1、超时及后端重试次数配置
proxy_next_upstream_tries 4; #结合proxy_next_upstream使用，用于后端重试次数。如果是tengine参数则是：proxy_upstream_tries
proxy_connect_timeout 10; #nginx到后端连接超时时间。
proxy_read_timeout 15; #nginx后端读取数据的超时时间。
proxy_send_timeout 60; #nginx发送数据到后端的超时时间
proxy_next_upstream http_500 http_502 http_504 error timeout invalid_header; #当请求后端出现500、502、504状态码时，继续发送请求到下一台后端服务器重试，需配置proxy_next_upstream_tries，否则当失败时会重试所有后端服务器。1.2、upstream的健康监测
upstream WEB_APP {
server 172.16.99.197:8080 max_fails=5 fail_timeout=5s; #表示在5秒[fail_timeout]内，失败了5次[max_fails],在这期间不会发送请求到此服务器。请根据实际情况合理配置该参数：避免出现"no live upstream"的告警,出现502请求。
server 172.16.99.198:8080 max_fails=5 fail_timeout=5s;
server 172.16.99.199:8080 max_fails=5 fail_timeout=5s;
#以下这部分配置是出自阿里云开源的tengine,能对后端进行主动监测并屏蔽掉故障的后端，避免请求发送到故障的机器，使用tengine或增加此模块才可配置这段。
check interval=3000 rise=2 fall=3 timeout=3000 type=http;
check_http_send "HEAD /s/monitor.js HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}
注：check各参数详细说明，可以参见阿里云开源的tengine地址：tengine
2.通过以下nginx配置降低出口带宽
开启压缩以后，大部份静态文件压缩后的大小大概原来的1/8左右。这对于请求量巨大的情况下能节省下不少出口带宽。
gzip on; #压缩开关、关闭：off
gzip_disable "msie6"; #排除不需要压缩的浏览器
gzip_min_length 1k; #当返回的content-length大于此值时开启压缩
gzip_buffers 4 16k; #压缩缓冲区设置
gzip_http_version 1.0; #开启压缩的HTTP协议版本
gzip_comp_level 9; #压缩的级别1-9，默认为1.
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; #支持压缩的mime类型
gzip_vary on; #在http响应头中返回Vary: Accept-Encoding标头
gzip_proxied any; #作为反向代理时针对上游的header头值进行压缩，此处的any表示都压缩