SpringCloud：Sentinel 与 雪崩问题

何鸭子
48 阅读4分钟

Sentinel 与 雪崩问题

携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第7天，点击查看活动详情

1. 雪崩问题及解决方案

1.1 雪崩问题

  • 什么是雪崩问题

    在微服务系统中，整个系统是以一系列固有功能的微服务组成。如果某一个固有功能微服务因为流量异常或其他问题导致响应异常，会影响到调用该服务的其他微服务，从而引起了一系列的连锁反应，最终导致整个系统崩溃。 这也就是我们所说的雪崩问题/雪崩效应。下面通过图片来展示案例。

    1. 所有微服务正常，微服务D、E、F 调用微服务B、C，而B、C调用微服务A。

      image-20220809151145865

    2. 微 服务A出现异常

      image-20220809151313359

    3. 影响微服务B、C，导致B、C出现异常

      image-20220809151401589

    4. 微服务D、E、F出现异常，整体服务瘫痪

      image-20220809151501833

  • 雪崩问题产生的场景

    1. 流量激增：比如异常流量、用户重试导致系统负载升高
    2. 程序bug：内存泄漏、线程池中的线程只有后未释放等
    3. 硬件问题：宕机、机房断电、光纤挖断
    4. 同步等待：系统间常采用同步服务调用模式。核心服务和非核心服务共用一个线程池和消息队列。如果一个核心业务线程调用非核心线程，而非核心线程出现故障，就会导致核心线程堵塞，一直处于等待时间。而进程间的调用有超时限制，最终因为超时所以核心线程断开，引起雪崩。
    5. 缓存击穿：常见于秒杀系统或热门事件。短时间内大量缓存失效导致大量缓存不命中，使请求直击后方，造成服务提供者超负荷运行，导致服务不可用

雪崩问题原因多，保证服务不挂机和流畅运行是我们不可推卸的责任。

我们会通过下面介绍的四种方式来减小出现雪崩问题的可能

1.2 超时处理

  • 超时处理：设定超过时间，请求超过限定时间没有响应就返回错误信息给用户，不会无休止等待。

    微服务 A 向微服务 C 发送请求，超时没有响应便自动返回错误信息给微服务 A。

    image-20220809161311036

  • 个人理解：超时不回应就当你废了。

超时处理只是减缓了雪崩问题的发生，而不是解决了雪崩问题。如果微服务 A 在一秒内向微服务 C 发送多个请求，而每秒只能对一个请求超时处理。那么微服务 A 中的线程也会被逐渐占满最后形成雪崩。

1.3 舱壁模式

  • 舱壁模式：设定每个服务可使用线程数，避免消耗所有的线程资源。可称呼为线程隔离。

    微服务 A 给微服务 C 分配10个线程可供使用。当 A 向 C 发送请求没有回应则继续发送，直到 C 的可用线程资源全部耗尽。

    image-20220809162742696

  • 个人理解：一条船多层多个船舱相互隔绝。一个船舱破了进水不会影响别的船舱。

舱壁模式虽然解决了雪崩问题，但是资源上有些许的浪费：假如微服务 C 真的宕机，那么就浪费了10个线程资源来向 C 发送请求。

1.4 熔断降级

  • 熔断降级：由断路器来统计服务的异常比例，如果超出阈值就会熔断该业务，拦截访问该业务的一切请求。

    在调用端即上游服务控制对下游服务的熔断功能，在上游服务中，如果发现下游服务在一定时间内，其超时率达到了某个阈值，则开启熔断机制，即不对下游服务进行调用，或者只进行一定比例的调用，而对于剩下的流量，则直接返回空响应或者返回默认响应。

    image-20220809165555986

  • 个人理解：类似生命值，过了比例就死了，再也会访问。

熔断模式既能解决雪崩问题，也能减少资源的浪费。

1.5 流量控制

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

    通过限制调用端的流量数来达到限流的目的。比如控制实例每秒钟的处理请求量，即控制QPS。常见的QPS控制方法有令牌桶算法

    image-20210715173555158

avatar
文章
阅读
粉丝