1：例如一个服务两个实例，前面 nginx 负载均衡。

nginx 可以做到实时的健康监测吗？一旦一个服务 kill 不往这个服务上转发请求，不过这样好像还是有一个问题，我要升级必然要 kill 掉一个服务，kill 瞬间如果还有请求在这个实例里，那么这个请求就无法返回数据，这样用户感知到异常了。 所以最好的方式是要重启一个服务前，告诉负载均衡器不要转发请求到我这里，然后等一段时间等这个机器上所有请求都处理完，这个时候老的请求完毕，新的请求不过来，就可以更新重启。

nginx 下有这样的功能吗？ haproxy 下倒是有 agent check 可以实现这个功能。
 

解决方案：

nginx -s reload|reopen|stop|quit  #重新加载配置|重启|停止|退出 nginx

nginx -s reload 
nginx配置平滑更新
为了让主进程重新读取配置文件，应该向主进程发送一个HUP信号，主进程一旦接收到重新加载配置的的信号，它就检查配置文件语法的有效性，然后试图应用新的配置，即打开新的日志文件和新的socket 监听，如果失败，它将回滚配置更改并继续使用旧的配置，如果成功了，它开启新的工作进程，并给旧的工作进程发消息让它们优雅的关闭，旧的工作进程接收到关闭信号后，不再接收新的请求，如果已有请求正在处理，等当前请求处理完毕后关闭，如果没有请求正在处理，则直接关闭。

upstream names{
     server www.abc.com:8080 ;
     server 127.0.0.1:8080 ;
 }    map $http_upgrade $connection_upgrade {  #websocket
                 default upgrade;
                 ''      close;
         }server {
     listen       443 ssl;
     server_name  www.xyz.cn;    ssl_certificate "/usr/src/www.xyz.cn/Nginx/1_www.xyz.cn_bundle.crt";
     ssl_certificate_key "/usr/src/www.xyz.cn/Nginx/2_www.xyz.cn.key";
     ssl_session_timeout 5m;
         ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #按照这个协议配置
         ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;#按照这个套件配置
         ssl_prefer_server_ciphers on;         location ~* '/websocket/' {
             proxy_pass http://local;
             proxy_http_version 1.1;
             proxy_set_header Host $host;
             proxy_set_header X-Real-IP $remote_addr;
             proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
             proxy_read_timeout 120s;            proxy_set_header Upgrade websocket;
             proxy_set_header Connection Upgrade;
         }        location / {
                 proxy_pass http://names; #转发到本机项目端口
         }
  
 }

2：如果你的nginx服务器给2台web服务器做代理，负载均衡算法采用轮询，那么当你的一台机器web程序iis关闭，也就是说web不能访问，那么nginx服务器分发请求还是会给这台不能访问的web服务器，如果这里的响应连接时间过长，就会导致客户端的页面一直在等待响应，对用户来说体验就打打折扣，这里我们怎么避免这样的情况发生呢。这里我配张图来说明下问题。

微服务降级方案 微服务平滑升级_nginx

如果负载均衡中其中web2发生这样的情况，nginx首先会去web1请求，但是nginx在配置不当的情况下会继续分发请求道web2，然后等待web2响应，直到我们的响应时间超时，才会把请求重新分发给web1，这里的响应时间如果过长，用户等待的时间就会越长。

下面的配置是解决方案之一。

proxy_connect_timeout 1;   #nginx服务器与被代理的服务器建立连接的超时时间，默认60秒
proxy_read_timeout 1; #nginx服务器想被代理服务器组发出read请求后，等待响应的超时间，默认为60秒。
proxy_send_timeout 1; #nginx服务器想被代理服务器组发出write请求后，等待响应的超时间，默认为60秒。
proxy_ignore_client_abort on;  #客户端断网时，nginx服务器是否终端对被代理服务器的请求。默认为off。

3：如果使用upstream指令配置啦一组服务器作为被代理服务器，服务器中的访问算法遵循配置的负载均衡规则，同时可以使用该指令配置在发生哪些异常情况时，将请求顺次交由下一组服务器处理。

proxy_next_upstream timeout;  #反向代理upstream中设置的服务器组，出现故障时，被代理服务器返回的状态值。

状态值可以是：error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off

  • error：建立连接或向被代理的服务器发送请求或读取响应信息时服务器发生错误。
  • timeout：建立连接，想被代理服务器发送请求或读取响应信息时服务器发生超时。
  • invalid_header:被代理服务器返回的响应头异常。
  • off:无法将请求分发给被代理的服务器。
  • http_400，....:被代理服务器返回的状态码为400，500，502，等。