15.0、springcloud-Hystrix-服务降级的实现、以及降级与熔断的区别
先来聊一聊什么是 服务降级 ,比如说我们现在有三个服务器A、B、C , 当到了一个时间段,发现访问A服务器的人变得很多很多,而B和C服务器的访问量却很少,那么我们为了防止整体资源不够用、A服务器压力过大崩塌,所以只能忍痛将B和C暂时先停掉,让A服务器能够正常的运作,然后等度过这个高并发的难关再重新开启,这就是服务降级。
【所有学习环境的搭建在前面的文章有说到】
第一步:在 springcloud-api 模块下的 service文件夹 中创建一个
DeptClientServiceFallBack.java 并让他实现 FallbackFactory 这个类,如下:
package com.hkl.springcloud.service;
import com.hkl.springcloud.pojo.Dept;
import feign.hystrix.FallbackFactory;
import java.util.List;
@Component
public class DeptClientServiceFallBack implements FallbackFactory {
@Override
public Object create(Throwable throwable) {
return new DeptClientService() {
@Override
public Dept queryById(long id) {
Dept dept = new Dept();
dept.setDeptno(id);
dept.setDname("服务器已关闭,该时间段无法访问,请稍后再试");
dept.setDb_source("当前无数据~");
return dept;
}
@Override
public List<Dept> queryAll() {
return null;
}
@Override
public boolean addDept(Dept dept) {
return false;
}
};
}
}
【注意】这里降级虽然说和熔断比较的像但还是有很大区别的,狭义的说熔断针对的是某个方法,而降级是针对某整个服务
第二步:在 DeptClientService.java接口 中的 @FeignClient注解 中加上 fallbackFactory 属性
package com.hkl.springcloud.service;
import com.hkl.springcloud.pojo.Dept;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.stereotype.Repository;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.PostMapping;
import java.util.List;
@FeignClient(value = "SPRINGCLOUD-PROVIDER-DEPT",fallbackFactory = DeptClientServiceFallBack.class)
@Repository
public interface DeptClientService {
@GetMapping("/dept/get/{id}")
public Dept queryById(@PathVariable("id") long id);
@GetMapping("/dept/list")
public List<Dept> queryAll();
@PostMapping("/dept/add")
public boolean addDept(Dept dept);
}
第三步:在 springcloud-consume-dept-feign 客户端模块中的 application.yaml 配置文件中开启 hystrix 的降级功能,
为什么在 Feign 中测试呢?
因为可以发现要用到 Feigin 面向接口的方式去访问才可以,因为Service层中要用到@FeignClient注解 的 FallbackFactory属性
#开启feign.hystrix服务降级功能
feign:
hystrix:
enabled: true
好了配置完这个之后,我们就可以来测试一下了:
启动注册中心、启动服务者、启动消费者,然后访问一下 queryById() 这个方法当然正常访问成功。
然后关闭服务提供者的服务器,再次访问这个方法:
如果没有之前我们的降级操作就会 直接报错 ,那这里当然 没有报错 而是给用户提示:“当前服务暂停使用,请稍后再试”
概念理解:
服务的熔断 是在 服务端 被迫进行的,而服务的降级 是在 客户端 主动进行的。
为什么这么说呢?我自己的理解是这样的:
服务的熔断:
服务的熔断 是在当一个服务 出现 异常、超时等错误的时候,服务器能够 down 掉然后启用另一条备选方案从而防止整个服务器雪崩。熔断是一个被动的解决方法,因为他是等待错误的出现,然后才被迫的 down 掉这个服务去执行备选流。这里是从服务端进行解决【注意:这里的服务端准确的来说指的是后台的服务提供端口的服务器嗷~】
服务的降级:
服务的降级是当某个服务器的访问量突然激增,为了让他能够正常运行,所以主动暂时的强制关闭掉该时间段访问量较少的服务器,保证整体资源的充足。这样虽然整体的服务水平降低了,但是好歹能用~
所以说降级是主动的处理机制,在服务器即将崩掉或者出现异常之前就进行降级的处理方案,保证他不出错能够正常执行
但是为什么说他是在客户端就进行的呢?
我的个人理解是:因为后台服务器已经关闭了,所以也不就存在什么服务端的处理了,直接在客户端就给拦截处理掉了【注意:这里的客户端指的不是前端嗷~,指的是后台调用服务的端口服务器】
熔断 和 负载均衡 是互不干扰的;
熔断在后端执行,负载均衡在消费者端执行,这两者整合不用担心。但是我还不太清楚降级和负载均衡应该怎么整合,因为他俩都是在客户端执行的~