必不可少的 Hystrix

最新推荐文章于 2024-04-29 23:28:39 发布

转载最新推荐文章于 2024-04-29 23:28:39 发布 · 160 阅读

CC 4.0 BY-SA版权

原文链接：https://github.com/Snailclimb/JavaGuide/blob/master/docs/system-design/micro-service/spring-cloud.md#%E5%BE%AE%E6%9C%8D%E5%8A%A1%E7%BD%91%E5%85%B3zuul

JAVA ------ SpringCloud 专栏收录该内容

5 篇文章

订阅专栏

本文介绍了Hystrix库如何通过熔断和降级防止服务雪崩。当服务调用失败率超过阈值时，Hystrix的断路器会自动熔断请求链路，避免级联故障。降级则是当方法调用异常时，执行备用逻辑以提供友好的用户体验。此外，文章还提及了舱壁模式用于隔离服务调用，防止单个服务问题影响整个系统。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

什么是 Hystrix之熔断和降级

在分布式环境中，不可避免地会有许多服务依赖项中的某些失败。
Hystrix是一个库，可通过添加等待时间容限和容错逻辑来帮助您控制这些分布式服务之间的交互。
Hystrix通过隔离服务之间的访问点，停止服务之间的级联故障并提供后备选项来实现此目的，所有这些都可以提高系统的整体弹性。

总体来说 Hystrix 就是一个能进行熔断和降级的库，通过使用它能提高整个系统的弹性。

那么什么是熔断和降级呢？再举个🌰，此时我们整个微服务系统是这样的。服务A调用了服务B，服务B再调用了服务C，但是因为某些原因，服务C顶不住了，这个时候大量请求会在服务C阻塞。

服务C阻塞了还好，毕竟只是一个系统崩溃了。但是请注意这个时候因为服务C不能返回响应，那么服务B调用服务C的的请求就会阻塞，同理服务B阻塞了，那么服务A也会阻塞崩溃。

请注意，为什么阻塞会崩溃。
因为这些请求会消耗占用系统的线程、IO 等资源，消耗完你这个系统服务器不就崩了么。

这就叫服务雪崩。妈耶，上面两个熔断和降级你都没给我解释清楚，你现在又给我扯什么服务雪崩？😫😫😫

别急，听我慢慢道来。

不听我也得讲下去！

所谓熔断就是服务雪崩的一种有效解决方案。当指定时间窗内的请求失败率达到设定阈值时，系统将通过断路器直接将此请求链路断开。

也就是我们上面服务B调用服务C在指定时间窗内，调用的失败率到达了一定的值，那么 Hystrix 则会自动将服务B与C 之间的请求都断了，以免导致服务雪崩现象。

其实这里所讲的熔断就是指的 Hystrix 中的断路器模式，你可以使用简单的 @HystrixCommand 注解来标注某个方法，这样 Hystrix 就会使用断路器来“包装”这个方法，每当调用时间超过指定时间时(默认为1000ms)，断路器将会中断对这个方法的调用。

当然你可以对这个注解的很多属性进行设置，比如设置超时时间，像这样。

@HystrixCommand(
    commandProperties = {@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "1200")}
)
public List<Xxx> getXxxx() {
    // ...省略代码逻辑
}

但是，我查阅了一些博客，发现他们都将熔断和降级的概念混淆了，以我的理解，降级是为了更好的用户体验，当一个方法调用异常时，通过执行另一种代码逻辑来给用户友好的回复。这也就对应着 Hystrix 的后备处理模式。你可以通过设置 fallbackMethod 来给一个方法设置备用的代码逻辑。比如这个时候有一个热点新闻出现了，我们会推荐给用户查看详情，然后用户会通过id去查询新闻的详情，但是因为这条新闻太火了(比如最近什么*易对吧)，大量用户同时访问可能会导致系统崩溃，那么我们就进行服务降级，一些请求会做一些降级处理比如当前人数太多请稍后查看等等。

// 指定了后备方法调用
@HystrixCommand(fallbackMethod = "getHystrixNews")
@GetMapping("/get/news")
public News getNews(@PathVariable("id") int id) {
    // 调用新闻系统的获取新闻api 代码逻辑省略
}
// 
public News getHystrixNews(@PathVariable("id") int id) {
    // 做服务降级
    // 返回当前人数太多，请稍后查看
}

什么是Hystrix之其他

我在阅读《Spring微服务实战》这本书的时候还接触到了一个舱壁模式的概念。在不使用舱壁模式的情况下，服务A调用服务B，这种调用默认的是使用同一批线程来执行的，而在一个服务出现性能问题的时候，就会出现所有线程被刷爆并等待处理工作，同时阻塞新请求，最终导致程序崩溃。而舱壁模式会将远程资源调用隔离在他们自己的线程池中，以便可以控制单个表现不佳的服务，而不会使该程序崩溃。

具体其原理我推荐大家自己去了解一下，本篇文章中对舱壁模式不做过多解释。当然还有 Hystrix 仪表盘，它是用来实时监控 Hystrix 的各项指标信息的，这里我将这个问题也抛出去，希望有不了解的可以自己去搜索一下。