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表示都压缩