1、现象：

    1）通过NGINX访问ppm服务开始超时。

    2）不久大量服务开始报no live upstream，造成部分服务不可用，导致了业务影响。

2、解决过程：

    1) 查看路由控制台管理界面，发现NGINX中有ppm的服务被超时下架。

    2）重启超时被下架的ppm服务，重启nginx解决。

3、根源分析：

生产环境中，应用启动后，需要动态注册到路由nginx中。请求到达接入层nginx后，通过负载把请求发给路由层nginx，再根据路由规则，分发到docker资源池的不同服务实例。

1) 在本次故障中，因为路由层nginx调用后端ppm多次服务超时，因此路由把ppm的服务下架。

2) 下架后接入层nginx把访问ppm的请求转发给路由层nginx，导致请求失败。

3) 多次失败后接入层nginx把路由层nginx下架。

4) 在路由层所有nginx都下架后，访问其他服务也就没有可以访问的live upstream，从而导致了到其他服务实例访问都失败。

接入层nginx 访问后端的upstream通过两个参数来进行控制：max_fails, fail_timeout, 比如：max_fails=10, fail_timeout=5s，则认为5秒超时为1个失败，10次失败后则不再访问后端的该upstream。

因此为避免某个服务超时导致路由nginx被下架，需要对接入层nginx的这两个参数进行调整：

1) fail_timeout需要设置为 > 服务端应用的最大执行时间。

     2) 增大max_fails, 并对no live upstream进行监控告警。