微服务组件(高并发带来的问题服务器雪崩效应 Sentinel入门)

最新推荐文章于 2024-04-04 09:15:00 发布

杨宸杨

最新推荐文章于 2024-04-04 09:15:00 发布

阅读量5.1k

点赞数 7

分类专栏：微服务文章标签：微服务服务器 sentinel

本文链接：https://blog.csdn.net/m0_62434717/article/details/128823430

版权

微服务专栏收录该内容

12 篇文章 3 订阅

订阅专栏

高并发带来的问题服务器雪崩效应 Sentinel入门

高并发带来的问题
- 模拟高并发
服务器雪崩效应
- 常见容错方案
Sentinel入门(常见的容错组件)

高并发带来的问题

在微服务架构中，我们将业务拆分成一个个的服务，服务与服务之间可以相互调用，但是由于网络原因或者自身的原因，服务并不能保证服务的100%可用，如果单个服务出现问题，调用这个服务就会出现网络延迟，此时若有大量的网络涌入，会形成任务堆积，最终导致服务瘫痪。

模拟高并发

1.创建SentinelController

@RestController
    public class SentinelController {
        @RequestMapping("/sentinel1")
        public String sentinel1() throws InterruptedException {
            TimeUnit.SECONDS.sleep(1);
            return "sentinel1";
        }
        @RequestMapping("/sentinel2")
        public String sentinel2() throws InterruptedException {
            return "sentinel2";
        }
    }

2.修改配置文件中tomcat的并发数

tomcat:
  threads:
    max: 10 #tomcat的最大并发值修改为10

服务器雪崩效应

在分布式系统中,由于网络原因或自身的原因,服务一般无法保证100%可用。如果一个服务出现了问题，调用这个服务就会出现线程阻塞的情况，此时若有大量的请求涌入，就会出现多条线程阻塞等待，进而导致服务瘫痪。
由于服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩效应”。
服务器的雪崩效应其实就是某个微小的服务器挂了，导致整一大片的服务器都不可用，类似生活中的雪崩效应，由于落下的最后一片雪花引发了雪崩的情况。
雪崩发生的原因多种多样，有不合理的容量设计，或者是高并发下某一个方法响应变慢，亦或是某台机器的资源耗尽。我们无法完全杜绝雪崩源头的发生，只能做好足够的容错，保证在一个服务器发生问题，不会影响到其它服务的正常运行。

常见容错方案

1.隔离机制:比如服务A内总共有100个线程,现在服务A可能会调用服务B,服务C,服务D.我们在服务A进行远程调用的时候,给不同的服务分配固定的线程,不会把所有线程都分配给某个微服务.比如调用服务B分配30个线程,调用服务C分配30个线程，调用服务D分配40个线程.这样进行资源的隔离，保证即使下游某个服务挂了，也不至于把服务A的线程消耗完。比如服务B挂了，这时候最多只会占用服务A的30个线程,服务A还有70个线程可以调用服务C和服务D。

2.超时机制:在上游服务调用下游服务的时候，设置一个最大响应时间，如果超过这个时间，下游未作出反应，就断开请求，释放掉线程。

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

4.熔断机制:在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。
服务熔断一般有三种状态:
。熔断关闭状态(Closed)
服务没有故障时，熔断器所处的状态，对调用方的调用不做任何限制
。熔断开启状态(Open)
后续对该服务接口的调用不再经过网络，直接执行本地的fallback方法4.
。半熔断状态(Half-Open)
尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率。如果成功率达到预期，则说明服务已恢复，进入熔断关闭状态;如果成功率仍旧很低，则重新进入熔断关闭状态。

5.降级机制:降级其实就是为服务提供一个兜底的方案了，一旦服务无法正常调用，就使用兜底方案

注意：在调用第三方接口的时候不能同步调用，要么通过异步线程池，要么通过mq消息中间件的方式

Sentinel入门(常见的容错组件)

什么是Sentinel?

Sentinel (分布式系统的流量防卫兵)是阿里开源的一套用于服务容错的综合性解决方案。它以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度来保护服务的稳定性

Sentinel管控台:针对服务进行规则的配置
Sentinel核心库:做具体的信息拦截和请求发送

订单服务集成Sentinel

第一步：导入依赖

<!--sentinel组件-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency

第二步：增加配置文件

spring:
  cloud:
    sentinel:
      transport:
        port: 9999 #跟控制台交流的端口，随意指定一个未使用的端口即可
        dashboard: localhost:8080 #指定控制台服务的地址

第三步：安装sentinel控制台

下载jar包

在这里插入图片描述

启动控制台
java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar

成功标志

进入到控制台面板，登录账号和密码默认都是sentinel
在这里插入图片描述

流控规则

流量控制，其原理是监控应用流量的QPs(每秒查询率)或并发线程数等指标，当达到指定的阈值时对流量进行控制

资源名:唯一名称，默认是请求路径，可自定义
针对来源:指定对哪个微服务进行限流，默认指default，意思是不区分来源，全部限制阈值类型/单机阈值:
.QPS(每秒请求数量):当调用该接口的QPs达到阈值的时候，进行限流
·线程数:当调用该接口的线程数达到阈值的时候，进行限流
是否集群:暂不需要集群

预热流控

在这里插入图片描述
前期初始化需要消耗大量资源，所以需要将流量控制的少一点

等待流控

在这里插入图片描述 如果一个请求等待的时间超过规定时间，就会被流控

关联流控

当某一核心资源的重要请求到达他的阈值，为了保证它能够正常运转，对别的不重要的请求进行限流
在这里插入图片描述

链路流控

在这里插入图片描述
不添加该属性的话，默认会将tranceService折叠掉

公共部分：

public class SentinelServiceImpl {
    @SentinelResource(value = "tranceService")
    public String resourceMethod(){
        //做业务
        return "业务资源";
    }
}

Controller接口：

@RestController
    public class TraceController {

        @Autowired
        private SentinelServiceImpl sentinelService;
        @RequestMapping("/trace1")
        public String trace1(){
            sentinelService.resourceMethod();
            return "trace1";
        }

        @RequestMapping("/trace2")
        public String trace2(){
            sentinelService.resourceMethod();
            return "trace2";
        }
    }