-
服务雪崩
-
定义
-
多个微服务之间调用的时候,假设为服务A调用微服务B和微服务C,微服务B和微服务C又调用其他的微服务,这就是所谓的“扇出”。
如果扇出的链路上某个微服务的调用响应时间过长,或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所谓的“雪崩效应”。
-
-
图解
-
正常请求流
-
-
-
-
-
一个系统有故障(阻塞整个用户请求)
-
-
-
-
-
高流量时一个系统有故障(导致所有服务器上的所有资源在数秒内饱和)
-
-
-
-
-
实际情况
- 应用程序中通过网络或客户端库访问可能导致网络请求的每个点都是潜在故障的来源。比故障更糟糕的是,这些应用程序还可能导致服务之间的延迟增加,这会备份队列、线程和其他系统资源,从而导致整个系统出现更多级联故障。
- 需要对故障和延迟进行隔离和管理,以达到单个依赖关系的失败不回影响整个应用程序或系统运行的效果。
-
-
常见场景及应对策略
-
硬件故障
- 如服务器宕机,机房断电,光纤被挖断等。
- 可用多机房容灾、异地多活等策略应对。
-
流量激增
- 如异常流量,重试加大流量等。
- 可用服务自动扩容、流量控制(限流、关闭重试)等策略应对。
-
缓存穿透
- 一般发生在应用重启,所有缓存失效时,以及短时间内大量缓存失效时。大量的缓存不命中,使请求直击后端服务,造成服务提供者超负荷运行,引起服务不可用。
- 可用缓存预加载、缓存异步加载等策略应对。
-
程序BUG
- 如程序逻辑导致内存泄漏,JVM长时间FullGC等。
- 可用修改程序bug、及时释放资源等策略应对。
-
同步等待
- 服务间采用同步调用模式,同步等待造成的资源耗尽。
- 可用资源隔离、MQ解耦、不可用服务调用快速失败等策略应对。资源隔离通常指不同服务调用采用不同的线程池;不可用服务调用快速失败一般通过熔断器模式结合超时机制实现。
-
-
-
服务熔断
-
定义
-
熔断机制是应对服务雪崩效应的一种微服务链路保护机制,当扇出链路的某个微服务不可用或者响应时间太长时,会进行服务的降级,进而熔断该节点微服务的调用,快速返回”错误”的响应信息。当检测到该节点微服务响应正常后恢复调用链路。
-
-
作用
-
对上游故障的补偿(开发)
- 由于断路器允许开发人员处理服务故障,客户端可以以一种优雅的方式随时间动态地适应服务可用性的变化。
- 在微服务架构中共享状态的断路器提供了网络效果,可以显著提高故障响应能力。
- 断路器与智能路由和负载均衡相结合,可以自动用健康的服务实例替换故障的服务实例,从而促进自修复。
-
监控和补救(运维)
- 当断路器跳闸时,通过调查相关日志和指标,运维人员可能会决定将部分或大部分流量从服务中分流。由于它缓解了系统的急性压力、分流或削减负荷,因此成为了运维团队中对于断路器最流行的使用方式。
- 将断路器定义为这种架构中预先确定的断点。理想情况下,这种断路器应该安装在已知能够承受与关键系统成正比的负载的地方。这类断路器在本质上就像架构中的金丝雀(canaries,具体可见他人文章《微服务治理实践 | 金丝雀发布》)一样工作,通过卸载来促进再修复。
-
-
发展趋势
- 随着断路器从客户端库发展到中间件、共享状态断路器和平台,它们的定义也变得越来越多样化。
- 断路器的开发人员和运维人员的应用场景出现了分歧,其定义涉及越来越多的参数。
- 举例:
- 目前云流量控制器(如Glasnostic)所提供的熔断功能,可以应用于由任意端点集定义的通信链路,并结合一些互补模式(如超时、反压或Brownouts)。
- 然后,随着时间的推移,结合一些参数(如请求速率、并发性、带宽或延迟)对这些模式组合进行优化。
-
-
Reference
- Hystrix原理与实战
https://blog.csdn.net/loushuiyifan/article/details/82702522
- SpringCloud学习笔记(五)(狂神视频笔记)
https://blog.csdn.net/hexinqiong/article/details/116399814
- 微服务中的熔断简介及工作原理详解