微服务保护详细笔记（一）：雪崩问题--Sentinel

本文链接：https://blog.csdn.net/m0_73927143/article/details/142387521

1.雪崩问题

1.1.雪崩问题产生原因：

比如查询购物车的业务，假如商品服务业务并发较高，占用过多Tomcat连接。可能会导致商品服务的所有接口响应时间增加，延迟变高，甚至是长时间阻塞直至查询失败。

此时查询购物车业务需要查询并等待商品查询结果，从而导致查询购物车列表业务的响应时间也变长，甚至也阻塞直至无法访问。而此时如果查询购物车的请求较多，可能导致购物车服务的Tomcat连接占用较多，所有接口的响应时间都会增加，整个服务性能很差，甚至不可用。

依次类推，整个微服务群中与购物车服务、商品服务等有调用关系的服务可能都会出现问题，最终导致整个集群不可用。

这就产生了级联失败问题，也称雪崩问题

言简意赅的说：雪崩问题产生的原因是什么？
微服务相互调用，服务提供者出现故障或阻塞。
微服务调用者没有做好异常处理，导致自身故障。
调用链中的所有服务级联失败，导致整个集群故障。

那么我们解决问题的思路有哪些？
尽量避免服务出现故障或阻塞：
- 保持代码的健壮性；
- 保持网络畅通；
- 能应对较多的并发请求；
服务调用者做好远程调用异常的后备方案，避免故障扩散

业务健壮性问题：

比如在查询购物车列表业务中，购物车服务需要查询最新的商品信息，与购物车数据做对比，提醒用户。大家设想一下，如果商品服务查询时发生故障，查询购物车列表在调用商品服务时，是不是也会异常？从而导致购物车查询失败。但从业务角度来说，为了提升用户体验，即便是商品查询失败，购物车列表也应该正确展示出来，哪怕是不包含最新的商品信息。