服务容错保护： Spring Cloud Hystrix
1.引出断路器：
在微服务架构中，我们将系统拆分为很多个服务，各个服务之间通过注册与订阅的方式相互依赖，由于各个服务都是在各自的进程中运行，就有可能由于网络原因或者服务自身的问题导致调用故障或延迟，随着服务的积压，可能会导致服务崩溃。为了解决这一系列的问题，断路器等一系列服务保护机制出现了。
断路器本身是一种开关保护机制，用于在电路上保护线路过载，当线路中有电器发生短路时，断路器能够及时切断故障电路，防止发生过载、发热甚至起火等严重后果。
在分布式架构中，断路器模式的作用也是类似的。
针对上述问题，Spring Cloud Hystrix 实现了断路器、线路隔离等一系列服务保护功能。它也是基于 Netflix 的开源框架 Hystrix 实现的，该框架的目标在于通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix 具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能。
2.快速入门
在开始实现断路器之前，先用之前实现的一些内容作为基础，构建一个如下图所示的服务调用关系。
2.1Hystrix设计原则
1.防止单个服务的故障，耗尽整个系统服务的容器（比如tomcat）的线程资源，避免分布式环境里大量级联失败。通过第三方客户端访问（通常是通过网络）依赖服务出现失败、拒绝、超时或短路时执行回退逻辑
2.用快速失败代替排队 (每个依赖服务维护一个小的线程池或信号量，当线程池满或信号量满，会立即拒绝服务而不会排队等待)和优雅的服务降级；当依赖服务失效后又恢复正常，快速恢复
3.提供接近实时的监控和警报 ，从而能够快速发现故障和修复。监控信息包括请求成功，失败（客户端抛出的异常），超时和线程拒绝。如果访问依赖服务的错误百分比超过阈值,断路器会跳闸，此时服务会在一段时间内停止对特定服务的所有请求
4.将所有请求外部系统（或请求依赖服务）封装到HystrixCommand或HystrixObservableCommand对象中，然后这些请求在一个独立的线程中执行。使用 隔离技术 来限制任何一个依赖的失败对系统的影响。每个依赖服务维护一个小的线程池（或信号量），当线程池满或信号量满，会立即拒绝服务而不会排队等待
Hystrix特性
1.请求熔断： 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN).
这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.
2.服务降级：Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.告知后面的请求服务不可用了，不要再来了。
3.依赖隔离(采用舱壁模式，Docker就是舱壁模式的一种)：在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池.比如说，一个服务调用两外两个服务，你如果调用两个服务都用一个线程池，那么如果一个服务卡在哪里，资源没被释放
后面的请求又来了，导致后面的请求都卡在哪里等待，导致你依赖的A服务把你卡在哪里，耗尽了资源，也导致了你另外一个B服务也不可用了。这时如果依赖隔离，某一个服务调用A B两个服务，如果这时我有100个线程可用，我给A服务分配50个，给B服务分配50个，这样就算A服务挂了，
我的B服务依然可以用。
4.请求缓存：比如一个请求过来请求我userId=1的数据，你后面的请求也过来请求同样的数据，这时我不会继续走原来的那条请求链路了，而是把第一次请求缓存过了，把第一次的请求结果返回给后面的请求。
5.请求合并：我依赖于某一个服务，我要调用N次，比如说查数据库的时候，我发了N条请求发了N条SQL然后拿到一堆结果，这时候我们可以把多个请求合并成一个请求，发送一个查询多条数据的SQL的请求，这样我们只需查询一次数据库，提升了效率。
Hystrixl流程图如下：
Hystrix流程说明:
1:每次调用创建一个新的HystrixCommand,把依赖调用封装在run()方法中.
2:执行execute()/queue做同步或异步调用.
4:判断熔断器(circuit-breaker)是否打开,如果打开跳到步骤8,进行降级策略,如果关闭进入步骤5.
5:判断线程池/队列/信号量是否跑满，如果跑满进入降级步骤8,否则继续后续步骤6.
6:调用HystrixCommand的run方法.运行依赖逻辑
6a:依赖逻辑调用超时,进入步骤8.
7:判断逻辑是否调用成功
7a:返回成功调用结果
7b:调用出错，进入步骤8.
8:计算熔断器状态,所有的运行状态(成功, 失败, 拒绝,超时)上报给熔断器，用于统计从而判断熔断器状态.
9:getFallback()降级逻辑.以下四种情况将触发getFallback调用：
(1):run()方法抛出非HystrixBadRequestException异常。
(2):run()方法调用超时
(3):熔断器开启拦截调用
(4):线程池/队列/信号量是否跑满
9a:没有实现getFallback的Command将直接抛出异常
9b:fallback降级逻辑调用成功直接返回
9c:降级逻辑调用失败抛出异常
10:返回执行成功结果
对之前的Ribbon进行Hystrix集成。如果对一个请求进行熔断，必然不能让客户直接去调用那个请求，你必然要要对别人的请求进行包装一层和拦截，才能做点手脚，比如进行熔断，所以说要在Ribbon上动手脚。因为它是请求发起的地方。
我们刚开始请求一个服务，为了负载均衡进行了拦截一次，现在我们要进行熔断，所以必须跟Ribbon集成一次，再进行请求拦截来熔断。
2.2 引入Hystrix相关的依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
<version>1.4.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
<version>1.4.0.RELEASE</version>
</dependency>
在启动类中加入@EnableCircuitBreaker注解，表示允许断路器。
import com.netflix.loadbalancer.IRule;
import com.netflix.loadbalancer.RandomRule;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.circuitbreaker.EnableCircuitBreaker;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
import org.springframework.cloud.client.loadbalancer.LoadBalanced;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;
@SpringBootApplication
@EnableDiscoveryClient
//允许断路器
@EnableCircuitBreaker
public class RibbonApplication {
public static void main(String[] args) {
SpringApplication.run(RibbonApplication.class, args);
}
@Bean
public IRule ribbonRule(){
return new RandomRule();
}
@Bean
@LoadBalanced
public RestTemplate restTemplate(){
return new RestTemplate();
}
}
2.3 修改之前的 Ribbon ，新建一个service
/**
* 测试
*/
@Service
public class HelloService {
@Autowired
private RestTemplate restTemplate;
//请求熔断注解，当服务出现问题时候会执行fallbackMetho属性的名为helloFallBack的方法
@HystrixCommand(fallbackMethod = "helloFallBack")
public String helloService() throws ExecutionException, InterruptedException {
return restTemplate.getForEntity("http://HELLO-SERVICE/hello",String.class).getBody();
}
public String helloFallBack(){
return "error";
}
}
Hystrix给我们提供了HystrixCommand类，让我们去继承它，去实现灵活的熔断和服务降级。
import com.netflix.hystrix.HystrixCommand;
import com.netflix.hystrix.HystrixCommandGroupKey;
import org.springframework.web.client.RestTemplate;
/**
* 测试
*/
public class HelloServiceCommand extends HystrixCommand<String> {
private RestTemplate restTemplate;
protected HelloServiceCommand(String commandGroupKey,RestTemplate restTemplate) {
super(HystrixCommandGroupKey.Factory.asKey(commandGroupKey));
this.restTemplate = restTemplate;
}
@Override
protected String run() throws Exception {
System.out.println(Thread.currentThread().getName());
return restTemplate.getForEntity("http://HELLO-SERVICE/hello",String.class).getBody();
}
@Override
protected String getFallback() {
return "error";
}
}
PS:非阻塞式IO有两个分别是：Future将来式，Callable回调式
1.Future将来式：就是说你用Future将来式去请求一个网络IO之类的任务，它会一多线程的形式去实现，主线程不必卡死在哪里等待，等什么时候需要结果就通过Future的get()方法去取，不用阻塞。
2.Callable回调式：预定义一个回调任务，Callable发出去的请求，主线程继续往下执行，等你请求返回结果执行完了，会自动调用你哪个回调任务。
其实HelloServiceCommand类几面不用变，只需要改变一下在Controller层的command的调用方式即可，command的叫用方式如下：
Future<String> queue = command.queue();
return queue.get();
然后重启Ribbon模块。
2.4Future的注解方式调用如下所示：
/**
* 测试
*/
@Service
public class HelloService {
@Autowired
private RestTemplate restTemplate;
@HystrixCommand(fallbackMethod = "helloFallBack")
public String helloService() throws ExecutionException, InterruptedException {
Future<String> future = new AsyncResult<String>() {
@Override
public String invoke() {
return restTemplate.getForEntity("http://HELLO-SERVICE/hello",String.class).getBody();
}
};
return future.get();
}
public String helloFallBack(){
return "error";
}
}
2.5 使用Hystrix的仪表盘
通过访问http://localhost:8001/hystrix就可以得到如下界面：
总结：
雪崩效应的原因：
- 服务提供者不可用
a.硬件故障
b.程序Bug
c.用户大量请求：在秒杀和大促开始前,如果准备不充分,用户发起大量请求造成服务提供者的不可用
- 重试加大流量
a.用户重试：用户由于忍受不了界面上长时间的等待,而不断刷新页面甚至提交表单
b.代码逻辑重试：服务调用端的会存在大量服务异常后的重试逻辑
- 服务调用者不可用
a.同步等待造成的资源耗尽：使用 同步调用 时, 会产生大量的等待线程占用系统资源. 一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态, 造成服务雪崩效应产生
雪崩效应的解决措施：
1) 流量控制
a.网关限流
因为Nginx的高性能, 目前一线互联网公司大量采用Nginx+Lua的网关进行流量控制, 由此而来的OpenResty也越来越热门.
b.用户交互限流
具体措施:
a21. 采用加载动画,提高用户的忍耐等待时间.
a22. 提交按钮添加强制等待时间机制.
c.关闭重试
2) 改进缓存模式
a.缓存预加载
b.同步改为异步刷新
3) 服务自动扩容
a.AWS的auto scaling
4) 服务调用者降级服务
a.资源隔离：主要是对调用服务的线程池进行隔离.
b.对依赖服务进行分类
依赖服务分为: 强依赖和若依赖. 强依赖服务不可用会导致当前业务中止,而弱依赖服务的不可用不会导致当前业务的中止.
c.不可用服务的调用快速失败
一般通过 超时机制,熔断器 和 熔断后的 降级方法 来实现
Less is more.
