springcloud微服务(六)服务保护机制SpringCloud Hystrix

微服务高可用技术

大型复杂的分布式系统中，高可用相关的技术架构非常重要。

高可用架构非常重要的一个环节，就是如何将分布式系统中的各个服务打造成高可用的服务，从而足以应对分布式系统环境中的各种各样的问题，，避免整个分布式系统被某个服务的故障给拖垮。

比如：服务间的调用超时，服务间的调用失败

要解决这些棘手的分布式系统可用性问题，就涉及到了高可用分布式系统中的很多重要的技术，包括：

资源隔离、限流与过载保护、熔断、优雅降级、容错、超时控制、监控运维

服务降级、熔断、限流概念

服务学崩效应

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

这时候可能会导致其他服务没有线程进行接受请求，这就是服务雪崩效应效应。

服务降级

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

服务熔断

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

服务隔离

因为默认情况下，只有一个线程池会维护所有的服务接口，如果大量的请求访问同一个接口，达到tomcat 线程池默认极限，可能会导致其他服务无法访问。

解决服务雪崩效应:使用服务隔离机制(线程池方式和信号量)，使用线程池方式实現隔离的原理: 相当于每个接口(服务)都有自己独立的线程池，因为每个线程池互不影响，这样的话就可以解决服务雪崩效应。

Hystrix简单介绍

Hystrix是国外知名的视频网站Netflix所开源的非常流行的高可用架构框架。Hystrix能够完美的解决分布式系统架构中打造高可用服务面临的一系列技术难题。

Hystrix “豪猪”，具有自我保护的能力。hystrix 通过如下机制来解决雪崩效应问题。

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

资源隔离：包括线程池隔离和信号量隔离，限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用。

降级机制：超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。

融断：当失败率达到阀值自动触发降级(如因网络故障/超时造成的失败率高)，熔断器触发的快速失败会进行快速恢复。

缓存：提供了请求缓存、请求合并实现。

Hystrix环境搭建

Maven依赖信息

  <!-- hystrix断路器 -->

      <dependency>

          <groupId>org.springframework.cloud</groupId>

          <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>

      </dependency>

开启Hystrix断路器

feign超时时间需要设置，否则会报错

java.net.SocketTimeoutException: Read timed out

##开启hystrix

  feign.hystrix.enabled= true

  #### hystrix禁止服务超时时间 
  hystrix.command.default.execution.timeout.enabled= false

  #并发执行的最大线程数，默认10

  #hystrix.threadpool.default.coreSize= 200

  #BlockingQueue的最大队列数，默认值-1

  #hystrix.threadpool.default.maxQueueSize= 1000

  #即使maxQueueSize没有达到，达到(队列拒绝阈值)queueSizeRejectionThreshold该值后，请求也会被拒绝，默认值5

 # hystrix.threadpool.default.queueSizeRejectionThreshold=  800
#如果并发数达到该设置值，请求会被拒绝和抛出异常并且fallback不会被调用。默认10

 # hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests= 500

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

}

服务降级处理注解方式

@HystrixCommand(fallbackMethod = "orderToUserInfoFallback")
	@GetMapping("/orderToUserInfo")
	public ResponseBase orderToUserInfoHystrix() {
		System.out.println("orderToUserInfo:" + "当前线程池名称:" + Thread.currentThread().getName());
		return memberServiceFeigin.getUserInfo();
	}

	@RequestMapping("/orderToUserInfoFallback")
	public ResponseBase orderToUserInfoFallback() {
		return setResultError("系统错误!!!!");
	}

如果每个方法都写@HystrixCommand(fallbackMethod = "orderToUserInfoFallback")

会显得比较麻烦，那么如何写个所有方法共用的呢？
使用 @HystrixCommand+@DefaultProperties即可直接在类上加上@DefaultProperties(defaultFallback = " orderToUserInfoFallback ") 方法上直接用@HystrixCommand就可以了

效果

当大量请求频繁访问orderToUserInfo接口会调用orderToUserInfoFallback方法

服务降级处理接口方式

@RequestMapping("/orderToUserInfo")
	public ResponseBase orderToUserInfo() {
		return memberServiceFeigin.getUserInfo();
	}

  @Component
public class MemberServiceFallback extends BaseApiService implements   MemberServiceFeigin {
	public ResponseBase getUserInfo() {
		// 服务降级处理
		return setResultError("系统错误,请稍后重试!");
	}

}

Hystrix的异常处理

我们在调用服务提供者时,我们自己也有可能会抛异常,默认情况下方法拋了异常会自动进行服务降级,交给服务降级中的方法去处理。

当我们自己发生异常后,只需要在服务降级方法中添加一个Throwable类型的参数就能够获取到抛出的异常的类型,如下

public String error(Throwable throwable){

     System.out.println("异常信息："+throwable.getMessage()); 

//访问远程服务失败，该如何处理，这些处理逻辑就可以写在该方法中      return  "ERROR";

}

此时我们可以在控制台看到异常的类型; 如果远程服务有一个异常抛出后我们不希望进入到服务降级方法中去处理,而是直接将异常抛给用户，那么我们可以在@HystrixCommand注解中忽略异常，如下：

@HystrixCommand(fallbackMethod="error",ignoreExceptions = Exception.class)