Spring Cloud GZIP压缩以及灾难性雪崩解决方案：服务降级、请求缓存、请求合并

转载自：https://zhuanlan.zhihu.com/p/95961946

为什么http连接池能提升性能？

两台服务器建立HTTP连接的过程是很复杂的个过程，涉及到多个数据包的交换，并且也很耗时间。Http连接需要的3次握手4次分手开销很大，这一开销对应大量的比较小的HTTP消耗来说更大。

如果我们直接采用HTTP连接池，节约了大量的3次握手4次分手，这样能大大提升吞吐率。
Feign的HTTP客户端支持3种框架：HttpURLConnection，HTTP Client，okhttp，默认是HttpURLConnection。

传统的HttpURLConnection是JDK自带的，并不支持连接池，如果要实现连接池的机制，还需要自己管理连接对象。对于网络请求这种底层相对复杂的操作，如果有可用的其他方案，也没有必要自己去管理连接对象；
HttpClient相比传统的JDK自带的HttpURLConnection，它封装了访问HTTP的请求头，参数，内容体，响应等等，它不仅使客户端发送Http请求变的容易，而且也方便了开发人员测试接口（基于HTTP协议的），即提高了开发效率，也方便提高代码的健壮性，另外高并发发短的请求网络的时候，还是使用连接池提升吞吐量。

什么是服务灾难性雪崩效应

在微服务架构中，一个请求需要调用多个服务是非常常见的。如客户端访问A服务，而A服务需要调用B服务，B服务需要调用C服务，由于网络原因或者自身的原因，如果B服务或者C服务不能及时响应，A服务将处于阻塞状态，直到B服务C服务响应。此时若有大量的请求涌入，容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，造成连锁反应，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

造成雪崩原因是什么？

服务提供者不可用（硬件故障，程序bug，缓存击穿，用户大量请求）
重试加大流量（用户重试，代码逻辑重试）
服务调用者不可用（同步等待造成的资源耗尽）

解决灾难性雪崩效应有哪些方式？

降级
隔离（线程池隔离和信号量隔离）
熔断
缓存
请求合并

1.1. 降级：超时降级，资源不足时（线程或信号量）降级，降级后可以配合降级接口返回托底数据。实现一个fallback方法，当请求后端服务出现异常时，可以使用fallback方法返回的值。
1.2. 隔离：隔离有线程池隔离和信号量隔离两种方式，限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用
1.3. 熔断：当失败率（如因网络故障/超时造成的失败率高）达到阈值自动触发降级，熔断器触发的快速失败会进行快速恢复
1.4. 缓存：提供了请求缓存
1.5. 请求合并：提供请求合并

什么是请求合并？
答：在微服务结构中，很多情况下会有多个请求同时发起，如果同一时间请求过多，服务器承受不了多个请求同时到达的压力，就会容易造成服务器崩塌，这时可以将多个请求合并成一个请求，然后在向服务器发起请求。
什么情况下使用请求合并？
答：在微服务架构中，我们将一个项目拆分成很多个独立的模块,这些独立的模块通过远程调用来互相配合，但是，在高并发情况下，通信次数的增加会导致总的通信时间增加，同时，线程池是资源也是有限的，高并发环境会导致有大量的线程处于等待状态，进而导致线程延迟，为了解决这些问题，需要使用Hystrix的请求合并。
请求合并有哪些缺点？
答：设置请求合并后，本来一个请求可能5ms就搞定了，但是现在必须再等10ms看看还有没有其他的请求一起，这样一个请求的耗时就从5ms增加到15ms，不过，如果我们发起的命令本身就是一个高延迟的命令，那么这个时候就可以使用请求合并了，因为这个时候时间窗的时间消耗就显得微不足道了，另外高并发也是请求合并的一个非常重要的场景。