Hystrix的异常处理和限流

最新推荐文章于 2024-01-31 07:48:05 发布

Denial_learn

最新推荐文章于 2024-01-31 07:48:05 发布

阅读量1.3k

点赞数

分类专栏：微服务-Netflix

本文链接：https://blog.csdn.net/Denial_learn/article/details/119891690

版权

微服务-Netflix 专栏收录该内容

19 篇文章 0 订阅

订阅专栏

本文详细介绍了Hystrix在微服务架构中的异常处理机制，包括服务降级和如何捕获并处理异常。同时，讨论了Hystrix的限流功能，通过线程池限制服务调用，防止系统过载。通过设置线程池参数，可以实现精细化的流量控制，确保在高并发场景下系统的稳定性和资源的有效利用。

摘要由CSDN通过智能技术生成

Hystrix的异常处理

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

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

public ResultObject fallback(Throwable throwable) {
    System.out.println(throwable.getMessage());
    return new ResultObject(Constant.ONE,"服务降级");
}

当然远程服务发生了异常也可以获取到异常信息；

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

@HystrixCommand(fallbackMethod = "fallback", ignoreExceptions=Throwable.class,

降级是作用？

可以监听你的请求有没有超时；（默认是1秒，时间可以改）
异常或报错了可以快速让请求返回，不会一直等待；（避免线程累积）
当的系统马上迎来大量的并发(双十一秒杀这种或者促销活动) 此时如果系统承载不了这么大的并发时，可以考虑先关闭一些不重要的微服务（在降级方法中返回一个比较友好的信息)，把资源让给核心微服务，待高峰流量过去，再开启回来。

Hystrix限流

限流有很多方案：

Nginx
Redis + Lua
Sentinel
基于限流算法自己实现（令牌桶、漏桶算法）

hystrix限流就是限制你某个微服务的使用量（可用线程数、信号量）
hystrix通过线程池的方式来管理微服务的调用，它默认是一个线程池（大小10个）管理你的所有微服务，你可以给某个微服务开辟新的线程池：

@RequestMapping("/cloud/goodsHystrix2")
@HystrixCommand(fallbackMethod = "fallback",
                threadPoolKey = "goods",
                threadPoolProperties = {@HystrixProperty(name = "coreSize", value = "2"),
                @HystrixProperty(name = "maxQueueSize", value = "1")})
public ResultObject goodsHystrix2() throws InterruptedException {

threadPoolKey 是线程池唯一标识， hystrix 会使用该标识来计数，看线程占用是否超过了，超过了就会直接降级该次调用；
这里coreSize给他值为2 那么假设你这个方法调用时间是1s执行完，那么在1s内如果有超过2个请求进来的话，剩下的请求则全部降级；
其中maxQueueSize是一个线程队列，里面只能放一个请求线程，本来线程数有2个，队列里面允许放一个，那么总共只能有3个请求线程执行，如果超过了就会限流；