Sentinel - 服务容错

1. 高并发带来的问题

在微服务架构中,我们将业务拆分成了一个又一个的微服务,应用层面的微服务要调用服务层面的微服务,但是由于网络或者自身的原因,并不能保证100%的调用成功,服务提供者也无法保证服务100%可用。

如果单个服务出现问题,调用这个服务就会出现网络延迟,如果此时处于高并发的场景,也就是说瞬间会涌入大量的连接,最终会导致连接耗尽,服务瘫痪。

1.1 模拟高并发场景

在商品微服务上,睡眠100毫秒,模拟网络拥堵

package com.mszlu.shop.goods.controller;

import com.mszlu.common.Result;
import com.mszlu.shop.goods.service.GoodsService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("goods")
public class GoodsController {

    @Autowired
    private GoodsService goodsService;

    @GetMapping("findGoods/{id}")
    public Result findGoods(@PathVariable("id") Long id){
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return goodsService.findGoodsById(id);
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

新写一个简单的商品微服务接口,用户当查询商品服务连接耗尽后,其他接口的访问情况:

修改tomcat的并发数,默认是200 ,将其改小一点:

server:
  port: 8002
  tomcat:
    max-threads: 10
    max-connections: 10
1
2
3
4
5

1.2 Jmeter压测

  1. 下载启动

    https://jmeter.apache.org/download_jmeter.cgi

    下载jmeter,解压进入bin目录,找到jmeter.properties,修改语言:

    language=zh_CN
    
    1

    双击jmeter.bat启动。

  2. 添加线程组

    image-20210620164940501

  3. 配置线程并发数,可以配置为200 效果更明显

    image-20210620165120692

  4. 添加http取样

    image-20210620165237142

  5. 配置取样,并启动测试

    访问商品微服务的查询商品接口:

    image-20210620171653165

  6. 启动测试后,调用商品微服务的测试接口

    image-20210620172056435

    经过测试,我们发现,test接口出现访问问题,不能正常的提供服务,或者响应延迟。

    这是因为findGoods接口 囤积了大量的请求,占用了所有的资源,一旦这样的接口多了,就会引起服务器的崩溃。

2. 服务雪崩问题

在分布式系统中,由于网络原因或自身的原因,服务一般无法保证100%可用,如果一旦一个服务出现问题,调用这个服务就会出现线程阻塞的情况,此时若有大量的请求涌入,就会出现多条线程阻塞等待,进而导致服务瘫痪。

由于服务和服务之间的依赖性,故障会传播,会对整个微服务系统造成灾难性的严重后果,这就是服务故障的“雪崩效应”。

image-20210620175700098

雪崩效应发生的原因多种多样,有不合理的容量设计,或者是高并发下某一个方法出现了响应变慢,亦或是某台机器的资源耗尽,我们无法完全杜绝雪崩的源头的发生,只有做好足够的容错,保证在一个服务发生问题,不会影响到其他服务的正常运行。

也就是“雪落而不雪崩”。

其实最好的办法,还是尽量减少服务之间的依赖

3. 常见的容错方案

要防止雪崩的扩散,我们就要做好服务的容错,容错说白了就是保护自己不被猪队友拖垮的一些措施,下面介绍常见的服务容错思路和组件。

3.1常见的容错思路

常见的容错思路有隔离,超时,限流,熔断,降级这几种。

3.1.1 隔离

它是指将系统按照一定的原则划分为若干个服务模块,各个模块之间相互独立,无强依赖。

当有故障发生时,能将问题和影响隔离在某个模块内部,而不扩散风险,不波及其他模块,不影响整体的系统服务。

常见的隔离方式有:线程池隔离信号量隔离

image-20210620195420440

线程池隔离中,一旦某个服务挂了,只会影响其中分配的连接,不会影响别的服务的执行,有限的分配连接。

image-20210620202113571

信号量隔离,设置了接收连接的上限,适用于可以快速返回的服务。

3.1.2 超时

在上游服务调用下游服务的时候,设置一个最大响应时间,如果超过这个时间,下游未做反应,就断开请求,释放掉线程。

image-20210620204301184

3.1.3 限流

限流就是限制系统的输入和输出流量,已达到保护系统的目的。为了保证系统的稳固运行,一旦达到需要限制的阈值,就需要限制流量并采取少量限制措施以完成限制流量的目的。

image-20210620205937575

3.1.4 熔断

在互联网系统中,当下游服务因访问压力过大而响应变慢或失败,上游系统为了保护系统整体的可用性,可以暂时切断对下游服务的调用。这种牺牲局部,保全整体的措施就叫做熔断。

image-20210622201522361

服务熔断一般有三种状态:

  1. 熔断关闭状态(closed)

    服务没有故障时,熔断器所处的状态,对调用方的调用不做任何限制

  2. 熔断开启状态

    后续对该服务接口的调用不在经过网络,直接执行本地的fallback方法

  3. 半熔断状态

    尝试恢复服务调用,允许有限的流量调用该服务,并监控调用成功率。如果成功率达到预期,则说明服务已恢复,进入熔断关闭状态;如果成功率依旧很低,则重新进入熔断开启状态。

3.1.5 降级

降级其实就是为服务提供一个拖底方案,一旦服务无法正常调用,就使用托底方案。

image-20210622204735618