微服务与Nacos概述-3

这篇具有很好参考价值的文章主要介绍了微服务与Nacos概述-3。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

流量治理

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

流量是一个系统中最重要的运维参数之一,在具体的应用中,作为产品部署,必须进行压力测试jmeter,需要通过压力测试查找应用的QPS值

在高并发系统中,出于系统保护角度考虑,通常会对流量进行限流;不但在工作中要频繁使用,而且也是面试中的高频考点。注意重点在于最常用的限流算法大致有三种:令牌桶算法,漏桶算法,计数器算法

  • 阿里开源的限流框架 Sentinel 中的匀速排队限流策略,就采用了漏桶算法

  • Nginx中的限流模块 limit_req_zone 也是采用了漏桶算法

总结限流算法

  • 固定窗口算法实现简单,性能高,但是会有临界突发流量问题,瞬时流量最大可以达到阈值的2倍

  • 为了解决临界突发流量,可以将窗口划分为多个更细粒度的单元,每次窗口向右移动一个单元,于是便有了滑动窗口算法

  • 滑动窗口当流量到达阈值时会瞬间掐断流量,所以导致流量不够平滑

  • 想要达到限流的目的,又不会掐断流量,使得流量更加平滑?可以考虑漏桶算法!需要注意的是,漏桶算法通常配置一个FIFO的队列使用以达到允许限流的作用

  • 由于速率固定,即使在某个时刻下游处理能力过剩,也不能得到很好的利用,这是漏桶算法的一个短板。

  • 限流和瞬时流量其实并不矛盾,在大多数场景中,短时间突发流量系统是完全可以接受的。令牌桶算法就是不二之选了,令牌桶以固定的速率v产生令牌放入一个固定容量为n的桶中,当请求到达时尝试从桶中获取令牌

  • 当桶满时,允许最大瞬时流量为n;当桶中没有剩余流量时则限流速率最低,为令牌生成的速率v

  • 如何实现更加灵活的多级限流呢?滑动日志限流算法了解一下!这里的日志则是请求的时间戳,通过计算制定时间段内请求总数来实现灵活的限流。当然,由于需要存储时间戳信息,其占用的存储空间要比其他限流算法要大得多。

限流算法并没有绝对的好劣之分,如何选择合适的限流算法呢?

  • 不妨从性能,是否允许超出阈值,落地成本,流量平滑度,是否允许突发流量以及系统资源大小限制多方面考虑

  • 当然市面上也有比较成熟的限流工具和框架。如Google出品的Guava中基于令牌桶实现的限流组件拿来即用;alibaba开源的面向分布式服务架构的流量控制框架Sentinel是基于滑动窗口实现的。

软件系统的可靠性或者可用性经常会使用x个9表示,其中3个9表示1年8.76小时适用于电脑或服务器,4个9表示52.6分钟适用于企业级设备,5个9表示5.26分钟适用于一般电信级设备。具体生产环境中最容易出现的是一种服务的雪崩效应问题。

RESTful接口的重试实现

1、依赖:spring-retry

2、开启Retry支持,在主类或者配置类上使用EnableRetry注解,一般使用在service层,开启retry功能

@RestController
@EnableRetr
public class TestController {
    @Autowired
    private RestTemplate restTemplate;
    @RequestMapping("/test")
    @Retryable(value = Exception.class, maxAttempts = 3, backoff =
    @Backoff(delay = 2000, multiplier = 1.0) )//针对test方法提供了异常重试的支持,value
//是异常类型,maxAttempts最大重试次数,backoff重试的相关参数配置,例如延迟时间等
    public String test() {
        String object = restTemplate.getForObject("http://retryprovider/retry", String.class);
        return object;
    }
    @Recover 对应的异常处理
    public String recover(Exception exception){
        return exception.getMessage();
    }
}

Sentinel

Sentinel是阿里提供的基于滑动窗口的流量控制和熔断降级的工具,用于保证分布式系统中应用的可靠性和稳定性,主要依靠于ProcessorSlotChain处理槽链的方式实现,可以将不同功能的Slot采用责任链模式组织起来,以松耦合的方式实现限流、熔断、系统保护等功能

基本概念

  • 限流

  • 熔断

  • 削峰填谷

在Sentinel应用种会引入一个webUI的管理控制器sentinel-dashboard,管理的默认用户名和口令为sentinel/sentinel

  • 查看集群信息以及各个节点的健康状况

  • 可以提供秒级的服务监控统计

  • 提供GUI进行流控规则配置、熔断降级以及配置规则的推送

限流的基本使用

限流主要用于将超过阈值配置的流量在到达目标之前进行处理

常规的限流策略有2种:QPS每秒的访问次数、处理线程个数

常规的限流处理方式有3种:直接拒绝、冷系统预热、匀速排队

1、添加依赖:spring-cloud-starter-alibaba-sentinel

2、添加配置

# Sentinel 控制台地址
spring.cloud.sentinel.transport.dashboard=localhost:8092

3、在访问的控制器上添加配置

@RestController
public class TestController {
    @GetMapping("/test")
    //可以使用SentinelResource定义资源名称
    // @SentinelResource(value = "hello")
    public String sayHello(String name){
        return "Hello "+name+"!";
    }
}

4、可以通过sentinel-dashboard配置指定资源的流控规则。默认为QPS表示每秒钟允许访问的次数,如果在规定的时间内超过阈值则会产生一个异常FlowException,默认处理方式为快速失败

@RestController
public class TestController {
    @GetMapping("/test")
    //可以使用SentinelResource定义资源名称
    @SentinelResource(value = "hello",blockHandler = "helloBlock")
    public String sayHello(String name){
        return "Hello "+name+"!";
    }
    public String helloBlock(String name, BlockException exception){
        System.out.println(name+"-->"+exception);
        if(BlockException.isBlockException(exception)){
            //限流处理
            return "限流降级:Block:"+exception.getMessage();
        }
        return exception.getMessage();
    }
}
  • Value:资源名称,必需项(不能为空)

  • blockHandler:处理BlockException的函数名称(可以理解对Sentinel的配置进行方法兜底)。

    • 函数要求:

      • 必须是public修饰

      • 返回类型与原方法一致

      • 参数类型需要和原方法相匹配,并在最后加BlockException类型的参数。

  • 默认需和原方法在同一个类中,若希望使用其他类的函数,可配置blockHandlerClass,并指定blockHandlerClass里面的方法。

    • blockHandlerClass:存放blockHandler的类。对应的处理函数必须是public static修饰,否则无法解析,其他要求:同blockerHandler

    fallback:用于在抛出异常的时候提供fallback处理逻辑(可以理解为对java异常情况方法兜底)。

    fallback函数可以针对所有类型的异常(除了exceptionsToIgnore里面排除掉的异常类型)进行处理。

    函数要求:

    • 返回类型与原方法一致

    • 参数类型需要和原方法相匹配,Sentinel 1.6开始,也可以在方法最后加Throwable类型的参数。

    • 默认需和原方法在同一个类中。若希望使用其他类的函数,可配置fallbackClass,并制定fallbackClass里面的方法。

      fallbackClass:存放fallback的类。对应的处理函数必须static修饰,否则无法解析,其他要求:同fallback。

Sentinal-dashboard的配置

阈值类型:阈值类型QPS或者并发线程数

  • 单机QPS为5即每秒只允许5次请求,超出的请求会被拦截并报错。

流控模式:当出现流控问题,就是超过阈值的处理方法

  • 流控模式有直接、关联和链路三种。在添加限流规则时,点击高级选项,可以选择三种流控模式

    • 1、直接,统计当前资源的请求,触发阈值时对当前资源直接限流,也是默认的模式

    • 2、关联,统计与当前资源相关的另一个资源,触发阈值时对当前资源限流。

    • 3、链路,统计从指定链路访问到本资源的请求,触发阈值时对指定链路限流

  • 总结流控模式

    • 直接模式:对当前资源限流

    • 关联模式:高优先级资源触发阈值,对低优先级资源限流。

    • 链路模式:阈值统计时,只统计从指定资源进入当前资源的请求,是对请求来源的限流

流控效果有快速失败、Warm Up和排队等待三种,流控效果是指请求达到流控阈值时应该采取的措施,

  • 1、快速失败:达到阈值后,新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。

  • 2、warm up:预热模式,对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化,从一个较小值逐渐增加到最大阈值。

  • 3、排队等待:让所有的请求按照先后次序排队执行,两个请求的间隔不能小于指定时长

流控效果:1、快速失败是QPS超过阈值时,拒绝新的请求。2、warm up是QPS超过阈值时,拒绝新的请求;QPS阈值是逐渐提升的,可以避免冷启动时高并发导致服务宕机。3、排队等待是请求会进入队列,按照阈值允许的时间间隔依次执行请求;如果请求预期等待时长大于超时时间,直接拒绝。

熔断的基本使用

断路器模式,在具体应用中断路器有Hystrix和Sentinel
微服务与Nacos概述-3,微服务,架构,云原生

状态机包括三个状态

  • closed关闭状态,断路器放行所有请求,并开始统计异常比例、慢请求比例。超过阈值则切换到open状态

  • open打开状态,服务调用被熔断,访问被熔断服务的请求会被拒绝,快速失败,直接走降级逻辑。Open状态5秒后会进入half-open状态

  • half-open半开状态,放行一次请求,根据执行结果来判断接下来的操作。请求成功则切换到closed状态;请求失败则切换到open状态

可以使用Sentinel-dashboard配置熔断规则

Sentinel提供的熔断策略有3种:慢调用RT比例、异常比例、异常个数

@RestController
public class HelloController {
    @Value("${spring.application.name}")
    private String appName;

    @SentinelResource(value = "hello", blockHandler = "handleError",
fallback = "handleException") //可以在控制器中,也可以在业务实现类的方法上
    @RequestMapping("/hello")
    public String sayHello(String name) {
        if(!StringUtils.hasText(name)) throw new
IllegalArgumentException("名称不能为空!");
        return String.format("[%s] said: hello %s!", appName, name);
    }
    public String handleError(String name, BlockException ex) { //流控降级处理
        ex.printStackTrace();
        return "error!"; }
    public String handleException(String name,Throwable t) { //异常降级处理
        return "参数错误!"; }
}

熔断降级处理

熔断降级设计理念,在限制的手段上,Sentinel 和 Hystrix 采取了完全不一样的方法。

Hystrix 通过线程池隔离的方式,来对依赖资源进行了隔离。这样做的好处是资源和资源之间做到了最彻底的隔离。缺点是除了增加了线程切换的成本,过多的线程池导致线程数目过多,还需要预先给各个资源做线程池大小的分配。

Sentinel 对这个问题采取了两种手段:

1、通过并发线程数进行限制。和资源池隔离的方法不同,Sentinel 通过限制资源并发线程的数量,来减少不稳定资源对其它资源的影响。这样不但没有线程切换的损耗,也不需要您预先分配线程池的大小。

当某个资源出现不稳定的情况下,例如响应时间变长,对资源的直接影响就是会造成线程数的逐步堆积。当线程数在特定资源上堆积到一定的数量之后,对该资源的新请求就会被拒绝。堆积的线程完成任务后才开始继续接收请求。

2、通过响应时间对资源进行降级。除了对并发线程数进行控制以外,Sentinel 还可以通过响应时间来快速降级不稳定的资源。当依赖的资源出现响应时间过长后,所有对该资源的访问都会被直接拒绝,直到过了指定的时间窗口之后才重新恢复。文章来源地址https://www.toymoban.com/news/detail-640943.html

到了这里,关于微服务与Nacos概述-3的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 微服务与Nacos概述-2

    微服务是一种软件开发架构,它将一个大型应用程序拆分为一系列小型、独立的服务。每个服务都可以独立开发、部署和扩展,并通过轻量级的通信机制进行交互。 应用开发 common模块中包含服务提供者和服务消费者共享的内容 provider模块是服务的提供者,用于通过SpringMVC的

    2024年02月13日
    浏览(29)
  • 微服务与Nacos概述-4

    每次服务重启后 之前配置的限流规则就会被清空因为是内存态的规则对象,所以就要用到Sentinel一个特性ReadableDataSource 获取文件、数据库或者配置中心是限流规则 依赖: spring-cloud-alibaba-sentinel-datasource 通过文件读取限流规则 在resources新建一个文件 比如flowrule.json 添加限流规

    2024年02月13日
    浏览(51)
  • 微服务与Nacos概述-6

    RBAC 基于角色的访问控制是实施面向企业安全策略的一种有效的访问控制方式。 基本思想是,对系统操作的各种权限不是直接授予具体的用户,而是在用户集合与权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后,该用户就拥

    2024年02月12日
    浏览(68)
  • 微服务与Nacos概述-5

    添加依赖: 定义配置 在主类或者配置类上添加注解以支持OpenClient应用 定义http伪客户端接口 定义控制器,通过feign接口调用远程的服务提供者 测试 负载均衡策略配置 LB中提供了三种负载均衡策略,同时提供接口允许用户自定义扩展 1、定义配置类 2、可以全局或者局部配置

    2024年02月13日
    浏览(29)
  • 微服务 & 云原生:微服务相关技术简要概述

    所谓单体架构,就是只有一台服务器,所有的系统、程序、服务、应用都安装在这一台服务器上。比如一个 bbs 系统,它用到的数据库,它需要存储的图片和文件等,统统都部署在同一台服务器上。 单体架构的好处就是简单,相对便宜。一般在互联网早期、或创业型团队,都

    2024年02月15日
    浏览(68)
  • 微服务概述之微服务架构

    为了解决单体应用的缺点,工程师们想到将原来大的单体应用进行拆分,化整为零形成独立的应用,不过此时这些应用没有直观的入口,因此用传统应用的概念来定义就不太妥当。于是诞生了“服务”,通过服务来描述这种功能性的应用,并其他应用提供功能支持,服务于其

    2024年01月22日
    浏览(42)
  • 微服务·架构组件之服务注册与发现-Nacos

    Nacos服务注册与发现流程 服务注册:Nacos 客户端会通过发送REST请求的方式向Nacos Server注册自己的服务,提供自身的元数据,比如ip地址、端口等信息。 Nacos Server接收到注册请求后,就会把这些元数据信息存储在一个双层的内存Map中。 服务心跳:在服务注册后,Nacos Client会维

    2024年02月02日
    浏览(43)
  • 微服务概述之单体架构

    互联网始于 1969年美国的阿帕网(ARPA),最开始的阿帕网只在美国军方使用。随着时间的推移,一些大学也开始加入建设,慢慢演化成了现在的因特网 (Internet)。随着计算机网络的普及,到现在全世界几乎一半的人口,都在使用互联网产品。日常生活中的各种场景,如商场

    2024年01月22日
    浏览(46)
  • 微服务架构+服务注册中心+Nacos和Eureka+比较分析

    Nacos和Eureka都是常用的服务注册中心,它们可以实现服务的注册、发现、负载均衡等功能,但是它们也有一些区别和优缺点。本资源将从功能特性、生态系统、CAP理论、连接方式、服务异常剔除、操作实例方式、自我保护机制等方面,详细比较和分析Nacos和Eureka的区别。本资源

    2024年02月21日
    浏览(47)
  • 0201概述-网关Gateway-微服务架构

    Spring Cloud Gateway是一个基于Spring Framework 5、Spring Boot 2和Project Reactor等技术开发的API网关,它提供了一系列的过滤器(Filter)来处理HTTP请求和响应,可以轻松地实现路由、负载均衡、限流、重试、熔断、安全控制等功能,可以作为微服务架构中的入口和边缘服务。 Spring Cloud

    2024年02月04日
    浏览(55)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包