springcloud熔断器Hystrix

为什么有Hystrix

在微服务架构中，业务别拆分成很多个服务，服务之间可以相互调用，服务并不能保证100%可用，如果一个服务出现问题，调用这个服务就会出现问题，如果此时大量的请求进来，就会形成任务累积，造成服务瘫痪。进一步导致依赖于这个服务的其他服务也会出现线程等待，最后资源耗尽服务不可用，最终导致整个系统不可用，这就是服务雪崩效应。

服务雪崩的原因

可能是某些机器突然发生故障。也可能是负载突然大量增加，超出了服务的处理能力

解决服务雪崩的方案

一般对服务的保护有三种方案：

1. 熔断模式：主要参考了电路中的保险丝概念，如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。
2. 隔离模式：把不同的请求隔离开，每种类型的请求相互不影响，如果一种类型的请求线程资源耗尽，则对后续的该类型请求直接返回，不再调用后续资源。这种模式使用场景非常多，例如将一个服务拆开，对于重要的服务使用单独服务器来部署

资源隔离策略

有两种隔离策略：线程池隔离和信号量隔离

• 信号量隔离：信号量的资源隔离只能起到一个开关的作用。比如服务A的信号量大小是10，那么就只允许10个线程同时访问服务A，其他的请求会被拒绝，起到限流保护的作用。
• 线程池隔离：当用户请求服务A和服务B的时候，tomcat的线程会将请求的任务交给服务A和服务B的内部线程池里面的线程来执行，tomcat的线程就可以去干别的事情去了，当服务A和服务I自己线程池里面的线程执行完任务之后，就会将调用的结果返回给tomcat的线程，从而实现资源的隔离，当有大量并发的时候，服务内部的线程池的数量就决定了整个服务的并发度，例如服务A的线程池大小为10个，当同时有12请求时，只会允许10个任务在执行，其他的任务被放在线程池队列中，或者是直接走降级服务，此时，如果服务A挂了，就不会造成大量的tomcat线程被服务A拖死，服务B依然能够提供服务。整个系统不会受太大的影响。

两种资源隔离策略适合场景

1. 当请求的服务网络开销比较大的时候，或者是请求比较耗时的时候，我们最好是使用线程隔离策略，这样的话，可以保证大量的tomcat线程可用，不会由于服务原因，一直处于阻塞或等待状态，可以直接快速失败。
2. 而当我们请求缓存这些服务的时候，我们可以使用信号量隔离策略，因为这类服务的返回通常会非常的快，不会占用容器线程太长时间，而且也减少了线程切换的一些开销，提高了缓存服务的效率。

Hystrix的工作原理

1. 断路器机制：设计三种状态OPEN，HALF-OPEN，CLOSED
   当Hystrix Command请求后端服务失败数量超过一定比例（默认是50%），断路器会打开，处于OPEN状态。这是所有调用这个服务的请求都会直接失败，不再去执行正常的处理逻辑。断路器开启一定的时间（默认是5秒），会自动切换到HALF-OPEN状态，阐释把一部分请求出执行正常的处理逻辑。如果失败，切换到OPEN，如果请求成功，说明服务恢复正常了，把断路器关掉，切换到CLOSED状态。
2. fallback： 当断路器打开的时候，不再执行正常的y业务逻辑，而是执行的就是fallback逻辑
3. 资源隔离：在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池. 例如调用产品服务的Command放入A线程池, 调用账户服务的Command放入B线程池. 这样做的主要优点是运行环境被隔离开了. 这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽时, 不会对系统的其他服务造成影响.