Spring Cloud 因为请求上游接口，没设置超时时间导致的服务雪崩

【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战
我觉得这个其中的超时场景跟我差不多

微服务架构中的上下游

在由微服务（或者只是老式分布式服务）组成的系统中，也有关于上游和下游服务的讨论。

依赖规则和价值规则也适用于这种情况

服务 B 是上游服务，因为服务 A 依赖于它。服务 A 是下游服务，因为它增加了服务 B 的价值。

请注意，在这种情况下上游和下游的定义中的“流”不是通过服务 A 进入系统的数据流，而是数据流系统一直到面向用户的服务。

服务离用户（或任何其他最终消费者）越近，它离下游越远。

背景

在几个月前开发的XX费余额查询接口，调用了某个人提供的接口，运行了几个月一直没问题，但是最近晚上突然，我们的公众号小程序，进入首页，变得很慢，经过排查发现，竟然是这个 个人查询接口 突然更新服务，导致查询变得很慢，加上请求时没加超时时间，一直等待个人接口返回数据，导致连接数过多，线程池的线程被耗尽，当其他请求进来，有服务调用其他下游服务的时候，这时候就卡住了，我这里就是用户支付成功，进行话费充值，充值完成，要做用户的订单累计，优惠券状态，分销商户佣金变更等等操作，这些都是要调用其他下游服务，因为线程没了，导致调用其他下游服务可能超时了或者阻塞了，然后就openfegin触发超时异常，因为没加熔断器啥的，直接不往下执行，导致业务异常了，这时候就是雪崩就产生了，整条服务链路都挂了。

解决方案

就是在原来的请求外部接口时，一定要加超时时间，不然请求量大了就会崩，然后可以的话一定要上熔断器Sentinel啥的，进行服务降级或熔断。

熔断方法： 直接请求本地的快速失败方法
降级方法：
1.拒绝服务
判断应用来源，高峰时段拒绝低优先级应用的服务请求，保证核心应用正常工作。也可以随机拒绝请求，直接返回服务器繁忙，避免同时涌入过多的请求，这在电商秒杀时用的特别多。
2.关闭服务
既然是高峰期，那么可以关闭一些冷门的或者边缘不重要的服务，给核心服务让出资源。如淘宝每年双11时候都会关闭如评价、确定收货等一些与下单核心业务无关的服务，以保证用户下单支付正常，当然肯定也会使用拒绝服务，0点高峰期很多用户看到的基本是服务器繁忙。

知识点：
什么是服务熔断？