一、背景介绍
1、服务雪崩
分布式系统环境下,服务间类似依赖非常常见,一个业务调用通常依赖多个基础服务。如下图
如果各个服务正常运行,那大家其乐融融,高高兴兴的,但是如果其中一个服务崩坏掉会出现什么样的情况呢?如下图
当Service A的流量波动很大,流量经常会突然性增加!那么在这种情况下,就算Service A能扛得住请求,Service B和Service C未必能扛得住这突发的请求。
此时,如果Service C因为抗不住请求,变得不可用。那么Service B的请求也会阻塞,慢慢耗尽Service B的线程资源,Service B就会变得不可用。紧接着,Service A也会不可用。
So,简单地讲。一个服务失败,导致整条链路的服务都失败的情形,我们称之为服务雪崩。
2、引起雪崩的原因和服务雪崩的三个阶段
原因大致有四:
1、硬件故障;
2、程序Bug;
3、缓存击穿(用户大量访问缓存中没有的键值,导致大量请求查询数据库,使数据库压力过大);
4、用户大量请求;
服务雪崩的第一阶段: 服务不可用;
第二阶段:调用端重试加大流量(用户重试/代码逻辑重试);
第三阶段:服务调用者不可用(同步等待造成的资源耗尽);
3、解决方案
1) 应用扩容(扩大服务器承受力)
加机器
升级硬件
2)流量控制(超出限定流量,返回类似重试页面让用户稍后再试)
限流
关闭重试
3) 缓存
将用户可能访问的数据大量的放入缓存中,减少访问数据库的请求。
4)服务降级
服务接口拒绝服务
页面拒绝服务
延迟持久化
随机拒绝服务
5) 服务熔断
如果对服务降级和服务熔断的概念模糊点此了解 关于服务熔断和服务降级的详解
二、Hystrix入门
Hystrix简介
Hystrix [hɪst’rɪks],中文含义是豪猪,因其背上长满棘刺,从而拥有了自我保护的能力。
以项目案例开始,快速入门(使用IDEA)
场景假设1( 服务提供方报错) : 在服务提供端中因为访问不到数据库中的数据(比如数据不存在,或是数据库压力过大,查询请求队列中),在这种情况下,服务提供方这边如何实现服务降级,以防止服务雪崩.
- 使用IDEA新建一个 microservice-provider-hystrix 工程
- 因为此工程要受到Hystrix保护,所以加入依赖.
- 3.在microservice-provider-hystrix 工程的启动类上启用断路器
在启动类上加入注解
@EnableCircuitBreaker //启用断路器
注意: 这里其实也可以使用 spring cloud应用中的@SpringCloudApplication注解,因为它已经自带了这些注解,源码如下:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class application {
public static void main(String[] args) {
SpringApplication.run(application.class, args);
}
}
@RestController
@RequestMapping("/test")
public class test {
@GetMapping("/hello/{id}")
@HystrixCommand(fallbackMethod="errorCallBack") //模仿没有这个数据时,服务降级
public Object hello(@PathVariable("id") long id){
if(id == 0){
throw new RuntimeException("查询无此产品");
}
return id;
}
//指定一个降级的方法
public Object errorCallBack(@PathVariable("id") long id){
System.out.println("降级了");
return "接口失败";
}
}