高并发 服务雪崩、Hystrix熔断、Hystrix降级

前言

听起来这几个词挺高大上的，以前都是盲区，现在我们好好梳理下这几个概念，熔断和降级是在一起使用的。先看个图

订单服务和会员服务不在一个服务器，订单服务会调用会员服务，当会员服务返回阻滞时，订单服务的线程会阻滞，如果请求过多，服务器的线程都被占用了，这是我们调用 查询订单服务就会没有线程用来处理，该服务器所有的服务都将不可用，这就是服务雪崩。

• 服务熔断
  为了解决上述问题，服务熔断的思想被提出来。类似现实世界中的“保险丝“，当某个异常条件被触发，直接熔断整个服务，而不是一直等到此服务超时。
  熔断的触发条件可以依据不同的场景有所不同，比如统计一个时间窗口内失败的调用次数。
• 服务降级
  有了熔断，就得有降级。所谓降级，就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。

1 熔断、降级原理

为了解决 上述问题，我们可以把 单个服务进行隔离，使其不能影响整个服务器的使用，常见的就是 线程隔离和信号量隔离。

1. 1 Hystrix实现服务隔离两种方案

Hystrix的资源隔离策略有两种，分别为：线程池和信号量

1.1.1 线程池方式

1、 使用线程池隔离可以完全隔离第三方应用，请求线程可以快速放回。
2、 请求线程可以继续接受新的请求，如果出现问题线程池隔离是独立的不会影响其他应用。
3、 当失败的应用再次变得可用时，线程池将清理并可立即恢复，而不需要一个长时间的恢复。
4、 独立的线程池提高了并发性

• 缺点：
  线程池隔离的主要缺点是它们增加计算开销（CPU）。每个命令的执行涉及到排队、调度和上 下文切换都是在一个单独的线程上运行的。

1.1.2 信号量

使用一个原子计数器（或信号量）来记录当前有多少个线程在运行，当请求进来时先判断计数 器的数值，若超过设置的最大线程个数则拒绝该请求，若不超过则通行，这时候计数器+1，请求返 回成功后计数器-1。
与线程池隔离最大不同在于执行依赖代码的线程依然是请求线程
tips：信号量的大小可以动态调整, 线程池大小不可以

1.2 比较

线程池隔离：
1、 第三方应用或者接口
2、 并发量大

信号量隔离：
1、 内部应用或者中间件（redis）
2、 并发需求不大

2 java 代码实现

先增加maven 依赖

<!-- hystrix 服务熔断，降级用-->
		<dependency>
			<groupId>org.apache.httpcomponents</groupId>
			<artifactId>httpclient</artifactId>
		</dependency>
		<!-- https://mvnrepository.com/artifact/com.alibaba/fastjson -->
		<dependency>
			<groupId>com.alibaba</groupId>
			<artifactId>fastjson</artifactId>
			<version>1.2.47</version>
		</dependency>
		<dependency>
			<groupId>com.netflix.hystrix</groupId>
			<artifactId>hystrix-metrics-event-stream</artifactId>
			<version>1.5.12</version>
		</dependency>
		<dependency>
			<groupId>com.netflix.hystrix</groupId>
			<artifactId>hystrix-javanica</artifactId>
			<version>1.5.12</version>
		</dependency>

会员服务代码

@RestController
@RequestMapping("/member")
public class MemberController {
   
    @RequestMapping("/memberIndex")
    public Ob