SpringCloud-Hystrix

1.为什么使用Hystrix

Hystrix是国外知名的视频网站Netflix所开源的非常流行的高可用架构框架。Hystrix能够完美的解决分布式系统架构中打造高可用服务面临的一系列技术难题。
Hystrix “豪猪”，具有自我保护的能力。hystrix 通过如下机制来解决雪崩效应问题。

在微服务架构中，我们把每个业务都拆成了单个服务模块，然后当有业务需求时，服务间可互相调用，但是，由于网络原因或者其他一些因素，有可能出现服务不可用的情况，当某个服务出现问题时，其他服务如果继续调用这个服务，就有可能出现线程阻塞，但如果同时有大量的请求，就会造成线程资源被用完，这样就可能会导致服务瘫痪，由于服务间会相互调用，很容易造成蝴蝶效应导致整个系统宕掉。因此，就有人提出来断路器来解决这一问题。

服务学崩效应
服务雪崩效应产生与服务堆积在同一个线程池中，因为所有的请求都是同一个线程池进行处理，这时候如果在高并发情况下，所有的请求全部访问同一个接口，
这时候可能会导致其他服务没有线程进行接受请求，这就是服务雪崩效应效应。

服务降级
在高并发情况下，防止用户一直等待，使用服务降级方式(直接返回一个友好的提示给客户端，调用fallBack方法)

服务熔断
熔断机制目的为了保护服务，在高并发的情况下，如果请求达到一定极限(可以自己设置阔值)如果流量超出了设置阈值，让后直接拒绝访问，保护当前服务。使用服务降级方式返回一个友好提示，服务熔断和服务降级一起使用

服务隔离
因为默认情况下，只有一个线程池会维护所有的服务接口，如果大量的请求访问同一个接口，达到tomcat 线程池默认极限，可能会导致其他服务无法访问。
解决服务雪崩效应:使用服务隔离机制(线程池方式和信号量)，使用线程池方式实現隔离的原理: 相当于每个接口(服务)都有自己独立的线程池，因为每个线程池互不影响，这样的话就可以解决服务雪崩效应。

线程池隔离:
每个服务接口，都有自己独立的线程池，每个线程池互不影响。每个服务都有自己的线程池,每个线程池互不影响,缺点:CPU占用率非常高,不是所有的接口都采用线程池隔离,核心接口一般采用

信号量隔离:
使用一个原子计数器（或信号量）来记录当前有多少个线程在运行，当请求进来时先判断计数器的数值，若超过设置的最大线程个数则拒绝该请求，若不超过则通行，这时候计数器+1，请求返 回成功后计数器-1。

服务限流
服务限流就是对接口访问进行限制，常用服务限流算法令牌桶、漏桶。计数器也可以进行粗暴限流实现。

2.环境的搭建

依赖

	<!-- hystrix断路器 -->
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
		</dependency>

Order客户端
配置文件

feign:
  hystrix:
enabled: true
    
#### hystrix禁止服务超时时间,一般别禁用,可能设置长点
hystrix:  
 command: 
   default: 
      execution: 
       timeout: 
        enabled: false   

启动类

@SpringBootApplication
@EnableEurekaClient
@EnableFeignClients
@EnableHystrix
public class AppOrder {
	public static void main(String[] args) {
		SpringApplication.run(AppOrder.class, args);
	}

}

实现类

    @HystrixCommand(fallbackMethod = "orderCallBack")
    @RequestMapping("/getMember")
    public String getMember() {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "this is member，我是会员服务,springcloud2.0版本" + serverPort;
    }

    public String orderCallBack(){
        return "友好的提示";
    }

上面的方法服务降级默认熔断是10次,如果超过10次,就会进行降级
有个坏处,就是回调必须在本类中创建一个方法,这种写法很冗余,同时把他是整个方法放入到了独立的线程池中,