
目录
背景
分布式架构面临的问题:服务雪崩
多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务,这就是所谓的"扇出"。如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所谓的“雪崩效应”。
对于高流量的应用来说,单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是,这些应用程序还可能导致服务之间的延迟增加,备份队列,线程和其他系统资源紧张,导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理,以便单个依赖关系的失败,不能取消整个应用程序或系统。所以,通常当你发现一个模块下的某个实例失败后,这时候这个模块依然还会接收流量,然后这个有问题的模块还调用了其他的模块,这样就会发生级联故障,或者叫雪崩。
比较经典的就是23年10.23号各大厂的生产故障:语雀、阿里云产品控制台、阿里系大部分产品(淘宝、咸鱼、阿里云盘)崩溃。
如何解决?
出现有问题的节点,快速熔断(快速返回失败处理或者返回默认兜底数据【服务降级】)。
"断路器"本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方无法处理的异常,这样就保证了服务调用方的线程不会被长时间、不必要地占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩。
相对应的措施就是:
- 服务熔断:类比保险丝,保险丝闭合状态(CLOSE)可以正常使用,当达到最大服务访问后,直接拒绝访问跳闸限电(PEN),此刻调用方会接受服务降级的处理并返回友好提示
- 服务降级:服务器忙,请稍后再试。不让客户端等待并立刻返回一个友好提示,fallback
- 服务限流:秒杀高并发操作,限制速率
- 服务限时
- 服务预热:一开始放20、30个,后面慢慢增加量100个等等
- 接近实时的监控
以上功能现在市面上可用的是Hystrix,但Hystrix已经停止更新进入维护状态,官方给出最好替代是Resilience4j。
所以推荐使用Resilience4j!
CircuitBreaker
CircuitBreaker的目的是保护分布式系统免受故障和异常,提高系统的可用性和健壮性。
当一个组件或服务出现故障时,CircuitBreaker会迅速切换到开放OPEN状态(保险丝跳闸断电),阻止请求发送到该组件或服务从而避免更多的请求发送到该组件或服务。这可以减少对该组件或服务的负载,防止该组件或服务进一步崩溃,并使整个系统能够继续正常运行。同时,CircuitBreaker还可以提高系统的可用性和健壮性,因为它可以在分布式系统的各个组件之间自动切换,从而避免单点故障的问题。
Circuit Breaker只是一套规范和接口,落地实现者是Resilience4J。

Resilience4j
Resilience4j 是一个专为函数式编程而设计的轻量级容错库。Resilience4j 提供高阶函数(装饰器),以增强任何功能接口、lambda 表达式或方法引用,包括断路器、速率限制器、重试或隔板。您可以在任何函数接口、lambda 表达式或方法引用上堆叠多个装饰器。优点是您可以选择所需的装饰器,而没有别的。
Resilience4j 2 需要 Java 17。
核心功能
- resilience4j-circuitbreaker:熔断
- resilience4j-ratelimiter:速率限制
- resilience4j-bulkhead: 舱壁
- resilience4j-retry:自动重试(同步和异步)
- resilience4j-timelimiter:超时处理
- resilience4j-cache:结果缓存
还有用于度量的附加模块、Feign、Kotlin、Spring、Ratpack、Vertx、RxJava2 等。
本文主要讲前三个核心功能,其他的功能可用其他组件替代,并不是王牌。
CircuitBreaker 服务熔断+服务降级
断路器有三个普通状态:关闭(CLOSED)、开启(OPEN)、半开(H

最低0.47元/天 解锁文章
3245

被折叠的 条评论
为什么被折叠?



