springcloud 学习笔记

一、Hystrix 服务

服务雪崩

多个微服务之间调用的时候，假设服务A调用服务B和服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的扇出。如果扇出的链路上某个微服务的调用相应时间过程或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。

类似于下图

当库存服务不可用时，商品服务请求线程被阻塞，如果有大批量请求调用库存服务时，最终可能导致整个商品服务资源耗尽，无法对外提供服务，这种请求可能不饿可用沿着调用链向上传递，会引发了雪崩。

Hystrix 是什么？

Hystrix 是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix 能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性，是一款容错框架，具有自我保护的能力。

“断路器” 本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

HyStrix 设计目标：

• 阻止故障连锁反应
• 出现故障失败后能够迅速恢复正常
• 回退并且优雅的降级

Hystrix 可以干什么

1. 服务降级
2. 服务熔断
3. 接近实时的监控

重要概念

服务降级

降级，通常是指高峰期，为了保证核心业务能够正常运行，需要暂时停掉一些不太重要的业务；或者某些服务不可用时，执行备用逻辑从故障服务中快速失败或者快速返回（兜底的方法），以便保证主体业务不受影响。Hystrix 提供的降级主要是为了容错，保证当前服务不受依赖服务故障的影响，从而提高服务的健壮性。

服务器忙，请稍后再试，不让客户端等待并立刻返回一个友好提示，fallback

什么情况下会触发降级？

1. 程序运行异常
2. 超时
3. 服务熔断出发服务降级
4. 线程池/信号量打满也会导致服务降级

降低配置：@HystrixCommand

8001 先从自身找问题：设置自身调用超时时间的峰值，峰值内可以正常运行，超过了需要有兜底的方法处理，作服务降级 fallback

8001 fallback

1. 业务类启动

@HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler", commandProperties = {
    @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds", value = "3000")
  })
public String paymentInfo_TimeOut(Integer id) {
    int timeNumber = 5;
    try {
        TimeUnit.SECONDS.sleep(timeNumber);
    } catch (InterruptedException e){
        e.printStackTrace();
    }
    // int age = 10 / 0;
    return "线程池" + Thread.currentThread().getName() + " paymentInfo_TimeOut,id: " + id + "\t" + "😊😊😊, 耗时(s)" + timeNumber;
}

public String paymentInfo_TimeOutHandler(Integer id) {
    return "线程池" + Thread.currentThread().getName() + " paymentInfo_TimeOutHandler,id: " + id + "\t" + "🆒🆒🆒🆒";
}

上面代码中故意制造的两个异常

1. int age = 10 / 0；计算异常
2. 我们能接受 3 秒钟，它运行 5 秒钟，超时异常

当前服务不可用了，做服务降级，兜底的方案都是 paymentInfo_TimeOutHandler

80 fallback

1. 编写配置

feign:
  hystrix:
    enabled: true

1. 在主启动类上加 @EnableHystrix
2. 修改业务代码

@GetMapping("/consumer/payment/hystrix/timeout/{id}")
@HystrixCommand(fallbackMethod = "paymentTimeOutFallbackMethod", commandProperties = {
    @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500")
})
public String paymentInfo_TimeOut(@PathVariable("id") Integer id){
    return paymentHystrixService.paymentInfo_TimeOut(id);
}

public String paymentTimeOutFallbackMethod(@PathVariable("id") Integer id) {
    return "I'm consumer 80, side is busy, please again second";
}

存在的问题：

1. 每个业务对应一个兜底的方法，代码膨胀
2. 统一和自定义需要分开

解决问题t

1. 每个方法配置一个吗？？ 会出现代码膨胀的问题
   feign 接口系列
   @DefaultProperties(defaultFallback = “”)
   controller 配置

@DefaultProperties(defaultFallback = “”)

1:1 每个方法配置一个服务降级方法，技术上可以，但是比较笨

1:N 除了个别重要核心业务有专属，其他普通的可以通过 @DefaultProperties(defaultFallback = “”) 统一跳转到统一处理结果页面

通用的和独享的各自分开，避免了代码膨胀，合理减少了代码量

服务熔断

类比保险丝达到最大服务访问后，当负载过载时，直接拒绝访问，拉闸限电，然后调用服务降级的方法并返回友好提示，隔一段时间之后熔断器会尝试半开，放入一部分流量请求进来，相当于对依赖服务及进行一次健康检查，如果请求成功了，说明服务恢复到正常。

更加通俗的说就是保险丝：服务的降级 —> 进而熔断 —>恢复调用链路

熔断机制概述

熔断机制是对应雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务出错不可用或者时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。

当检测到该节点微服务调用响应正常后，恢复调用链路

在 Spring Cloud 框架里，熔断机制通过 Hystrix 实现。Hystrix 会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是 5 秒内 20 次调用失败，就会启动熔断机制。熔断机制的注解是 @HystrixCommand。

代码实现

service 层

@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_fallback", commandProperties = {
    @HystrixProperty(name = "circuitBreaker.enabled", value = "true"),// 是否开启断路器
    @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"), // 请求次数
    @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "10000"), // 时间窗口期
    @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "60") // 失败率达到多少后跳闸
})
public String paymentCircuitBreaker(@PathVariable("id") Integer id) {
    if (id < 0) {
        throw new RuntimeException("******id 不能为负数");
    }
    String serialNumber = IdUtil.simpleUUID();
    return Thread.currentThread().getName() + "\t" + "调用成功，流水号" + serialNumber;
}
public String paymentCircuitBreaker_fallback(@PathVariable("id") Integer id) {
    return "id 不能为负数，请稍后再试 id: " + id;
}

controller 层

@GetMapping("/payment/circuit/{id}")
public String paymentCircuitBreaker(@PathVariable("id") Integer id) {
    String result = paymentService.paymentCircuitBreaker(id);
    log.info("******result: " + result);
    return result;
}

熔断类型

**熔断打开：**请求不再进行调用当前服务，内部设置时钟一般为 MTTR（平均故障处理时间），当打开时长达到所设时钟，则进入半熔断状态

**熔断关闭：**熔断关闭不会对服务进行熔断

**熔断半开：**部分请求根据规则调用当前服务，如果请求成功且符合规则则认为当前服务恢复正常，关闭熔断

@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_fallback", commandProperties = {
    @HystrixProperty(name = "circuitBreaker.enabled", value = "true"),// 是否开启断路器
    @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"), // 请求次数
    @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "10000"), // 时间窗口期
    @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "60") // 失败率达到多少后跳闸
})

涉及到断路器的三个重要参数：快照时间窗，请求总数阈值，错误百分比阈值

1：快照时间窗：断路器确定是否打开需要统计一些请求和错误数据，而统计的时间范围就是快照时间窗，默认为最近 10 秒。

2：请求参数总阈值：在快照时间窗内，必须满足请求总数阀值才有资格熔断。默认为20，意味着在 10 秒内，如果该 gystrix 命令的调用次数不足 20 次，即时所有的请求都超时或者其他原因失败，断路器都不会打开。

3：错误百分比阀值：当请求总数在快照时间窗内超过了阀值，比如发生了 30 次调用，如果在这 30 次调用中，有 15 次发生了超时异常，也就是超过 50% 的错误百分比，在默认设定 50% 阀值情况下，这时候就会将断路器打开。

断路器开启或关闭的条件

1. 当满足一定的阀值的时候（默认10秒内超过20个请求）
2. 当失败率达到一定的时候（默认10秒内超过50%的请求失败）
3. 达到以上阀值，断路器将会开启
4. 当开启的时候，所有请求都不会进行转发
5. 一段时间之后（默认是 5 秒），这个时候断路器是半开状态，会让其中一个请求进行转发。如果成功，断路器会关闭，若失败，继续开启，重复 4 和 5.

服务限流

秒杀高并发操作，严谨一窝蜂的过来拥挤，大家排队，一秒钟 N 个，有序进行

二、GateWay

GateWay简介

SpringCloud GateWay 是 SpringCloud 的一个全新项目 ，基于 Spring 5.0 + Spring Boot 2.0 和 Project Reactor 等技术开发的网关，它旨在为微服务架构提供一个简单有效的统一的 API 路由管理方式。

SpringCloud GateWay 作为 Spring Cloud 生态系统中的网关，目标是替代 Zuul，在Spring Cloud 2.0 以上版本中，没有对新版本的 Zuul2.0以上最新高性能版本进行集成，仍然还是使用的 Zuul 1.x 非 Reactor 模式的老版本，而为了提高网关的性能，Spring Cloud GateWay 是基于 WebFlux 框架实现的，而 WebFlux 框架底层则使用了高性能的 Reactor 模式通信框架 Netty。

Spring Cloud GateWay 的目标统一提供的路由方式且基于 Filter 链的方式提供了网关的基本功能，例如：安全，监控/指标，和限流。

GateWay 具有如下特性

1. 基于Spring Framework 5，Project Reactor 和 Spring Boot 2.0 进行构建
2. 动态路由：能够匹配任何请求属性
3. 可以对路由指定 Predicate（断言）和Filter（过滤器）
4. 继承 Hystrix 的短路器功能
5. 继承 Spring Cloud 服务发现功能；
6. 易于编写的 Predicate（断言）和 Filter（过滤器）
7. 请求限流功能
8. 支持路径重写

GateWay 三大核心概念

Route(路由)

路由是构建网关的基本模块，它由ID目标URI，一系列的断言和过滤器组成，如果断言为 true 则匹配该路由

Predicate(断言)

开发人员可以进行匹配 HTTP 请求中的所有内容（例如：请求头或者请求参数），如果请求与断言相匹配则进行路由

Filter(过滤)

指的是 Spring 框架中 GateWayFilter 的实例，使用过滤器，可以在请求被路由前或者之后对请求修改。

实例演示

1. 创建一个 GateWay 的模块
2. 编写 pom 文件
3. 编写 application.yml 文件

server:
  port: 9527

spring:
  application:
    name: cloud-gateway
  #############################新增网关配置###########################
  cloud:
    gateway:
      routes:
        - id: payment_routh #payment_route    #路由的ID，没有固定规则但要求唯一，建议配合服务名
          uri: http://localhost:8001          #匹配后提供服务的路由地址
          #uri: lb://cloud-payment-service #匹配后提供服务的路由地址
          predicates:
            - Path=/payment/get/**         # 断言，路径相匹配的进行路由

        - id: payment_routh2 #payment_route    #路由的ID，没有固定规则但要求唯一，建议配合服务名
          uri: http://localhost:8001          #匹配后提供服务的路由地址
          #uri: lb://cloud-payment-service #匹配后提供服务的路由地址
          predicates:
            - Path=/payment/lb/**         # 断言，路径相匹配的进行路由
####################################################################

eureka:
  instance:
    hostname: cloud-gateway-service
  client: #服务提供者provider注册进eureka服务列表内
    service-url:
      register-with-eureka: true
      fetch-registry: true
      defaultZone: http://eureka7001.com:7001/eureka

1. 编写主启动类

@SpringBootApplication
@EnableEurekaClient
public class GateWayMain9527 {
  public static void main(String[] args) {
    SpringApplication.run(GateWayMain9527.class, args);
  }
}

1. 测试结果显示

GateWay 网关配置有两种方式

1. 在配置文件 yml 中配置 （上面所展示的 yml 代码就是在 yml 中配置的）
2. 代码注入 RouteLocator 的 Bean

@Bean
public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
    RouteLocatorBuilder.Builder routes = builder.routes();

    routes.route("path_route_atguigu",
                 r -> r.path("/guonei")
                 .uri("http://news.baidu.com/guonei")).build();
    return routes.build();
}

访问效果展示

GateWay 配置动态路由

修改 yml 配置文件

上面的 yml 文件中我们的 uri 是写死的，这样不好

修改动态配置

#############################新增网关配置###########################
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true	# 开启从注册中心动态创建路由的功能，利用微服务名进行路由
      routes:
        - id: payment_routh #payment_route    #路由的ID，没有固定规则但要求唯一，建议配合服务名
#          uri: http://localhost:8001          #匹配后提供服务的路由地址
          uri: lb://cloud-payment-service		#匹配后提供服务的路由地址
          predicates:
            - Path=/payment/get/**         # 断言，路径相匹配的进行路由

        - id: payment_routh2 #payment_route    #路由的ID，没有固定规则但要求唯一，建议配合服务名
#          uri: http://localhost:8001          #匹配后提供服务的路由地址
          uri: lb://cloud-payment-service		 #匹配后提供服务的路由地址
          predicates:
            - Path=/payment/lb/**         # 断言，路径相匹配的进行路由
####################################################################

访问地址：http://localhost:9527/payment/lb

GateWay 的 filter

配置全局过滤器

1. 创建一个类并实现 GlobalFilter，Ordered。

@Component
@Slf4j
public class MyLogGateWayFilter implements GlobalFilter, Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        log.info("*********come in MyLogGateWayFilter: " + new Date());
        String uname = exchange.getRequest().getQueryParams().getFirst("uname");
        if (uname == null) {
            log.info("**** 用户名非法，非法，非法，非法");
            exchange.getResponse().setStatusCode(HttpStatus.NOT_ACCEPTABLE);
            return exchange.getResponse().setComplete();
        }
        return chain.filter(exchange);
    }

    @Override
    public int getOrder() {
        return 0;
    }
}

上面代码中需要过滤路径中必须带有uname参数，否则不会给放行。

展示效果：

访问正确的路径是正常展示

filter 拦截未通过时的效果