精华内容
下载资源
问答
  • 容错限流:Hystrix

    2019-11-07 16:57:46
    https://blog.csdn.net/qq_25484147/article/details/83375225 https://blog.csdn.net/qq_23181091/article/details/80785453 ...容错限流:Hystrix 1 解决的问题 微服务下,假设每个...

    来源:
    《微服务架构实战160讲》
    https://blog.csdn.net/qq_25484147/article/details/83375225

    https://blog.csdn.net/qq_23181091/article/details/80785453

    https://cloud.tencent.com/developer/article/1477400

    容错限流:Hystrix

    1 解决的问题

    微服务下,假设每个服务的可用性为四个9,总体可用性肯定会有所下降,导致时不时地会有一段时间不可用,比如每个请求都依赖很多服务,如果某个服务延迟很慢,那么用户请求都会阻塞在这里,用户体验很差,即“高峰期雪崩效应”

    2 容错限流原理

    • 基本的容错模式:五种方法
      在这里插入图片描述

    • 断路器模式
      在这里插入图片描述
      原理是一个状态机,三种状态进行切换

    • 舱壁隔离(Bulkhead)模式

    对资源进行失败单元的隔离,每个或若干个失败单元出问题都不影响整体

    • 容错理念

    1 凡是依赖都可能会失败(这也是写代码时要考虑健壮性的原因,如判空)

    2 凡是资源都有限制: CPU/Memory/Threads/Queue

    3 网络并不可靠

    4 延迟是应用稳定性差的主要原因(延迟会占据大量的资源)

    5 弹性理念:出问题后恢复原状的能力

    • 限流:线程和信号量隔离

    线程池隔离:为每个服务创建一个线程池

    信号量隔离:一个服务拥有一个计数器,一个请求代表一个数
    在这里插入图片描述

    • 请求熔断

    当Hystrix Command请求后端服务失败数量超过一定比例(默认50%),断路器会切换到开路状态(Open);
    此时所有请求会直接失败而不会发送到后端服务.;
    断路器保持在开路状态一段时间后(默认5秒),,自动切换到半开路状态(HALF-OPEN),这时熔断器只允许一个请求通过.;
    当该请求调用成功时,,熔断器恢复到关闭状态, 若该请求失败, 熔断器继续保持打开状态,,接下来的请求被禁止通过;
    如此循环反复

    • 服务降级

    Fallback相当于是降级操作.;
    对于查询操作,可以实现一个fallback方法,当请求后端服务出现异常的时,可以使用fallback方法返回的值.;fallback方法的返回值一般是设置的默认值或者来自缓存,告知后面的请求服务不可用了,不要再来了。

    3 架构设计

    • 工作流程:自适应反馈机
      在这里插入图片描述
      流程中会判断电路是否打开?线程池/队列是否满了?超时?等状况,如果失败,则进入getFallback()

    最后这些状况都会报告给Calculate Circuit Health,提供下次判断的依据

    Hystrix命令模式封装了命令运行逻辑(run)和服务调用失败时回退逻辑(getFallback)。
    其command抽象类是HystrixCommand,用于包装执行具有潜在风险功能的代码(通常指通过网络进行的服务调用),具备容错和延时,统计和性能指标捕获,断路器和舱壁功能。

    getFallback即熔断之后的降级流程,可以看到熔断和降级在Hystrix中是相结合的

    • 内核设计:一秒一个的滚筒式设计
      在这里插入图片描述
      一秒产生一个新桶,统计”成功”“失败”“超时“”拒绝”的请求个数

    每次请求进行先到达allowRequest,如果isOpen为false,则可以通过,执行一个请求

    isOpen()计算错误率是否超过阀值,如果超过则close circuit

    滚筒即Metrics,有两个,一个是现在的,一个是新生成的,用来统计信息,即Calculate Circuit Health

    4 参考部署

    在这里插入图片描述
    turbine:聚合Hystrix的流,通过Eureka发现网卡的实例,发起流的连接,通过apollo动态地调配Hystrix的配置(每个微服务的配置不同,使用apollo集中配置好一点)

    展开全文
  • 本文主要讲述网关结合熔断器来进行容错限流的处理。 熔断器主要应用在超时、服务器端错误等使用场景中。可以将Gateway和Hystrix集成,通过过滤器配置,加入fallbackUri来实现。因为netflix-hystrix停止更新的缘故...

    目录

    容错

        pom文件

        容错控制器

        配置

        测试

    限流

    依赖

    修改启动项,配置限流的Bean

    配置文件配置限流过滤器

    测试

    端点

         依赖

         配置文件开启端点支持

         添加动态路由


           路由容错主要通过处理未定义的路由和熔断器来实现。本文主要讲述网关结合熔断器来进行容错限流的处理。

           熔断器主要应用在超时、服务器端错误等使用场景中。可以将Gateway和Hystrix集成,通过过滤器配置,加入fallbackUri来实现。因为netflix-hystrix停止更新的缘故,在spring-cloud-gateway-server 2.x版本中,还有HystrixGatewayFilterFactory这个类,但在spring-cloud-gateway-server 3.x版本中,HystrixGatewayFilterFactory不在了,取而代之的是SpringCloudCircuitBreakerFilterFactory。推荐使用Spring Cloud CircuitBreaker GatewayFilter Factory。

           SpringCloudCircuitBreaker API是对多种断路器提供的一层抽象API,SpringCloudCircuitBreaker本身提供了对4种断路器组件的支持:

    • Netfix Hystrix
    • Resilience4J
    • Sentinel
    • Spring Retry

           如果要在Spring Cloud Gateway中使用CircuitBreaker功能,则只能使用其中的2个组件:Netfix Hystrix和Resilience4J

    容错

        pom文件

    		<dependency>
    			<groupId>org.springframework.cloud</groupId>
    			<artifactId>spring-cloud-starter-gateway</artifactId>
    		</dependency>
    		<!-- Spring Cloud Consul 的支持-->
    		<dependency>
    			<groupId>org.springframework.cloud</groupId>
    			<artifactId>spring-cloud-starter-consul-discovery</artifactId>
    		</dependency>
    
    		<dependency>
    			<groupId>org.springframework.cloud</groupId>
    			<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
    			<version>2.2.6.RELEASE</version>
    		</dependency>
    		<dependency>
    			<groupId>org.springframework.cloud</groupId>
    			<artifactId>spring-cloud-starter-circuitbreaker-reactor-resilience4j</artifactId>
    			<version>2.0.0</version>
    		</dependency>

        容错控制器

    package com.example.demo.ch09.controller;
    
    import org.springframework.web.bind.annotation.RequestMapping;
    import org.springframework.web.bind.annotation.RestController;
    import reactor.core.publisher.Mono;
    
    import java.util.HashMap;
    import java.util.Map;
    
    @RestController
    public class NotFoundController {
    
        @RequestMapping(value = "/fallback")
        public Mono<Map<String, String>> notFound() {
            Map<String, String> stringMap = new HashMap<>();
            stringMap.put("code", "100");
            stringMap.put("data", "Service Not Available");
            return Mono.just(stringMap);
        }
    }

        配置

    这里使用YAML配置

    server:
      port: 8220
    spring:
      application:
        name: gateway-consul
      cloud:
        gateway:
          routes:
            - id: hello
              uri: lb://service-provider/hello/
              predicates:
                - Path=/hello
                - Method=GET
              filters:
                - AddRequestParameter=name,songyunhui
                - name: CircuitBreaker
                  args:
                    name: fallbackcmd
                    fallbackUri: forward:/fallback #配置了fallback时要回调的路径,当 Hystrix的 fallback被调用时,请求将转发到fallback
          discovery:
            locator:
              enabled: true #是否与服务中心的发现组件进行整合
        consul:
          host: 10.1.12.22
          port: 8500
          discovery:
            instance-id: ${spring.application.name}:${server.port}
    logging:
      level:
        ROOT: INFO
    feign:
      circuitbreaker:
        enabled: true #开启Hystrix

     

    其中,fallbackUri表示熔断后应该访问的地址,可以是外部地址,也可以是内部地址。

     

        测试

    1、“服务提供者”正常工作,访问http://localhost:8220/hello

    2、关闭“服务提供者”,访问http://localhost:8220/hello

    控制台:

    WARN 9316 --- [oundedElastic-1] o.s.c.l.core.RoundRobinLoadBalancer      : No servers available for service: service-provider

     

    限流

           一般限流都在网关层实现,比如使用Nginx、Zuul、Spring Cloud Gateway、Openresty、Kong等。常见的限流算法有:计数器、漏桶、令牌桶。限流算法是通用的,而非Spring Cloud Gateway独有。

           Spring Cloud Gateway内置了限流工厂RequestRateLimiterGatewayFilterFactory,它底层是使用Redis的Lua脚本实现的。在Spring Cloud Gateway上实现限流很简单,只需要编写相应的过滤器即可。

    依赖

    		<dependency>
    			<groupId>org.springframework.boot</groupId>
    			<artifactId>spring-boot-starter-data-redis-reactive</artifactId>
    			<version>2.3.8.RELEASE</version>
    		</dependency>

           需要添加Redis依赖,并配置好Redis服务器,详情参见linux下部署单机版redis

    修改启动项,配置限流的Bean

           在GatewayApplication中添加:

    	@Bean
    	public KeyResolver ipKeyResolver() {
    		//按IP来限流。
    		//return exchange -> Mono.just(exchange.getRequest().getRemoteAddress().getHostName());
    		return new KeyResolver() {
    
    			@Override
    			public Mono<String> resolve(ServerWebExchange exchange) {
    				//获取访问者的ip地址, 通过访问者ip地址进行限流, 限流使用的是Redis中的令牌桶算法
    				String hostName = exchange.getRequest().getRemoteAddress().getHostName();
    				return Mono.just(hostName);
    			}
    		};
    	}

           这里是根据IP地址限流。‘

    配置文件配置限流过滤器

    server:
      port: 8220
    spring:
      application:
        name: gateway-consul
      cloud:
        gateway:
          routes:
            - id: hello
              uri: lb://service-provider/hello/
              predicates:
                - Path=/hello
                - Method=GET
              filters:
                - AddRequestParameter=name,songyunhui
                - name: RequestRateLimiter # 限流过滤器使用gateway内置令牌算法
                  args:
                    redis-rate-limiter:
                      replenishRate: 1 #令牌补充的频率,每次就一个
                      burstCapacity: 2 #令牌桶的最大容量,允许在一秒钟内完成的最大请求数
                    key-resolver: "#{@ipKeyResolver}"
          discovery:
            locator:
              enabled: true #是否与服务中心的发现组件进行整合
        consul:
          host: 10.1.12.22
          port: 8500
          discovery:
            instance-id: ${spring.application.name}:${server.port}
    
      redis:
        host: redis服务器地址
        port: 6379
        database: 1
    
      level:
        ROOT: INFO
    feign:
      circuitbreaker:
        enabled: true #开启Hystrix
    #默认为true
    management:
      endpoint:
        gateway:
          enabled: true
      endpoints:
        web:
          exposure:
            include: gateway

           这里默认使用Spring Cloud Gateway内置的令牌桶算法。

    测试

          使用Jmeter,起10个线程,一秒钟并发请求,结果如下:

    从响应结果中可以看出限流成功:

    HTTP/1.1 429 Too Many Requests
    X-RateLimit-Remaining: 0
    X-RateLimit-Requested-Tokens: 1
    X-RateLimit-Burst-Capacity: 2
    X-RateLimit-Replenish-Rate: 1
    content-length: 

    端点

         依赖

           Spring Cloud Gateway的端点被纳入Spring Boot Actuator中了,所以需要引用Actuator的依赖:

    		<dependency>
    			<groupId>org.springframework.boot</groupId>
    			<artifactId>spring-boot-starter-actuator</artifactId>
    		</dependency>

         配置文件开启端点支持

    management:
      endpoint:
        gateway:
          enabled: true
      endpoints:
        web:
          exposure:
            include: gateway

         添加动态路由

           开启端点支持后,要想动态添加路由配置,只需发送POST请求即可。比如,想添加一条这样的路由:

           路由路径:http://localhost:8220/actuator/gateway/routes/hello3

           路由ID:hello3

           使用Postman,往http://localhost:8220/actuator/gateway/refresh发送以下POST请求:

    {
    	"id": "hello3 ",
    	"predicates": [{
    		"name": "Path",
    		"args": {
    			"_genkey_0": "/hello3/**"
    		}
    	}],
    	"filters": [],
    	"uri": "http://www.baidu.com",
    	"order": 0
    }

     发送成功之后,访问http://localhost:8220/actuator/gateway/routes/hello3

    展开全文
  • 微服务容错限流Hystrix架构和实践 1、容错限流的需求 微服务化后,存在多个服务,若果其中某一个服务响应很慢,阻塞了所有的请求,导致系统雪崩 2、基本的容错模式 超时 限流:限制最大并发数 熔断:错误达到阈值...

    微服务容错限流Hystrix架构和实践

    1、容错限流的需求

    • 微服务化后,存在多个服务,若果其中某一个服务响应很慢,阻塞了所有的请求,导致系统雪崩

    2、基本的容错模式

    • 超时
    • 限流:限制最大并发数
    • 熔断:错误达到阈值时,类似保险丝熔断
    • 隔离:隔离不同的依赖调用
    • 降级:服务降级(大量用户请求进入时候,优先保证vip用户请求)

    3、Hystrix设计原理(自适应反馈机制)

    在这里插入图片描述

    • 依赖的调用使用了Hystrix后,首先会被封装在一个HystrixCommond的类里。

    • execute同步执行方式,queue一步执行方式,最新的版本支持响应式执行。

    • circult open开关不通,不同的时候判断是否存在降级函数,没有降级函数直接抛出异常

      有降级函数就执行,存在执行成功(返回降级响应),执行失败抛出异常

    • circult open开关通,如果用的是线程隔离,去判断线程池是否满,如果满了是走降级流程

    • 线程池如果没满,就真正的执行run方法,调用封装方法,超时或执行失败也是走降级流程,

      如果成功响应,就是report Metrics,就是把执行情况做一个记录

    • Metrics会把成功或失败的情况报告给Health组件,health组件相当于一个脑袋,他会计算Hystrix的执行情况,用来判定开关是打开还是闭合

    4、断路器内核设计

    在这里插入图片描述

    • 基于滚筒式的统计方式,每一秒产生一个桶,每个桶里记录相关的Metrics的成功或失败,

      没过一秒产生一个通,前面的桶丢弃,所有的计算都是基于这10个桶

    • 当HystricsCommond请求过来的时候,首先判断是否允许请求通过,允许通过的话就直接执行

    • 不允许通过的时候,会判断sleep time passed(睡眠周期)是否已过,熔断之后会有一个睡眠周期,如果没过睡眠周期,拒绝访问,如果过会放一个请求过来尝试,试通了电路就会打开

    • 判断是否打开时,计算失败数/(成功数+失败数),大于设定的错误阈值时,会触发熔断(根据10个桶的值计算)

    5、Hystrix的主要概念

    • HystrixCommond

    在这里插入图片描述

    业务逻辑实现要集成HystrixCommond基类,业务逻辑写在run方法里

    • Fail fast 快速失败:run方法里直接抛异常

    在这里插入图片描述

    • Fail silent 安静失败:getFailBack降级函数里,放回一个null或空值

      在这里插入图片描述

    • Static fallback:也是降级函数返回一个缺省值,true或缺省对象
      在这里插入图片描述

    • fallback via network 通过防落进行降级,主服务失败了,降价方法里调用一个辅助服务,通过缓存之类的

    在这里插入图片描述

    • primary+secondary with fall back(主次降级机制)

    在这里插入图片描述
    就是一个功能有一个老版本,一个新版本,都放在开关后边,用那个开那个

    6、Hystrix请求合并

    • 很多小请求过来的时候,会做一个请求Batch合并,例如把 10毫秒的请求合并打包发给服务器,

      响应成功后拆解响应给用户

    7、Hystirx请求缓存

    8、Hystrix隔离机制

    8.1、线程隔离

    • 为每个调用的服务建立单独的线程池,每次调用都发生在单独的线程里,通过线程池里的线程去调用服务,线程池里可以设置线程数量,比如设置10个线程,线程数量消耗光了,就不能再调用了

    8.2、信号量隔离

    • 信号量隔离,简单来讲就是一个计数器,比如设置为10个信号量,进来一个请求会消耗一个信号量,请求结束将信号量还回去,10的信号量消耗完了,就不能再请求了

    8.3 信号量隔离 vs 线程隔离

    • 信号量隔离

      优点:轻量,无额外开销

      不足: 不支持任务排队和主动超时,不支持一步调用

      适用:守信客户(自己开发的服务)、高扇出(网关上使用)、高频高速调用(调用缓存cache)

    • 线程隔离

      优点:支持排队和超时,支持异步调用

      不足:线程调用会产生额外的开销

      使用:不受信的客户、有限的扇出

    9、Hystrix主要配置项

    在这里插入图片描述
    maxQueueSize:为 -1的时候表示是同步队列

    展开全文
  • 为什么需要容错限流 服务依赖 :服务扇出 单个服务延迟:所有请求都阻塞在某个服务上 容错限流的原理 超时:主动超时 限流:限制最大流量 熔断:当错误达到阀值时类似于保险丝的熔断 隔离:隔离不同的依赖调用 服务...

    为什么需要容错限流
    服务依赖 :服务扇出
    单个服务延迟:所有请求都阻塞在某个服务上
    容错限流的原理
    超时:主动超时
    限流:限制最大流量
    熔断:当错误达到阀值时类似于保险丝的熔断
    隔离:隔离不同的依赖调用
    服务降级
    断路器模式
    在这里插入图片描述
    舱壁隔离模式
    1 凡是依赖都有可能失败
    2 凡是资源都有限制
    3 网络并不可靠
    4 延迟是应用稳定性的杀手,延迟会占用大量的资源,比如内存等
    Hystrix原理
    Hystrix自适应工作流程
    在这里插入图片描述
    断路器
    在这里插入图片描述
    基于以秒为单位的滚筒,如果处于断路状态,或者睡眠时间未到达则拒绝请求,否则放入一个请求,并通过滚筒计算失败率,如果失败率超过阀值则关闭电路
    Hystrix的主要概念
    Hystrix command 自己的业务逻辑继承 Hystrix command
    快速失败
    安静失败 失败的时候返回空值
    static fallback 返回默认值
    Fallback via Network 调用辅助服务
    Primary secondary with fallback 先尝试老功能,新功能没问题再尝试新功能
    请求合并 把一段时间内的请求合并发送
    请求缓存 对请求进行缓存
    Hystrix 信号量和线程池隔离
    线程池隔离:为每一个依赖的服务单独建立一个线程池
    支持排队,主动超时,支持异步调用
    适用于不授信客户,适用于非高扇出场景
    信号量隔离:为每一个依赖的服务建立信号量
    适合 授信服务,高扇出场景
    Hystrix 的主要配置项
    在这里插入图片描述
    隔离策略
    间隔窗口
    最小流量阀值
    最小错误阀值
    补充:服务熔断和服务降级
    服务熔断
    向调用方返回一个符合预期的,可处理的备选响应,而不是长时间的等待或者抛出调用方无法处理的异常。当某个异常条件被触发,直接熔断整个服务,而不是一直等到此服务超时。
    缺点:方法膨胀;处理异常的方法跟业务方法耦合在了一起
    服务降级
    服务降级是在客户端完成的,与服务端没有关系。一般是从整体负荷考虑,当某个服务熔断以后,服务器将不再被调用,此时客户端可以自己准备一个本地的fallback回调,返回一个缺省值,这样做虽然服务水平下降,但是还是能保证可用性的。

    展开全文
  • 使用容错限流的原因 使用微服务架构时由于服务间依赖严重并且复杂,如果某个被频繁调用的单个系统出现相应延迟,用户在不明原因的情况下拿不到返回值,便会不断的重试,导致本来已经不堪重负的服务器被最后一根...
  • 容错限流学习笔记

    2020-05-17 10:33:10
    限流:限制最大并发数, 熔断:错误数达到阀值时,类似保险丝熔断 隔离:隔离不同的依赖调用,资源是有限的,如果不隔离可能由于某服务延迟,把资源都耗尽,采用隔离只会影响出问题的服务不会影响其他服务。 降级:...
  • 九:对微服务限流容错的理解

    千次阅读 2018-08-01 14:39:07
    从以下几个方面理解微服务的限流容错 2. 为什么需要限流容错机制 3. 微服务的限流容错相关概念有哪些 3.1 雪崩效应 3.2 容错机制 3.3 限流机制 3.4 降级机制 4. 通过Hystrix来理解限流容错框架 4.1 Hystrix是什么 ...
  • 限流,熔断,降级 限流: 通过线程池实现:当线程池满,后面的请求会直接 fallback 通过信号量实现:不阻塞线程,但资料不隔离 熔断: 前几次请求都失败,则认为下一次大概率失败,就直接失败,这样可以防止错误和...
  • 那么可以直接降级,降级的方案比 如设置默认值、采用兜底数据(系统推荐的行为广告挂 了,可以提前准备静态页面做返回)等等 限流降级,在秒杀这种流量比较集中并且流量特别大的 情况下,因为突发访问量特别大可能...
  • 限流 在高峰时,限制客户端连接的数量,一般在服务端进行。 常见的策略有: 1,令牌桶法 固定频率在桶中生成令牌,来一个客户端发放一个令牌,令牌发完了就等待或者拒绝 springcloud实现:zuul网关,gateway ...
  • management: endpoints: web: exposure: include: '*'
  • Integer res = new QueryUserIdCommand(userServiceProvider).execute(); log.info("result:{}", res);
  • 微服务框架集成了限流容错组件,能够在运行时自动限流容错,保护服务,如果进一步和动态配置相结合,还可以实现动态熔断、服务降级、限流限流 C ⇄ S 的异常问题:C 的请求太多,超出 S 的服务能力,导致 S 不...
  • dubbo服务降级与限流

    2020-11-19 22:25:40
    作为RPC框架,dubbo在调用过程中不可避免的会出现各种异常问题,在使用springcloud进行微服务治理时,会接触到hystrix,sentinel等服务限流降级框架,同样对于dubbo来说,使用过程中也需要考虑这方面的问题 ...
  • Netflix宣布停止开发Hystrix,建议使用Resilience4j,Resilience4j到底是什么鬼?Resilience4j最新版本为0.13.2,无论是案例还是... 实际上Resilience4j的灵感来自于Hystrix,同样是轻量级的分布式容错方法库,比H...
  • 微服务接口限流设计与思考

    千次阅读 2018-09-25 10:03:59
    服务治理本身的概念比较大,包括鉴权、限流、降级、熔断、监控告警等等,本文聚焦于... 如何打造高度容错、高 TPS、低延迟的限流框架? 微服务架构中没有接口限流,可能会遇到哪些问题? 针对微服务接口限...
  • 微服务接口限流的设计、思考

    千次阅读 2018-11-29 10:13:59
    服务治理本身的概念比较大,包括鉴权、限流、降级、熔断、监控告警等等,本文聚焦于限流,根据笔者的实战经验,分享一些对微服务接口限流的思考。 本文试图讲清楚以下问题,如果您对限流也有类似的疑问或对某一话题...
  • hystrix接口限流

    2019-04-20 09:02:23
    Hystrix是Netflix开源的一款容错框架,包含常用的容错方法:线程隔离、信号量隔离、降级策略、熔断技术。 在高并发访问下,系统所依赖的服务的稳定性对系统的影响非常大,依赖有很多不可控的因素,比如网络连接变慢...
  • 上一章讲了常见的限流算法,本章我们来看看,Spring Cloud中的Hystrix组件在对请求进行熔断、限流与服务保护操作时的算法实践。 一、雪崩 分布式系统环境下,服务间依赖非常常见,一个业务调用通常依赖多个基础...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 37,813
精华内容 15,125
热门标签
关键字:

容错限流