notebook
yubin
2022-03-12
目录

Spring Cloud 快速入门 4：服务保护

# 1. 服务保护 —— 初识 Sentinel

# 1.1 雪崩问题及解决方案

微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。如果服务提供者 D 发生了故障，当前的应用的部分业务因为依赖于服务 D，因此也会被阻塞。此时，其它不依赖于服务 D 的业务似乎不受影响。但是，依赖服务 D 的业务请求被阻塞，用户不会得到响应，则 tomcat 的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞。服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。那么，依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了：

image-20210715172710340

解决雪崩问题的常见方式有四种：

# 🖊 解决方案 1：超时处理

超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待。

这种方式只能缓解雪崩问题，比如等待 1s 后返回错误信息，但每秒收到 2 个请求，依然会产生雪崩。 所以这种方案不能从根本上解决问题。

# 🖊 解决方案 2：仓壁模式

仓壁模式来源于船舱的设计：

image-20210715172946352

船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没。

于此类似，我们可以限定每个业务能使用的线程数，避免耗尽整个 tomcat 的资源，因此也叫线程隔离。

但这种方式也会造成资源浪费，比如服务 C 挂了，但依然会出现对其的访问。

# 🖊 解决方式 3：熔断降级

断路器模式：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。

断路器会统计访问某个服务的请求数量和异常比例，当发现访问服务 D 的请求异常比例过高时，认为服务D有导致雪崩的风险，会拦截访问服务 D 的一切请求，形成熔断。

# 🖊 解决方式 4：流量控制

流量控制：限制业务访问的 QPS，避免服务因流量的突增而故障。

image-20210715173555158

流量控制是预防雪崩，前三种是出现雪崩时的解决问题。注意并不是做好流量控制就会避免雪崩问题，网络问题、假死问题等都会引起雪崩。

# 1.2 服务保护技术对比

Spring Cloud 支持多种服务保护技术，早期较流行的是 Hystrix，但目前国内实用最广泛的还是阿里巴巴的 Sentinel。它俩的对比可自行百度。

# 1.3 Sentinel 安装

Sentinel 是阿里巴巴开源的微服务流量控制组件。具有如下特征：

  • 丰富的应用场景：承接多年双十一大促的核心场景
  • 完备的实时监控：可以在控制台中看到接入应用的单台机器秒级数据
  • 广泛的开源生态：可以轻松与 Spring Cloud、Dubbo、gRPC 等整合
  • 完善的 SPI 扩展点：可以通过实现扩展接口来快速地定制逻辑，如定制规则管理、适配动态数据源等

# 安装：

去 Github 下载 jar 包，在任意非中文目录执行：

java -jar sentinel-dashboard-1.8.1.jar
1
配置项 默认值 说明
server.port 8080 服务端口
sentinel.dashboard.auth.username sentinel 默认用户名
sentinel.dashboard.auth.password sentinel 默认密码

例如，修改端口：

java -Dserver.port=8090 -jar sentinel-dashboard-1.8.1.jar
1

之后在指定端口便可访问其控制台页面了。

# 1.4 微服务整合 Sentinel

我们在 order-service 中整合sentinel，并连接 sentinel 的控制台，步骤如下：

# 1）引入依赖

<!--sentinel-->
<dependency>
    <groupId>com.alibaba.cloud</groupId> 
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
1
2
3
4
5

# 2）配置控制台

修改 application.yaml 文件，添加下面内容：







 

server:
  port: 8088
spring:
  cloud: 
    sentinel:
      transport:
        dashboard: localhost:8080  # sentinel 控制台地址
1
2
3
4
5
6
7

# 3）访问服务

访问 order-service 的任意端点，比如访问 http://localhost:8088/order/101，这样才能触发 sentinel 的监控。

这时打开 Sentinel 的控制台，可以看到效果：

image-20210715191241799

# 2. Sentinel 的流量控制

限流是避免服务因突发的流量而发生故障，是对微服务雪崩问题的预防。

# 2.1 簇点链路

当请求进入微服务时，首先会访问 DispatcherServlet，然后进入 Controller、Service、Mapper，这样的一个调用链就叫做簇点链路。簇点链路中被监控的每一个接口就是一个资源。默认情况下 sentinel 会监控 Spring MVC 的每一个端点（Endpoint），因此 Spring MVC 的每一个端点就是调用链路中的一个资源。

例如我们刚刚访问的 order-service 中的 OrderController 中的端点：/order/{orderId}：

image-20210715191757319

流控、熔断等都是针对簇点链路中的资源来设置的，因此我们可以点击对应资源后面的按钮来设置规则：

  • 流控：流量控制
  • 降级：降级熔断
  • 热点：热点参数限流，是限流的一种
  • 授权：请求的权限控制

# 2.2 快速入门

在 Sentinel 控制台中，点击资源 /order/{orderId} 后面的流控按钮，就可以弹出表单：

image-20210715191757319

表单中可以填写限流规则，如下：

image-20210715192010657
  • 其含义是限制 /order/{orderId} 这个资源的单机 QPS 为 1，即每秒只允许1次请求，超出的请求会被拦截并报错。

# 2.3 流控模式

在添加限流规则时，点击高级选项，可以选择三种流控模式：

  • 直接（默认）：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式
  • 关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流
  • 链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流

# 2.3.1 关联模式

关联模式：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流

image-20210715202540786
  • 当 /write 资源访问量触发阈值时，就会对 /read 资源限流，避免影响 /write 资源。

使用场景：比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是优先支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。

需求说明：

  • 在 OrderController 新建两个端点：/order/query 和 /order/update，无需实现业务

  • 配置流控规则，当 /order/update 资源被访问的 QPS 超过 5 时，对 /order/query 请求限流

# 1）定义两个端点

两个端点模拟订单的查询和更新业务：

@GetMapping("/query")
public String queryOrder() {
    return "查询订单成功";
}

@GetMapping("/update")
public String updateOrder() {
    return "更新订单成功";
}
1
2
3
4
5
6
7
8
9

重启服务后，可以在 Sentinel 控制台的簇点链路中配置规则。

# 2）配置流控规则

对哪个端点限流，就点击哪个端点后面的按钮。我们是对订单查询 /order/query 限流，因此点击它后面的按钮，并在表单中填写流控规则：

image-20210716102103814

小结

满足下面的条件可以使用关联模式：

  • 两个有竞争关系的资源
  • 一个优先级较高，另一个优先级较低

# 2.3.2 链路模式

链路模式：只针对从指定链路访问到本资源的请求做统计，判断是否超过阈值。

配置示例：

例如有两条请求链路：

  • /test1 --> /common

  • /test2 --> /common

如果只希望统计从 /test2 进入到/common的请求，则可以这样配置：

image-20210716103536346

实战案例：有查询订单和创建订单业务，两者都需要查询商品。针对从查询订单进入到查询商品的请求统计，并设置限流。

# 1）添加查询商品方法

在 order-service 服务中，给 OrderService 类添加一个 queryGoods 方法：

@Service
public class OrderService {
    ...
    public void queryGoods() {
    	System.err.println("查询商品");
	}
}
1
2
3
4
5
6
7
# 2）查询订单时，查询商品

在 order-service 的 OrderController 中，修改 /order/query 端点的业务逻辑：

@GetMapping("/query")
public String queryOrder() {
    // 查询商品
    orderService.queryGoods();
    // 查询订单
    System.out.println("查询订单");
    return "查询订单成功";
}
1
2
3
4
5
6
7
8
# 3）新增订单，查询商品

在 order-service 的 OrderController 中，修改 /order/save 端点，模拟新增订单：

@GetMapping("/save")
public String saveOrder() {
    // 查询商品
    orderService.queryGoods();
    // 查询订单
    System.err.println("新增订单");
    return "新增订单成功";
}
1
2
3
4
5
6
7
8
# 4）给查询商品添加资源标记

默认情况下，OrderService 中的方法是不被 Sentinel 监控的，需要我们自己通过注解来标记要监控的方法。

给 OrderService 的 queryGoods 方法添加 @SentinelResource 注解：

 




@SentinelResource("goods")
public void queryGoods(){
    System.err.println("查询商品");
}
1
2
3
4

链路模式中，是对不同来源的两个链路做监控。但是 sentinel 默认会给进入 Spring MVC 的所有请求设置同一个 root 资源，会导致链路模式失效。我们需要关闭这种对 Spring MVC 的资源聚合，修改 order-service 服务的 application.yml 文件：

spring:
  cloud:
    sentinel:
      web-context-unify: false # 关闭context整合
1
2
3
4

重启服务，访问 /order/query 和 /order/save，可以查看到 sentinel 的簇点链路规则中，出现了新的资源：

image-20210716105227163
# 5）添加流控规则

点击 goods 资源后面的流控按钮，在弹出的表单中填写下面信息：

image-20210716105408723
  • 只统计从 /order/query 进入 /goods 的资源，QPS阈值为 2，超出则被限流。

# 2.4 流控效果

在流控的高级选项中，还有一个流控效果选项：

image-20210716110225104

流控效果是指请求达到流控阈值时应该采取的措施：

  • 快速失败：达到阈值后，新的请求会被立即拒绝并抛出 FlowException 异常。【默认】

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

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

# 2.4.1 流控效果 - warm up

阈值一般是一个微服务能承担的最大QPS，但是一个服务刚刚启动时，一切资源尚未初始化（冷启动），如果直接将 QPS 跑到最大值，可能导致服务瞬间宕机。

warm up 也叫预热模式，是应对服务冷启动的一种方案。请求阈值初始值是 maxThreshold / coldFactor，持续指定时长后，逐渐提高到 maxThreshold 值。而 coldFactor 的默认值是3.

# 2.4.2 流控效果 - 排队等待

排队等待是让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成，如果请求预期的等待时间超出最大时长，则会被拒绝。

例如：QPS = 5，意味着每 200ms 处理一个队列中的请求；timeout = 2000，意味着预期等待时长超过2000ms的请求会被拒绝并抛出异常。

那什么叫做预期等待时长呢？

比如现在一下子来了12 个请求，因为每 200ms 执行一个请求，那么：

  • 第6个请求的预期等待时长 = 200 * （6 - 1） = 1000ms
  • 第12个请求的预期等待时长 = 200 * （12-1） = 2200ms

使用这种模式，QPS 曲线会变的很平滑，这也能起到流量整形的作用，对于服务器来说是更友好的。

# 2.5 热点参数限流

之前的限流是统计访问某个资源的所有请求，判断是否超过QPS阈值。而热点参数限流是分别统计参数值相同的请求，判断是否超过QPS阈值。它是一种更细粒度的限流。

# 2.5.1 全局参数限流

image-20210716115131463
  • 当 id=1 的请求触发阈值被限流时，id 值不为1的请求不受影响。

配置示例：

image-20210716115232426
  • 对 hot 这个资源的 0 号参数（第一个参数）做统计，每 1 秒相同参数值的请求数不能超过 5

# 2.5.2 热点参数限流

刚才的配置中，对查询商品这个接口的所有商品一视同仁，QPS都限定为5。而在实际开发中，可能部分商品是热点商品，例如秒杀商品，我们希望这部分商品的 QPS 限制与其它商品不一样，高一些。那就需要配置热点参数限流的高级选项了：

image-20210716115717523
  • 结合上一个配置，这里的含义是对 0 号的 long 类型参数限流，每 1 秒相同参数的 QPS 不能超过 5，有两个例外：
    • 如果参数值是 100，则每 1 秒允许的 QPS 为 10
    • 如果参数值是 101，则每 1 秒允许的 QPS 为 15

# 2.5.3 案例

需求：给 /order/{orderId} 这个资源添加热点参数限流，规则如下：

  • 默认的热点参数规则是每1秒请求量不超过2
  • 给102这个参数设置例外：每1秒请求量不超过4
  • 给103这个参数设置例外：每1秒请求量不超过10

注意

热点参数限流对默认的 Spring MVC 资源无效，需要利用 @SentinelResource 注解标记资源

# 1）标记资源

给 order-service 中的 OrderController 中的 /order/{orderId} 资源添加注解：

@SentinelResource("hot")
@GetMapping("{orderId}")
public Order queryOrderByUserId(@PathVariable("orderId") Long orderId) {
    // 根据id查询订单并返回
    return orderService.queryOrderById(orderId);
}
1
2
3
4
5
6
# 2）热点参数限流规则

在 Sentinel 控制台可以看到 hot 资源出现了，点击左侧菜单中热点规则菜单：

image-20210716120319009

点击新增，填写表单：

image-20210716120536714

# 3. Sentinel 的隔离和降级

虽然限流可以尽量避免因高并发而引起的服务故障，但服务还会因为其它原因而故障。而要将这些故障控制在一定范围，避免雪崩，就要靠线程隔离（舱壁模式）和熔断降级手段了。

线程隔离：调用者在调用服务提供者时，给每个调用的请求分配独立线程池，出现故障时，最多消耗这个线程池内资源，避免把调用者的所有资源耗尽。

image-20220314150238006

熔断降级：是在调用方这边加入断路器，统计对服务提供者的调用，如果调用的失败比例过高，则熔断该业务，不允许访问该服务的提供者了。

image-20210715173428073

不管是线程隔离还是熔断降级，都是对客户端（调用方）的保护。

我们的微服务远程调用都是基于 Feign 来完成的，因此我们需要将 Feign 与 Sentinel 整合，在 Feign 里面实现线程隔离和服务熔断。

# 3.1 FeignClient 整合 Sentinel

# 1）修改配置，开启 sentinel 功能

修改 OrderService 的 application.yml 文件，开启 Feign 的 Sentinel 功能：

feign:
  sentinel:
    enabled: true # 开启feign对sentinel的支持
1
2
3

# 2）编写失败降级逻辑

业务失败后，不能直接报错，而应该返回用户一个友好提示或者默认结果，这个就是失败降级逻辑。

给 FeignClient 编写失败后的降级逻辑：

  • 方式 1：FallbackClass，无法对远程调用的异常做处理
  • 方式 2：FallbackFactory，可以对远程调用的异常做处理

这里我们演示方式 2 的失败降级处理。

👣 step 1：在 feign-api 项目中定义类，实现 FallbackFactory

image-20220314151245872 

import feign.hystrix.FallbackFactory;
...

@Slf4j
public class UserClientFallbackFactory implements FallbackFactory<UserClient> {
    @Override
    public UserClient create(Throwable throwable) {
        return new UserClient() {
            @Override
            public User findById(Long id) {
                log.error("查询用户异常", throwable);
                return new User();
            }
        };
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

👣 step 2：在 DefaultFeignConfiguration 类中将 UserClientFallbackFactory 注册为一个Bean：

@Bean
public UserClientFallbackFactory userClientFallbackFactory(){
    return new UserClientFallbackFactory();
}
1
2
3
4

👣 step 3：在 UserClient 接口中使用 UserClientFallbackFactory：

@FeignClient(value = "userservice", fallbackFactory = UserClientFallbackFactory.class)
public interface UserClient {

    @GetMapping("/user/{id}")
    User findById(@PathVariable("id") Long id);
}
1
2
3
4
5
6

重启后，访问一次订单查询业务，然后查看 sentinel 控制台，可以看到新的簇点链路：

image-20210716123705780

总结

Feign 整合 Sentinel 的步骤：

  • 在 application.yml 中配置：feign.sentienl.enable=true
  • 给 FeignClient 编写 FallbackFactory 并注册为 Bean
  • 将 FallbackFactory 配置到 FeignClient

# 3.2 线程隔离（舱壁模式）

# 3.2.1 线程隔离的实现方式

线程隔离有两种方式实现：

  • 线程池隔离

  • 信号量隔离（Sentinel 默认采用）

image-20210716123036937
  • 左边是线程池隔离，右边是信号量隔离

线程池隔离：给每个服务调用业务分配一个线程池，利用线程池本身实现隔离效果。

信号量隔离：不创建线程池，而是计数器模式，记录业务使用的线程数量，达到信号量上限时，禁止新的请求。

两者的优缺点：

线程池隔离 信号量隔离
优：支持主动超时、异步调用 轻量级，无额外开销
缺：线程的额外开销较大 不支持主动超时、异步调用
场景：低扇出 高频调用、高扇出
  • 扇出：是指调用 A 服务后，A 又会调用好几个别的服务，这就像一个扇子一样，一下子扇出好几个。像网关就是一个高扇出的服务。
  • 主动超时：比如当我们发现某个线程执行太久了，可以主动关掉这个线程，从而主动关闭它。

# 3.2.2 sentinel 的线程隔离

在添加限流规则时，可以选择两种阈值类型：

image-20210716123411217

  • QPS：就是每秒的请求数，

  • 线程数：是该资源能使用用的 tomcat 线程数的最大值。也就是通过限制线程数量，实现线程隔离（舱壁模式）。

# 3.2.3 案例

需求：给 order-service 服务中的 UserClient 的查询用户接口设置流控规则，线程数不能超过 2。

选择 feign 接口后面的流控按钮：

image-20210716123831992

填写表单：

image-20210716123936844

# 3.3 熔断降级

熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求。

断路器控制熔断和放行是通过状态机来实现的。状态机包括三个状态：

  • closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值则切换到 open 状态
  • open：打开状态，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open 状态 5 秒后会进入 half-open 状态
  • half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。
    • 请求成功：则切换到 closed 状态
    • 请求失败：则切换到 open 状态

熔断条件的判断是依据熔断策略来完成的。断路器熔断策略有三种：慢调用、异常比例、异常数

# 3.3.1 慢调用

慢调用：业务的响应时长（RT）大于指定时长的请求认定为慢调用请求。在指定时间内，如果请求数量超过设定的最小数量，慢调用比例大于设定的阈值，则触发熔断。

image-20210716145934347
  • 解读：RT 超过 500ms 的调用是慢调用，统计最近 10000ms 内的请求，如果请求量超过 10 次，并且慢调用比例不低于 0.5，则触发熔断，熔断时长为 5 秒。然后进入 half-open 状态，放行一次请求做测试。

案例需求：给 UserClient 的查询用户接口设置降级规则，慢调用的 RT 阈值为 50ms ，统计时间为 1 秒，最小请求数量为 5，失败阈值比例为 0.4，熔断时长为 5

# 👣 1）设置慢调用

修改 user-service 中的 /user/{id} 这个接口的业务。通过休眠模拟一个延迟时间：





 




@GetMapping("/{id}")
public User queryById(@PathVariable("id") Long id, @RequestHeader(value = "Truth", required = false) String truth) throws InterruptedException {
    if (id == 1) {
        // 休眠，触发熔断
        Thread.sleep(60);
    }
    return userService.queryById(id);
}
1
2
3
4
5
6
7
8

此时，orderId=101 的订单，关联的是 id 为 1 的用户，调用时长为 60ms，其他调用则很快。

# 👣 2）设置熔断规则

下面，给 feign 接口设置降级规则：

image-20210716150654094

image-20210716150740434
  • 超过 50ms 的请求都会被认为是慢请求
# 👣 3）测试

在浏览器访问：http://localhost:8088/order/101，快速刷新5次，可以发现触发了熔断，快速失败了，并且走降级逻辑，返回的默认结果。此时在浏览器访问：http://localhost:8088/order/102，竟然也被熔断了：

# 3.3.2 异常比例、异常数

异常比例或异常数：统计指定时间内的调用，如果调用次数超过指定请求数，并且出现异常的比例达到设定的比例阈值（或超过指定异常数），则触发熔断。

image-20210716131430682
  • 解读：统计最近 1000ms 内的请求，如果请求量超过 10 次，并且异常比例不低于 0.4，则触发熔断。

案例需求：给 UserClient 的查询用户接口设置降级规则，统计时间为 1 秒，最小请求数量为 5，失败阈值比例为 0.4，熔断时长为 5s

# 👣 1）设置异常请求

首先，修改 user-service 中的 /user/{id} 这个接口的业务。手动抛出异常，以触发异常比例的熔断：






 
 




@GetMapping("/{id}")
public User queryById(@PathVariable("id") Long id, @RequestHeader(value = "Truth", required = false) String truth) throws InterruptedException {
    if (id == 1) {
        // 休眠，触发熔断
        Thread.sleep(60);
    } else if (id == 2) {
        throw new RuntimeException("故意出错，触发熔断");
    }
    return userService.queryById(id);
}
1
2
3
4
5
6
7
8
9
10
  • 也就是说，id 为 2 时，就会触发异常
# 👣 2）设置熔断规则

下面，给 feign 接口设置降级规则：

image-20210716150654094image-20210716151538785

image-20210716151538785

在 5 次请求中，只要异常比例超过 0.4，也就是有 2 次以上的异常，就会触发熔断。

# 👣 3）测试

在浏览器快速访问：http://localhost:8088/order/102，快速刷新5次，触发熔断。

# 4. Sentinel 的授权规则

# 4.1 授权规则

# 4.1.1 基本规则

授权规则可以对调用方的来源（origin）做控制，有白名单和黑名单两种方式。

  • 白名单：来源在白名单内的调用者允许访问

  • 黑名单：来源在黑名单内的调用者不允许访问

网关就可以做身份验证的工作了，这里的授权规则可以将微服务的地址进行保护，使之只能通过网关来访问，而防止了有人直接对微服务的访问。

点击左侧菜单的授权，可以看到授权规则：

image-20210716152010750

  • 资源名：就是受保护的资源，例如 /order/{orderId}

  • 流控应用：是来源者的名单，

比如我们允许请求从 gateway 到 order-service，不允许浏览器访问 order-service，那么白名单中就要填写网关的来源名称（origin）。

# 4.1.2 如何获取 origin

Sentinel 是通过 RequestOriginParser 这个接口的 parseOrigin 来获取请求的来源的：

public interface RequestOriginParser {
    /**
     * 从请求 request 对象中获取 origin，获取方式自定义
     */
    String parseOrigin(HttpServletRequest request);
}
1
2
3
4
5
6

这个方法的作用就是从 request 对象中，获取请求者的 origin 值并返回。默认情况下，sentinel 不管请求者从哪里来，返回值永远是 default，也就是说一切请求的来源都被认为是一样的值 default。

因此，我们需要自定义这个接口的实现，让不同的请求，返回不同的 origin。

例如 order-service 服务中，我们定义一个 RequestOriginParser 的实现类：

import com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.RequestOriginParser;
...

@Component
public class HeaderOriginParser implements RequestOriginParser {
    @Override
    public String parseOrigin(HttpServletRequest request) {
        // 1.获取请求头
        String origin = request.getHeader("origin");
        // 2.非空判断
        if (StringUtils.isEmpty(origin)) {
            origin = "blank";
        }
        return origin;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
  • 我们会尝试从 request-header 中获取 origin 值。怎样获取是自定义的。

# 4.1.3 给网关添加请求头

既然获取请求 origin 的方式是从 reques-header 中获取 origin 值，我们必须让所有从 gateway 路由到微服务的请求都带上 origin 头。

这个需要利用之前学习的一个 GatewayFilter 来实现： AddRequestHeaderGatewayFilter。修改 gateway 服务中的 application.yml，添加一个 defaultFilter：





 



spring:
  cloud:
    gateway:
      default-filters:
        - AddRequestHeader=origin,gateway
      routes:
       # ...略
1
2
3
4
5
6
7

这样，从 gateway 路由的所有请求都会带上 origin 头，值为 gateway。而从其它地方到达微服务的请求则没有这个头。

# 4.1.5 配置授权规则

接下来，我们添加一个授权规则，放行 origin 值为 gateway 的请求。

image-20210716153250134image-20210716153301069

image-20210716153301069

现在，我们直接跳过网关，访问 order-service 服务，会发现直接访问微服务，请求会被拦截，而通过网关访问则不受影响。

# 4.2 自定义异常结果

默认情况下，发生限流、降级、授权拦截时，都会抛出异常到调用方。异常结果都是 flow limmiting（限流）。这样不够友好，无法得知是限流还是降级还是授权拦截。

# 4.2.1 异常类型

如果要自定义异常时的返回结果，需要实现 BlockExceptionHandler 接口：

public interface BlockExceptionHandler {
    /**
     * 处理请求被限流、降级、授权拦截时抛出的异常：BlockException
     */
    void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception;
}
1
2
3
4
5
6

这个方法有三个参数：

  • HttpServletRequest request：request对象
  • HttpServletResponse response：response对象
  • BlockException e：被sentinel拦截时抛出的异常

这里的 BlockException 包含多个不同的子类：

异常 说明
FlowException 限流异常
ParamFlowException 热点参数限流的异常
DegradeException 降级异常
AuthorityException 授权规则异常
SystemBlockException 系统规则异常

# 4.2.2 自定义异常处理

下面，我们就在 order-service 定义一个自定义异常处理类：

@Component
public class SentinelExceptionHandler implements BlockExceptionHandler {
    @Override
    public void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception {
        String msg = "未知异常";
        int status = 429;

        if (e instanceof FlowException) {
            msg = "请求被限流了";
        } else if (e instanceof ParamFlowException) {
            msg = "请求被热点参数限流";
        } else if (e instanceof DegradeException) {
            msg = "请求被降级了";
        } else if (e instanceof AuthorityException) {
            msg = "没有权限访问";
            status = 401;
        }

        response.setContentType("application/json;charset=utf-8");
        response.setStatus(status);
        response.getWriter().println("{\"msg\": " + msg + ", \"status\": " + status + "}");
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

重启测试，在不同场景下（限流、授权拦截...），会返回不同的异常信息。

总结

  • 获取请求来源的接口：RequestOriginParser
  • 处理 BlockException 的接口：BlockExceptionHandler

# 5. 规则持久化

现在，sentinel 的所有规则都是内存存储，重启后所有规则都会丢失。在生产环境下，我们必须确保这些规则的持久化，避免丢失。

# 5.1 规则管理模式

规则是否能持久化，取决于规则管理模式，sentinel支持三种规则管理模式：

  • 原始模式：Sentinel 的默认模式，将规则保存在内存，重启服务会丢失。
  • pull 模式和 push 模式

# 5.1.1 pull 模式

pull 模式：控制台将配置的规则推送到Sentinel客户端，而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询，更新本地规则。

image-20210716154155238

这种方式存在时效性问题。比如当推送规则写入本地文件中后，客户端不会立刻去查询并更新，这会导致不同的服务之间具有不同的规则，从而产生不一致性问题。

# 5.1.2 push 模式 ⭐️

push 模式：控制台将配置规则推送到远程配置中心，例如 Nacos。Sentinel 客户端监听 Nacos，获取配置变更的推送消息，完成本地配置更新。【推荐使用这种方式】

image-20210716154215456

具体配置方式可自行搜索

编辑 (opens new window)
上次更新: 2023/04/22, 08:56:42
Spring Cloud 快速入门 3：服务异步通讯
Spring Security

← Spring Security→

最近更新
01
Deep Reinforcement Learning
10-03
02
误删数据后怎么办
04-06
03
MySQL 一主多从
03-22
更多文章>
Theme by Vdoing | Copyright © 2021-2024 yubincloud | MIT License
×