• 了解雪崩产生的原因
• 理解常见解决方案

随着微服务架构的广泛应用，应用程序的复杂性已经得到了显著提高，但与之同时，微服务雪崩问题也开始引起广泛关注。微服务雪崩是指在微服务架构中，一个或多个微服务出现故障或不可用时，导致整个系统的不稳定甚至崩溃。本文将介绍微服务雪崩的产生原因以及一些常见的解决方案。

1. 雪崩介绍

微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。

如图，如果服务提供者I发生了故障，当前的应用的部分业务因为依赖于服务I，因此也会被阻塞。此时，其它不依赖于服务I的业务似乎不受影响。

但是，依赖服务I的业务请求被阻塞，用户不会得到响应，服务器的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。

那么，依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了：

总结雪崩产生原因

• 依赖关系复杂性： 在微服务架构中，各个服务之间存在复杂的依赖关系。如果一个服务出现故障，它可能会导致依赖于它的其他服务也无法正常工作。
• 大规模部署： 大规模部署意味着有大量的服务实例在运行，当其中一部分实例出现问题时，整个系统可能受到影响。
• 同时故障： 有时，多个服务可能因相同的原因（如硬件故障、网络问题或配置错误）而同时故障，导致雪崩效应。
• 超时和重试： 如果某个服务在请求时长时间未响应，其他服务可能会发起重试请求，导致更多的负载，最终导致系统崩溃。
• 资源耗尽： 当某个服务的资源（如数据库连接、线程池）被过度消耗时，它可能会无法响应请求，从而引发雪崩。

2. 雪崩解决方案

雪崩解决常见解决方案有以下几种:

• 超时处理：对于每个微服务的请求，应该设置合理的超时时间。超时时间应该充分考虑服务的响应时间和业务需求，以避免等待时间过长导致的问题
• 舱壁模式（Bulkhead Pattern for Avalanche）:系统遇到雪崩风险时，通过隔离不同服务或组件，以防止一个故障或高负载情况影响整个系统的稳定性。是一种应对潜在雪崩的设计模式
• 限流（Rate Limiting）: 限流可以控制对服务的请求速率，确保不会超出服务的处理能力。这可以防止流量过多而导致系统崩溃
• 熔断器模式（Circuit Breaker Pattern）：熔断器模式是一种容错模式，用于避免雪崩效应。熔断器会监控服务的健康状态，当服务连续出现故障或响应时间超过阈值时，熔断器会打开，阻止进一步的请求流量流向该服务，从而保护系统的稳定性
• 降级策略（Fallback）： 降级是一种处理服务不可用或性能下降的策略，它允许系统在出现问题时提供有限但稳定的功能，而不是完全失败。当服务出现问题时，降级策略可以返回默认值、缓存数据、执行备用操作或者提供一个基本的响应，以确保用户仍然能够访问系统的一部分功能

2.1. 超时处理

针对服务调用增加超时机制(一般dubbo默认30s)，一旦超时自动释放资源，因释放资源较快一定程度可抑制资源耗尽问题。但如果在超时释放的时间内陡增大量请求，依然会导致服务宕机不可用。

2.2. 舱壁模式（Bulkhead Pattern for Avalanche）

仓壁模式来源于船舱的设计：船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没。于此类似，我们可以限定每个业务能使用的线程数，避免耗尽整个服务器的资源，因此也叫线程隔离。

2.3. 熔断器模式（Circuit Breaker Pattern）

熔断器模式：由熔断器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。

熔断器会统计访问某个服务的请求数量，异常比例

当发现访问服务D的请求异常比例过高时，认为服务D有导致雪崩的风险，会拦截访问服务D的一切请求，形成熔断：

2.4. 限流

限流：限制业务访问的QPS，避免服务因流量的突增而故障。

雪崩问题:

• 微服务之间相互调用，因为调用链中的一个服务故障，引起整个链路都无法访问的情况。

解决方案:

限流是对服务的保护，避免因瞬间高并发流量而导致服务故障，进而避免雪崩。是一种预防措施。

超时处理、线程隔离、降级熔断是在部分服务故障时，将故障控制在一定范围，避免雪崩。是一种补救措施。