Spring Cloud 的 Hystrix.功能及实践详解

一、概述

在微服务架构中,我们将系统拆分成了很多服务单元,各单元的应用间通过服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行,依赖通过远程调用的方式执行,这样就有可能因为网络原因或是依赖服务自身间题出现调用故障或延迟,而这些问题会直接导致调用方的对外服务也出现延迟,若此时调用方的请求不断增加,最后就会因等待出现故障的依赖方响应形成任务积压,最终导致自身服务的瘫痪。

所以我们引入了断路器,类似于物理上的电路,当电流过载时,就断开电路,就是我们俗称的“跳闸”。同理,服务间的调用也是如此,当不断的出现服务延迟、故障等影响到系统性能的调用,就把这个服务调用切断!

Spring Cloud Hystrix 实现了断路器、线程隔离等一系列服务保护功能。它也是基于 Netflix 的开源框架 Hystrix 实现的,该框架的目标在于通过控制那些访问远程系统、服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。Hystrix 具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能。

二、Hystrix 工作流程

1.创建 HystrixCommand(用在依赖的服务返回单个操作结果的时候) 或 HystrixObserableCommand(用在依赖的服务返回多个操作结果的时候) 对象。

2.命令执行。其中 HystrixComand 实现了下面前两种执行方式;而 HystrixObservableCommand 实现了后两种执行方式:

  • execute():同步执行,从依赖的服务返回一个单一的结果对象, 或是在发生错误的时候抛出异常。
  • queue():异步执行, 直接返回 一个Future对象, 其中包含了服务执行结束时要返回的单一结果对象。
  • observe():返回 Observable 对象,它代表了操作的多个结果,它是一个 Hot Obserable(不论 "事件源" 是否有 "订阅者",都会在创建后对事件进行发布,所以对于 Hot Observable 的每一个 "订阅者" 都有可能是从 "事件源" 的中途开始的,并可能只是看到了整个操作的局部过程)。
  • toObservable(): 同样会返回 Observable 对象,也代表了操作的多个结果,但它返回的是一个Cold Observable(没有 "订阅者" 的时候并不会发布事件,而是进行等待,直到有 "订阅者" 之后才发布事件,所以对于 Cold Observable 的订阅者,它可以保证从一开始看到整个操作的全部过程)。

3.若当前命令的请求缓存功能是被启用的, 并且该命令缓存命中, 那么缓存的结果会立即以 Observable 对象的形式 返回。

4.检查断路器是否为打开状态。如果断路器是打开的,那么Hystrix不会执行命令,而是转接到 fallback 处理逻辑(第 8 步);如果断路器是关闭的,检查是否有可用资源来执行命令(第 5 步)。

5.线程池/请求队列/信号量是否占满。如果命令依赖服务的专有线程池和请求队列,或者信号量(不使用线程池的时候)已经被占满, 那么 Hystrix 也不会执行命令, 而是转接到 fallback 处理逻辑(第8步)。
6.Hystrix 会根据我们编写的方法来决定采取什么样的方式去请求依赖服务。

  • HystrixCommand.run() :返回一个单一的结果,或者抛出异常。
  • HystrixObservableCommand.construct(): 返回一个Observable 对象来发射多个结果,或通过 onError 发送错误通知。

7.Hystrix会将 "成功"、"失败"、"拒绝"、"超时" 等信息报告给断路器, 而断路器会维护一组计数器来统计这些数据。断路器会使用这些统计数据来决定是否要将断路器打开,来对某个依赖服务的请求进行 "熔断/短路"。

8.当命令执行失败的时候, Hystrix 会进入 fallback 尝试回退处理, 我们通常也称该操作为 "服务降级"。而能够引起服务降级处理的情况有下面几种:

  • 第4步: 当前命令处于"熔断/短路"状态,断路器是打开的时候。
  • 第5步: 当前命令的线程池、 请求队列或 者信号量被占满的时候。
  • 第6步:HystrixObservableCommand.construct() 或 HystrixCommand.run() 抛出异常的时候。

9.当Hystrix命令执行成功之后, 它会将处理结果直接返回或是以Observable 的形式返回。

tips:如果我们没有为命令实现降级逻辑或者在降级处理逻辑中抛出了异常, Hystrix 依然会返回一个 Observable 对象, 但是它不会发射任何结果数据, 而是通过 onError 方法通知命令立即中断请求,并通过onError()方法将引起命令失败的异常发送给调用者。

三、Hystrix 熔断保护机制

1.假设大量的请求数量超过了 HystrixCommandProperties.circuitBreakerRequestVolumeThreshold() 的阈值,熔断器将会从关闭状态变成打开状态;

2.假设依赖调用失败的百分比超过了 HystrixCommandProperties.circuitBreakerErrorThresholdPercentage() 的阈值,熔断器将会从关闭状态变成打开状态;

3.在熔断器处于打开状态的期间,所有对这个依赖进行的调用都会短路,即不进行真正的依赖调用,返回失败;
在等待(冷却)的时间超过 HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds() 的值后,熔断器将处于半开的状态,将允许单个请求去调用依赖,如果这次的依赖调用还是失败,熔断器状态将再次变成打开,这个打开状态持续时间是

4.HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds() 配置的值;如果这次的依赖调用成功,熔断器状态将变成关闭,后续依赖调用可正常执行。

四、Hystrix 依赖隔离机制

线程池隔离

Hystrix 则使用“舱壁模式”实现线程池的隔离,它会为每一个依赖服务创建 一个独立的线程池,这样就算某个依赖服务出现延迟过高的情况,也只是对该依赖服务的调用产生影响,而不会拖慢其他的依赖服务。缺点是涉及到线程切换的性能损耗,但是官方给出的结果是性能损耗是可以接受的。

信号量隔离

信号量隔离可实现对依赖调用最高并发请求数的限制,每次依赖调用都会先判断信号量是否达到阈值,如果达到极限值则拒绝调用。信号量的开销远比线程池的开销小,但是它不能设置超时和实现异步访问。所以,只有在依赖服务是足够可靠的情况下才使用信号量 。以下是两种配置信号量隔离的方式:

Setter 方式

HystrixCommand.Setter setter = HystrixCommand.Setter
.withGroupKey(HystrixCommandGroupKey.Factory.asKey("strGroupCommand"))
.andCommandKey(HystrixCommandKey.Factory.asKey("strCommand"))
.andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("strThreadPool"));
// 配置信号量隔离
HystrixCommandProperties.Setter commandPropertiesSetter = HystrixCommandProperties.Setter().withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.SEMAPHORE);
setter.andCommandPropertiesDefaults(commandPropertiesSetter);

注解方式

@HystrixCommand(fallbackMethod = "fallbackMethod",
commandProperties = {
// 设置隔离策略,THREAD 表示线程池 SEMAPHORE:信号池隔离
@HystrixProperty(name = "execution.isolation.strategy", value = "THREAD"),
// 当隔离策略选择信号池隔离的时候,用来设置信号池的大小(最大并发数)
@HystrixProperty(name = "execution.isolation.semaphore.maxConcurrentRequests", value = "10"),
}
)

五、hystrix 实战

SpringBoot 版本号:2.1.6.RELEASE
SpringCloud 版本号:Greenwich.RELEASE

1. pom.xml

    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
    </dependency>

2. 在 SpringBoot 的启动类上引入 @EnableCircuitBreaker 注解,开启断路器功能。

3. 上面 hystrix 工作原理中提到断路器有四种执行方式:

execute() - 同步执行

  @HystrixCommand(fallbackMethod = "fallbackMethod")
  public String strConsumer() {
    ResponseEntity<String> result = restTemplate.getForEntity("http://cloud-eureka-client/hello", String.class);
    return result.getBody();
  }

fallbackMethod —— 回调方法,在服务调用异常、断路器打开、线程池/请求队列/信号量占满时会走回调逻辑。必须和服务方法定义在同一个类中,对修饰符没有特定的要求,定义为 private、 protected、 public 均可。

queue() - 异步执行

  @HystrixCommand(fallbackMethod = "fallbackMethod", ignoreExceptions = {IllegalAccessException.class})
  public Future<String> asyncStrConsumer() {

    Future<String> asyncResult = new AsyncResult<String>() {
      @Override
      public String invoke() {
        ResponseEntity<String> result = restTemplate.getForEntity("http://cloud-eureka-client/hello", String.class);
        return result.getBody();
      }
    };
    return asyncResult;
  }

ignoreExceptions 表示抛出该异常时不走降级回调逻辑,忽略此异常。

observe () 执行方式

  @HystrixCommand(observableExecutionMode = ObservableExecutionMode.EAGER)
  protected Observable<String> construct() {
    ResponseEntity<String> result = restTemplate.getForEntity("http://cloud-eureka-client/hello", String.class);
    return Observable.just(result.getBody());
  }

toObservable() 执行方式

  @HystrixCommand(observableExecutionMode = ObservableExecutionMode.LAZY)
  protected Observable<String> construct() {
    ResponseEntity<String> result = restTemplate.getForEntity("http://cloud-eureka-client/hello", String.class);
    return Observable.just(result.getBody());
  }

4. 命令名称、分组以及线程池划分

Hystrix 会根据组来组织和统计命令的告警、仪表盘等信息。

默认情况下,Hystrix 会让相同组名的命令使用同一个线程池。

通常情况下,尽量通过 HystrixThreadPoolKey 的方式来指定线程池的划分,而不是通过组名的默认方式实现划分,因为多个不同的命令可能从业务逻辑上来看属于同一个组,但是往往从实现本身上需要跟其他命令进行隔离。

  @HystrixCommand(fallbackMethod = "fallbackMethod", groupKey = "strGroupCommand", commandKey = "strCommand", threadPoolKey = "strThreadPool")
  public String strConsumer(@CacheKey Long id) {
    ResponseEntity<String> result = restTemplate.getForEntity("http://cloud-eureka-client/hello", String.class);
    return result.getBody();
  }

groupKey 默认是类名,commandKey 默认是方法名 ,threadPoolKey 默认和 groupKey 一致。

5. 请求缓存和请求合并

5.1 请求缓存

缓存的作用和好处,真的是无需多言了。请求缓存,顾名思义,就是将对同一个 key 的请求结果,缓存下来。那么下次对这个 key 的请求,数据就直接在缓存中返回,减少响应时间;

在 Hystrix 中使用缓存,主要是三个注解:@CacheResult、@CacheKey、@CacheRemove

  • @CacheResult:用来标记请求结果应该被缓存,必须与 @HystrixCommand 一起使用。
  • @CacheKey:用来修饰方法参数,表示缓存的 key 名,优先级高于 @CacheResult 设置的 key 名。
  • @CacheRemove:当数据更新的时候,为了数据的一致性,我们需要使缓存失效。@CacheRemove 就是用来标记请求结果的缓存失效(commandKey 是必填参数,表示要失效的缓存 key)。
  @CacheResult(cacheKeyMethod = "getCacheKey")
  @HystrixCommand(fallbackMethod = "fallbackMethod")
  public String strConsumer(@CacheKey Long id) {
    ResponseEntity<String> result = restTemplate.getForEntity("http://cloud-eureka-client/hello", String.class);
    return result.getBody();
  }

5.2 请求合并

微服务架构中的依赖通常通过远程调用实现,而远程调用中最常见的问题就是通信消耗与连接数占用。

在高并发的情况之下,因通信次数的增加,总的通信时间消耗将会变得不那么理想。同时,因为依赖服务的线程池资源有限,将出现排队等待与响应延迟的清况。为了优化这两个问题,Hystrix 提供了 HystrixCollapser 来实现请求的合并,以减少通信消耗和线程数的占用。

@RestController
public class UserConsumer {

  @Autowired
  private UserService userService;

  /**
   * 通过 id 获取用户接口
   *
   * @param id
   * @return
   */
  @HystrixCollapser(batchMethod = "getByIds", collapserProperties = {
      // 10ms 内的请求合并为一次批量请求
      @HystrixProperty(name = "timerDelayInMilliseconds", value = "10"),
      // 批处理过程中是否开启缓存
      @HystrixProperty(name = "requestCache.enabled", value = "10"),
  })
  public String getById(Long id) {
    return userService.getUserById(id);
  }

  /**
   * 通过 ids 批量获取用户信息接口
   *
   * @param ids id 集合
   * @return
   */
  @HystrixCommand
  public Set<String> getByIds(List<Long> ids) {
    return userService.getUserByIds(ids);
  }
}

虽然通过请求合并可以减少请求的数量以缓解依赖服务线程池的资源,但是在使用的时候也需要注意它所带来的额外开销:用于请求合并的延迟时间窗会使得依赖服务的请求延迟增高。

是否开启缓存合并,我们一般考虑下面两个因素:

  • 如果依赖服务的请求命令本身是一个高延迟的命令,那么可以使用请求合并器,因为高延迟,时间窗的时间消耗显得微不足道了。
  • 如果一个时间窗内只有1-2个请求,那么这样的依赖服务不适合使用请求合并器。这种情况不但不能提升系统性能,反而会成为系统瓶颈;相反,如果一个时间窗内具有很高的并发量,并且服务提供方也实现了批量处理接口,那么使用请求合并器可以有效减少网络连接数量并极大提升系统吞吐量。

6. HystrixCommand 属性介绍

  @HystrixCommand(fallbackMethod = "fallbackMethod", groupKey = "strGroupCommand", commandKey = "strCommand", threadPoolKey = "strThreadPool",
      commandProperties = {
          // 设置隔离策略,THREAD 表示线程池 SEMAPHORE:信号池隔离
          @HystrixProperty(name = "execution.isolation.strategy", value = "THREAD"),
          // 当隔离策略选择信号池隔离的时候,用来设置信号池的大小(最大并发数)
          @HystrixProperty(name = "execution.isolation.semaphore.maxConcurrentRequests", value = "10"),
          // 配置命令执行的超时时间
          @HystrixProperty(name = "execution.isolation.thread.timeoutinMilliseconds", value = "10"),
          // 是否启用超时时间
          @HystrixProperty(name = "execution.timeout.enabled", value = "true"),
          // 执行超时的时候是否中断
          @HystrixProperty(name = "execution.isolation.thread.interruptOnTimeout", value = "true"),
          // 执行被取消的时候是否中断
          @HystrixProperty(name = "execution.isolation.thread.interruptOnCancel", value = "true"),

          // 允许回调方法执行的最大并发数
          @HystrixProperty(name = "fallback.isolation.semaphore.maxConcurrentRequests", value = "10"),
          // 服务降级是否启用,是否执行回调函数
          @HystrixProperty(name = "fallback.enabled", value = "true"),

          // 是否启用断路器
          @HystrixProperty(name = "circuitBreaker.enabled", value = "true"),
          // 该属性用来设置在滚动时间窗中,断路器熔断的最小请求数。例如,默认该值为 20 的时候,如果滚动时间窗(默认10秒)内仅收到了19个请求, 即使这19个请求都失败了,断路器也不会打开。
          @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "20"),
          // 该属性用来设置在滚动时间窗中,表示在滚动时间窗中,在请求数量超过 circuitBreaker.requestVolumeThreshold 的情况下,如果错误请求数的百分比超过50, 就把断路器设置为 "打开" 状态,否则就设置为 "关闭" 状态。
          @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "50"),
          // 该属性用来设置当断路器打开之后的休眠时间窗。 休眠时间窗结束之后,会将断路器置为 "半开" 状态,尝试熔断的请求命令,如果依然失败就将断路器继续设置为 "打开" 状态,如果成功就设置为 "关闭" 状态。
          @HystrixProperty(name = "circuitBreaker.sleepWindowinMilliseconds", value = "5000"),
          // 断路器强制打开
          @HystrixProperty(name = "circuitBreaker.forceOpen", value = "false"),
          // 断路器强制关闭
          @HystrixProperty(name = "circuitBreaker.forceClosed", value = "false"),

          // 滚动时间窗设置,该时间用于断路器判断健康度时需要收集信息的持续时间
          @HystrixProperty(name = "metrics.rollingStats.timeinMilliseconds", value = "10000"),
          // 该属性用来设置滚动时间窗统计指标信息时划分"桶"的数量,断路器在收集指标信息的时候会根据设置的时间窗长度拆分成多个 "桶" 来累计各度量值,每个"桶"记录了一段时间内的采集指标。
          // 比如 10 秒内拆分成 10 个"桶"收集这样,所以 timeinMilliseconds 必须能被 numBuckets 整除。否则会抛异常
          @HystrixProperty(name = "metrics.rollingStats.numBuckets", value = "10"),
          // 该属性用来设置对命令执行的延迟是否使用百分位数来跟踪和计算。如果设置为 false, 那么所有的概要统计都将返回 -1。
          @HystrixProperty(name = "metrics.rollingPercentile.enabled", value = "false"),
          // 该属性用来设置百分位统计的滚动窗口的持续时间,单位为毫秒。
          @HystrixProperty(name = "metrics.rollingPercentile.timeInMilliseconds", value = "60000"),
          // 该属性用来设置百分位统计滚动窗口中使用 “ 桶 ”的数量。
          @HystrixProperty(name = "metrics.rollingPercentile.numBuckets", value = "60000"),
          // 该属性用来设置在执行过程中每个 “桶” 中保留的最大执行次数。如果在滚动时间窗内发生超过该设定值的执行次数,
          // 就从最初的位置开始重写。例如,将该值设置为100, 滚动窗口为10秒,若在10秒内一个 “桶 ”中发生了500次执行,
          // 那么该 “桶” 中只保留 最后的100次执行的统计。另外,增加该值的大小将会增加内存量的消耗,并增加排序百分位数所需的计算时间。
          @HystrixProperty(name = "metrics.rollingPercentile.bucketSize", value = "100"),
          // 该属性用来设置采集影响断路器状态的健康快照(请求的成功、 错误百分比)的间隔等待时间。
          @HystrixProperty(name = "metrics.healthSnapshot.intervalinMilliseconds", value = "500"),

          // 是否开启请求缓存
          @HystrixProperty(name = "requestCache.enabled", value = "true"),
          // HystrixCommand的执行和事件是否打印日志到 HystrixRequestLog 中
          @HystrixProperty(name = "requestLog.enabled", value = "true"),

      },
      threadPoolProperties = {
          // 该参数用来设置执行命令线程池的核心线程数,该值也就是命令执行的最大并发量
          @HystrixProperty(name = "coreSize", value = "10"),
          // 该参数用来设置线程池的最大队列大小。当设置为 -1 时,线程池将使用 SynchronousQueue 实现的队列,否则将使用 LinkedBlockingQueue 实现的队列。
          @HystrixProperty(name = "maxQueueSize", value = "-1"),
          // 该参数用来为队列设置拒绝阈值。 通过该参数, 即使队列没有达到最大值也能拒绝请求。
          // 该参数主要是对 LinkedBlockingQueue 队列的补充,因为 LinkedBlockingQueue 队列不能动态修改它的对象大小,而通过该属性就可以调整拒绝请求的队列大小了。
          @HystrixProperty(name = "queueSizeRejectionThreshold", value = "5"),
      }
  )
  public String strConsumer() {
    ResponseEntity<String> result = restTemplate.getForEntity("http://cloud-eureka-client/hello", String.class);
    return result.getBody();
  }

演示源代码 :https://github.com/JMCuixy/spring-cloud-demo

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • SpringBoot2.0整合SpringCloud Finchley @hystrixcommand注解找不到解决方案

    hystrix参数使用方法 通过注解@HystrixCommand的commandProperties去配置, 如下就是hystrix命令超时时间命令执行超时时间,为1000ms和执行是不启用超时 @RestController public class MovieController { @Autowired private RestTemplate restTemplate; @GetMapping("/movie/{id}") @HystrixCommand(commandPro

  • springcloud使用Hystrix进行微服务降级管理

    前言:目前我们的项目是微服务架构,基于dubbo框架,服务之间的调用是通过rpc调用的.刚开始没有任何问题,项目运行健康.良好.可是过了一段时间,线上总有人反应查询订单失败,等过了一段时间才能查到.这是怎么回事呢?打开后台的日志一看出现了一些RpcException和TimeOutException,原来是远程调用超时了,可能某个服务在请求的高发期访问数据库异常,IO阻塞,返回接口异常了.后来这个问题越来越频繁,如何解决这个棘手的问题呢? 一:Hystrix是什么? 1.1:基本解释 Hystr

  • SpringCloud中的断路器(Hystrix)和断路器监控(Dashboard)

    前言 本篇主要介绍的是SpringCloud中的断路器(Hystrix)和断路器指标看板(Dashboard)的相关使用知识. SpringCloud Hystrix Hystrix 介绍 Netflix创建了一个名为Hystrix的库,它实现了断路器模式.主要的目的是为了解决服务雪崩效应的一个组件,是保护服务高可用的最后一道防线. 开发准备 开发环境 •JDK:1.8 •SpringBoot:2.1.1.RELEASE •SpringCloud:Finchley 注:不一定非要用上述的版本,可

  • 详解springcloud 基于feign的服务接口的统一hystrix降级处理

    springcloud开发微服务时,基于feign来做声明式服务接口,当启用hystrix服务熔断降级时,项目服务众多,每个Feign服务接口都得写一些重复问的服务降级处理代码,势必显得枯燥无味: Feign服务接口: @FeignClient(name="springcloud-nacos-producer", qualifier="productApiService", contextId="productApiService", fallb

  • SpringCloud Zuul在何种情况下使用Hystrix及问题小结

    首先,引入spring-cloud-starter-zuul之后会间接引入: hystrix依赖已经引入,那么何种情况下使用hystrix呢? 在Zuul的自动配置类ZuulServerAutoConfiguration和ZuulProxyAutoConfiguration中总共会向Spring容器注入3个Zuul的RouteFilter,分别是 •SimpleHostRoutingFilter 简单路由,通过HttpClient向预定的URL发送请求 生效条件: RequestContext.

  • springboot2.0和springcloud Finchley版项目搭建(包含eureka,gateWay,Freign,Hystrix)

    前段时间spring boot 2.0发布了,与之对应的spring cloud Finchley版本也随之而来了,两者之间的关系和版本对应详见我这边文章:spring boot和spring cloud对应的版本关系 项目地址:spring-cloud-demo spring boot 1.x和spring cloud Dalston和Edgware版本搭建的微服务项目现在已经很流行了,现在很多企业都已经在用了,这里就不多说了. 使用版本说明: spring boot 2.0.x spring

  • Spring Cloud 的 Hystrix.功能及实践详解

    一.概述 在微服务架构中,我们将系统拆分成了很多服务单元,各单元的应用间通过服务注册与订阅的方式互相依赖.由于每个单元都在不同的进程中运行,依赖通过远程调用的方式执行,这样就有可能因为网络原因或是依赖服务自身间题出现调用故障或延迟,而这些问题会直接导致调用方的对外服务也出现延迟,若此时调用方的请求不断增加,最后就会因等待出现故障的依赖方响应形成任务积压,最终导致自身服务的瘫痪. 所以我们引入了断路器,类似于物理上的电路,当电流过载时,就断开电路,就是我们俗称的"跳闸".同理,服务间的调

  • Spring Cloud Gateway动态路由Apollo实现详解

    目录 背景 路由的加载 实现动态路由 背景 在之前我们了解的Spring Cloud Gateway配置路由方式有两种方式 通过配置文件 spring: cloud: gateway: routes: - id: test predicates: - Path=/ms/test/* filters: - StripPrefix=2 uri: http://localhost:9000 通过JavaBean @Bean public RouteLocator routeLocator(RouteL

  • Spring cloud Feign 深度学习与应用详解

    简介 Spring Cloud Feign是一个声明式的Web Service客户端,它的目的就是让Web Service调用更加简单.Feign提供了HTTP请求的模板,通过编写简单的接口和插入注解,就可以定义好HTTP请求的参数.格式.地址等信息.Feign会完全代理HTTP请求,开发时只需要像调用方法一样调用它就可以完成服务请求及相关处理.开源地址:https://github.com/OpenFeign/feign.Feign整合了Ribbon负载和Hystrix熔断,可以不再需要显式地

  • Spring Cloud Gateway全局异常处理的方法详解

    前言 Spring Cloud Gateway是Spring官方基于Spring 5.0,Spring Boot 2.0和Project Reactor等技术开发的网关,Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式.Spring Cloud Gateway作为Spring Cloud生态系中的网关,目标是替代Netflix ZUUL,其不仅提供统一的路由方式,并且基于Filter链的方式提供了网关基本的功能,例如:安全,监控/埋点,和限流等

  • Spring Cloud 系列之注册中心 Eureka详解

    1.1 简介 1.1.1 概述   Netflix Eureka 是由 Netflix 开源的一款基于 REST 的服务发现组件,包括 Eureka Server 及 Eureka Client.2012 年 9 月在 GitHub 上发布 1.1.2 版本,目前 Netflix 以宣布闭源,所以市面上还是以 1.x 版本为主.Eureka 提供基于 REST 的服务,在集群中主要用于服务管理.Eureka 提供了基于 Java 语言的客户端组件,客户端组件实现了负载均衡的功能,为业务组件的集群

  • Spring Cloud GateWay 路由转发规则介绍详解

    Spring在因Netflix开源流产事件后,在不断的更换Netflix相关的组件,比如:Eureka.Zuul.Feign.Ribbon等,Zuul的替代产品就是SpringCloud Gateway,这是Spring团队研发的网关组件,可以实现限流.安全认证.支持长连接等新特性. Spring Cloud Gateway Spring Cloud Gateway是SpringCloud的全新子项目,该项目基于Spring5.x.SpringBoot2.x技术版本进行编写,意在提供简单方便.可

  • Java Spring Cloud Bus 实现配置实时更新详解

    目录 背景 实现原理 ConfigServer改造 1. pom.xml增加以下依赖 2. 配置文件中配置暴露接口 Service改造 1. pom.xml增加以下依赖 2. 通过@RefreshScope声明配置刷新时需要重新注入 测试 总结 背景 使用Spring Cloud Config Server,启动Service时会从配置中心取配置文件,并注入到应用中,如果在Service运行过程中想更新配置,需要使用Spring Cloud Bus配合实现实时更新. 实现原理 需要借助Rabbi

  • 详解spring cloud使用Hystrix实现单个方法的fallback

    本文介绍了spring cloud-使用Hystrix实现单个方法的fallback,分享给大家,具体如下: 一.加入Hystrix依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix</artifactId> </dependency> 二.编写Controller package c

  • spring cloud 使用Hystrix 实现断路器进行服务容错保护的方法

    在微服务中,我们将系统拆分为很多个服务单元,各单元之间通过服务注册和订阅消费的方式进行相互依赖.但是如果有一些服务出现问题了会怎么样? 比如说有三个服务(ABC),A调用B,B调用C.由于网络延迟或C本身代码有问题导致B迟迟得不到回应,这样B调用C的请求就会被挂起,等待. 在高并发的访问的情况下,这些挂起的线程得不到释放,使后续的请求阻塞,最终导致B也挂掉了.依次类推,A可能也会挂掉,进而使整个系统全部崩溃. 为了解决整个问题,Spring Cloud 使用Hystrix进行服务容错保护,包括断

  • Spring Boot实现登录验证码功能的案例详解

    目录 验证码的作用 案例要求 前端页面准备 准备login.html页面 随机验证码工具类 后端控制器 验证码的作用 验证码的作用:可以有效防止其他人对某一个特定的注册用户用特定的程序暴力破解方式进行不断的登录尝试我们其实很经常看到,登录一些网站其实是需要验证码的,比如牛客,QQ等.使用验证码是现在很多网站通行的一种方式,这个问题是由计算机生成并且评判的,但是必须只有人类才能解答,因为计算机无法解答验证码的问题,所以回答出问题的用户就可以被认为是人类.验证码一般用来防止批量注册. 案例要求 验证

随机推荐