hystrix 之服务雪崩

服务雪崩：在微服务调用的过程中由于各服务之间的强依赖关系，如果某些服务发成故障，可能会导致所有服务的所有资源不可用的现象

主要原因：

　　服务提供者不可用（硬件故障，程序 BUG，缓存击穿，用户大量请求等）

　　重试加大流量（用户重试，代码逻辑重试）

　　服务消费者不可用（同步等待造成的资源耗尽

即一个服务不可用，导致一系列服务的不可用。

解决方案：

　　请求缓存：支持将一个请求与返回结果做缓存处理；

　　请求合并：将相同的请求进行合并然后调用批处理接口；

　　服务隔离：限制调用分布式服务的资源，某一个调用的服务出现问题不会影响其他服务调用；

　　服务熔断：牺牲局部服务，保全整体系统稳定性的措施；

　　服务降级：服务熔断以后，客户端调用自己本地方法返回缺省值。

 

请求缓存：

　　Hystrix 为了降低访问服务的频率，支持将一个请求与返回结果做缓存处理，但Hystrix 自带缓存有两个缺点：

　　　　本地缓存，集群情况下缓存无法同步。

　　　　不支持第三方缓存容器，如：Redis，MemCache。

　　因此：可使用 Spring 的缓存集成方案

请求合并：

　　在高并发情况下，减少微服务之间通信次数，将各请求合并处理

　　优点：减少了微服务之间的通信

　　缺点：增加了单个请求的延迟，请求量不高，请求耗时延迟低不适用

服务隔离：

　　线程池隔离：通常情况下一个微服务的所有接口都是在一个线程池中运行，如果由于某个接口访问压力过大，导致其他接口无法访问

　　　　对访问压力过大的接口单独设立线程，而不影响其他线程

　　　　优点：

　　　　　　使用线程池隔离可以安全隔离依赖的服务，减少所依赖服务发生故障时的影响面。

　　　　　　独立的线程池提高了并发性。

　　　　　　当失败的服务再次变得可用时，线程池将清理并立即恢复，而不需要一个长时间的恢复。

　　　　确定：

　　　　　　请求在线程池中执行，肯定会带来任务调度、排队和上下文切换带来的 CPU 开销。

　　　　　　因为涉及到跨线程，那么就存在 ThreadLocal 数据的传递问题，比如在主线程初始化的 ThreadLocal 变量

 

　　信号量隔离：

　　　　每次调用线程，当前请求通过计数信号量进行限制，当信号量大于了最大请求数 maxConcurrentRequests 时，进行限制，调用 fallback 接　　　　　　　　口快速返回。信号量的调用是同步的，也就是说，每次调用都得阻塞调用方的线 程，直到结果返回。这样就导致了无法对访问做超时（只能依靠调　　用协议超时，无法主动释放）

服务熔断：

　　启动条件：

　　　　单位时间内请求超标

　　　　单位时间内请求失败太多

　　重试：熔断启动状态下，单位时间内重试，成功则关闭熔断，失败则fallback

 

服务降级：当服务不可用时，默认的处理方法

　　触发条件：

　　　　方法抛出非 HystrixBadRequestException 异常

　　　　方法调用超时

　　　　熔断器开启拦截调用

　　　　线程池/队列/信号量跑满