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

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


高并发带来的问题

在微服务架构中,我们将业务拆分成一个个的服务,服务与服务之间可以相互调用,但是由于网络原因或者自身的原因,服务并不能保证服务的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折叠掉

目录
相关文章
|
7月前
|
Java UED Sentinel
微服务守护神:Spring Cloud Sentinel,让你的系统在流量洪峰中稳如磐石!
【8月更文挑战第29天】Spring Cloud Sentinel结合了阿里巴巴Sentinel的流控、降级、熔断和热点规则等特性,为微服务架构下的应用提供了一套完整的流量控制解决方案。它能够有效应对突发流量,保护服务稳定性,避免雪崩效应,确保系统在高并发下健康运行。通过简单的配置和注解即可实现高效流量控制,适用于高并发场景、依赖服务不稳定及资源保护等多种情况,显著提升系统健壮性和用户体验。
133 1
|
7月前
|
负载均衡 应用服务中间件 持续交付
微服务架构下的Web服务器部署
【8月更文第28天】随着互联网应用的不断发展,传统的单体应用架构逐渐显露出其局限性,特别是在可扩展性和维护性方面。为了解决这些问题,微服务架构应运而生。微服务架构通过将应用程序分解成一系列小型、独立的服务来提高系统的灵活性和可维护性。本文将探讨如何在微服务架构中有效部署和管理Web服务器实例,并提供一些实际的代码示例。
262 0
|
3月前
|
监控 API 开发者
Sentinel:微服务的全能守护
Sentinel 是阿里巴巴开源的一款轻量级流量控制和熔断降级框架。它通过设置流量控制、熔断降级和系统保护规则,确保微服务在高并发场景下稳定运行。Sentinel 提供丰富的功能、实时监控和灵活的集成方式,适用于各种分布式系统。
313 0
|
3月前
|
监控 Java Sentinel
Hystrix 与 Sentinel 大比拼:微服务稳定性工具谁更优?
Hystrix 和 Sentinel 是用于微服务架构中保护服务稳定性和可靠性的工具,主要实现服务熔断、限流、降级等功能。Hystrix 侧重于熔断器模式和服务隔离,通过线程池或信号量隔离服务,防止故障扩散;Sentinel 则更全面,涵盖流量控制、熔断降级和系统自适应保护,适用于高并发场景,并提供实时监控和灵活的策略调整。两者设计理念不同,Hystrix 适合中小规模应用,而 Sentinel 更适合大规模高并发系统。
63 0
|
4月前
|
算法 Java API
Sentinel学习圣经:从入门到精通 Sentinel,最全详解 (40+图文全面总结)
尼恩给大家做一下系统化、体系化的梳理,联合社群小伙伴,来一个Sentinel学习圣经:从入门到精通Sentinel。
|
7月前
|
负载均衡 监控 Java
SpringCloud常见面试题(一):SpringCloud 5大组件,服务注册和发现,nacos与eureka区别,服务雪崩、服务熔断、服务降级,微服务监控
SpringCloud常见面试题(一):SpringCloud 5大组件,服务注册和发现,nacos与eureka区别,服务雪崩、服务熔断、服务降级,微服务监控
10217 6
SpringCloud常见面试题(一):SpringCloud 5大组件,服务注册和发现,nacos与eureka区别,服务雪崩、服务熔断、服务降级,微服务监控
|
6月前
|
XML Java 数据库
在微服务架构中,请求常跨越多个服务,涉及多组件交互,问题定位因此变得复杂
【9月更文挑战第8天】在微服务架构中,请求常跨越多个服务,涉及多组件交互,问题定位因此变得复杂。日志作为系统行为的第一手资料,传统记录方式因缺乏全局视角而难以满足跨服务追踪需求。本文通过一个电商系统的案例,介绍如何在Spring Boot应用中手动实现日志链路追踪,提升调试效率。我们生成并传递唯一追踪ID,确保日志记录包含该ID,即使日志分散也能串联。示例代码展示了使用过滤器设置追踪ID,并在日志记录及配置中自动包含该ID。这种方法不仅简化了问题定位,还具有良好的扩展性,适用于各种基于Spring Boot的微服务架构。
79 3
|
5月前
|
存储 Linux 网络安全
【VMware VCF】使用 SFTP 服务器备份 VCF 核心组件的配置文件
【10月更文挑战第6天】以下是使用 SFTP 服务器备份 VMware VCF 核心组件配置文件的步骤:首先,设置 SFTP 服务器并配置用户账号与权限;其次,确保 VCF 环境能与 SFTP 服务器建立网络连接,并检查防火墙规则;接着,识别核心组件配置文件的位置,并使用 SFTP 客户端工具(如 `lftp` 或 WinSCP)进行备份;最后,验证备份结果的完整性和正确性,并定期执行备份操作,设置备份文件保留策略以节省存储空间。
|
7月前
|
运维 Cloud Native 开发者
云原生技术演进:从微服务到无服务器的旅程
【8月更文挑战第20天】在数字化时代的浪潮中,云原生技术如同一艘航船,承载着企业转型的梦想与挑战。本文将深入探讨云原生技术的发展路径,从微服务的兴起到无服务器架构的革新,揭示这一技术演进背后的逻辑与动力。通过分析云原生技术的优势、面临的挑战以及未来的发展趋势,我们将描绘出一幅云原生技术演进的宏伟蓝图。
|
7月前
|
运维 Cloud Native 云计算
云原生架构的演进:从微服务到无服务器计算
在数字化转型的浪潮中,云原生技术以其灵活性、可扩展性和成本效益性,成为推动现代软件开发和运维的关键力量。本文将探讨云原生概念的演变,特别是从微服务架构到无服务器计算的转变,揭示这一进化如何影响应用程序的开发、部署和管理。通过分析实际案例,我们旨在提供对云原生技术未来趋势的洞察,同时指出企业在这一转变过程中可能面临的挑战和机遇。
67 2