Spring Cloud详细笔记-Toy模板网

这篇具有很好参考价值的文章主要介绍了Spring Cloud详细笔记。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

Spring Cloud 学习组件

服务注册中心：Zookeeper、Nacos🐕，每个微服务启动都需要向Nacos注册，服务消费者使用服务时向Nacos拉取服务。维护微服务IP地址和端口
服务调用：Ribbon、OpenFeign🐕，替换restTemplate发送http请求，**从Nacos拿到的IP端口进行服务请求。**内部的服务请求！
```
User user = restTemplate.getForObject(url.User.class);
```
服务降级：Sentienl🐕，微服务保护、服务降级、流量控制、熔断降级
服务网关：Gateway🐕，外部服务请求的权限控制，限流，请求路由等！
服务配置：Nacos🐕，统一管理经常需要修改的配置！
服务总线：Nacos🐕

为什么使用微服务

模块化和可维护性：微服务架构将大型应用程序拆分为多个小型服务，每个服务都专注于一个特定的业务功能。这种模块化的设计使得每个服务的代码和逻辑相对简单，更易于维护和修改。
可扩展性：由于每个服务都是独立的，可以根据需求对特定服务进行水平扩展，而不会对整个系统造成影响。
技术多样性：微服务架构允许每个服务使用适合其需求的最佳技术栈和编程语言。这样可以根据具体的业务需求选择最适合的技术，提高开发效率和灵活性。
可测试性：微服务架构将系统拆分为小型服务，每个服务的代码相对简单，更易于编写单元测试、集成测试和端到端测试。
高可用性和容错性：由于每个服务都是独立的，一个服务的故障不会影响整个系统的运行。通过采用适当的容错机制，如负载均衡、故障恢复和服务发现等，可以提高系统的可用性和容错性。

案例需求：

假设有两个微服务：order-service和user-service，修改order-service，根据id查询订单业务，要求在查询订单的同时，根据订单中包含的userId查询出用户信息，一起返回。不能直接调用order-service的数据库。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jwMUZJi9-1685800252528)(E:/BaiduNetdiskDownload/2022黑马/黑马旅游/实战篇/学习资料/day01-SpringCloud01/讲义/assets/image-20210713213312278.png)]

因此，我们需要在order-service中向user-service发起一个http的请求，调用http://localhost:8081/user/{userId}这个接口。

RestTemplate

RestTemplate是Spring Framework中的一个类，用于在Java应用程序中发送HTTP请求并与RESTful风格的Web服务进行交互。RestTemplate提供了各种方法来执行HTTP请求，如GET、POST、PUT、DELETE等，可以发送请求并接收响应数据。它封装了HTTP连接、请求和响应的处理，并提供了一组方便的方法来简化与Web服务的交互。

使用RestTemplate，您可以进行以下操作：

发送GET请求：使用RestTemplate的getForObject()或getForEntity()方法可以发送GET请求，并获取响应结果。您可以指定请求的URL、参数和返回类型。
发送POST请求：使用RestTemplate的postForObject()或postForEntity()方法可以发送POST请求，并将请求数据传递给服务器。您可以指定请求的URL、请求体、参数和返回类型。
发送PUT请求：使用RestTemplate的put()方法可以发送PUT请求，并将请求数据传递给服务器。您可以指定请求的URL、请求体和参数。
发送DELETE请求：使用RestTemplate的delete()方法可以发送DELETE请求，并删除服务器上的资源。您可以指定请求的URL和参数。
处理响应数据：RestTemplate支持将响应数据转换为各种类型，如String、JSON、XML等。您可以根据需要使用不同的方法，如getForObject()、postForObject()等。

可以在order-service中使用RestTemplate请求user-service微服务返回user用户。

注册中心Eureka和Nacos

如上图所示，我们将user-service的url写死了，实际生产环境中有多个user-service服务器实例。如果我们需要增加服务器实例或者停掉其中几台我们不希望停机修改代码，而是用一种动态管理的服务进行热部署。这种动态管理的程序叫做注册中心。在微服务架构中，注册中心是一种用于管理和跟踪微服务实例的组件。它充当了服务发现和服务注册的中心化存储和协调器。注册中心允许微服务在启动时向其注册自己的实例信息，并在需要时提供服务实例的位置信息。

服务注册：微服务在启动时将自己的实例信息（如主机名、IP地址、端口号、健康状态等）注册到注册中心。这样，其他服务或客户端可以查询注册中心以获取可用的服务实例。
服务发现：服务发现是指客户端或其他微服务查询注册中心以获取特定服务的可用实例列表。通过注册中心，客户端可以动态地发现和连接到服务，而无需硬编码服务实例的位置信息。
心跳和健康检查：注册中心通常会通过心跳机制或定期的健康检查来监控服务实例的可用性。如果某个服务实例不再响应心跳或健康检查，注册中心将标记该实例为不可用，并从服务列表中移除。
负载均衡：注册中心可以提供负载均衡的功能，使客户端能够在多个可用实例之间分配请求负载。负载均衡可以基于不同的算法，如轮询、随机选择、加权等，来确保请求在可用实例之间均匀分布。
自动服务故障处理：注册中心可以自动检测服务实例的故障并进行处理。当某个服务实例不可用时，注册中心可以通知其他微服务或负载均衡器，从而避免将请求发送到不可用的实例。

Eureka

获取地址信息的流程如下：

user-service服务实例启动后，将自己的信息注册到eureka-server（Eureka服务端）。这个叫服务注册eureka-server保存服务名称到服务实例地址列表的映射关系。order-service根据服务名称，拉取实例地址列表。这个叫服务发现或服务拉取。

order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？

user-service会每隔一段时间（默认30秒）向eureka-server发起请求，报告自己状态，称为心跳。当超过一定时间没有发送心跳时，eureka-server会认为微服务实例故障，将该实例从服务列表中剔除。order-service拉取服务时，就能将故障实例排除了

实际搭建Eureka服务：

引入SpringCloud为eureka服务提供的starter依赖

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

给eureka-server服务编写一个启动类，一定要添加一个@EnableEurekaServer注解，开启eureka的注册中心功能

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

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

编写一个application.yml文件，内容如下:

server:
  port: 10086
spring:
  application:
    name: eureka-server
eureka:
  client:
    service-url: 
      defaultZone: http://127.0.0.1:10086/eureka

启动微服务，然后在浏览器访问：http://127.0.0.1:10086。

服务注册

引入eureka客户端依赖：在user-service的pom文件中，引入下面的eureka-client依赖：

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

在user-service中，修改application.yml文件，添加服务名称、eureka地址：

spring:
  application:
    name: userservice #本微服务名称
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka #eureka服务地址

服务发现

在order-service的pom文件中，引入下面的eureka-client依赖：

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

服务发现也需要知道eureka地址，因此第二步与服务注册一致，都是配置eureka信息。在order-service中，修改application.yml文件，添加服务名称、eureka地址：

spring:
  application:
    name: orderservice
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

服务拉取和负载均衡

修改order-service服务中的order.service包下的OrderService类中的queryOrderById方法。修改访问的url路径，用服务名代替ip、端口：

spring会自动帮助我们从eureka-server端，根据userservice这个服务名称，获取实例列表，而后完成负载均衡。另外，负载均衡只需要给RestTemplate这个Bean添加一个@LoadBalanced注解。

Ribbon负载均衡原理

SpringCloud底层其实是利用了一个名为Ribbon的组件，来实现负载均衡功能的。

那么我们发出的请求明明是http://userservice/user/1，怎么变成了http://localhost:8081的呢？那就是LoadBalancerInterceptor，这个类会在对RestTemplate的请求进行拦截，然后从Eureka根据服务id获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务id。

基本流程如下：

拦截我们的RestTemplate请求http://userservice/user/1
RibbonLoadBalancerClient会从请求url中获取服务名称，也就是user-service
根据user-service到eureka拉取服务列表
eureka返回列表，localhost:8081、localhost:8082
LoadBalancer通过IRule的choose(key)利用内置负载均衡规则，从列表中选择一个，例如localhost:8081
RibbonLoadBalancerClient修改请求地址，用localhost:8081替代userservice，得到http://localhost:8081/user/1，发起真实请求

负载均衡策略IRule

不同规则的含义如下：

内置负载均衡规则类	规则描述
RoundRobinRule	简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。
AvailabilityFilteringRule	对以下两种服务器进行忽略：（1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。（2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的..ActiveConnectionsLimit属性进行配置。
WeightedResponseTimeRule	为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。
ZoneAvoidanceRule	以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。
BestAvailableRule	忽略那些短路的服务器，并选择并发数较低的服务器。
RandomRule	随机选择一个可用的服务器。
RetryRule	重试机制的选择逻辑

默认的实现就是ZoneAvoidanceRule，是一种轮询方案

饥饿加载

Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：

ribbon:
  eager-load:
    enabled: true
    clients: userservice

Nacos注册中心

国内公司一般都推崇阿里巴巴的技术，比如注册中心，SpringCloudAlibaba也推出了一个名为Nacos的注册中心。Nacos更加简单，从官网下载Nacos的安装包，解压运行即可开启Nacos服务。我们只需要对依赖和配置文件进行更改即可！restTemplate不需要改动。

引入依赖

在cloud-demo父工程的pom文件中的<dependencyManagement>中引入SpringCloudAlibaba的依赖：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
    <version>2.2.6.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

然后在user-service和order-service中的pom文件中引入nacos-discovery依赖：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

配置nacos地址

在user-service和order-service的application.yml中添加nacos地址：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848

服务分级存储模型

Nacos将同一机房内的实例划分为一个集群。也就是说，user-service是服务，一个服务可以包含多个集群，如杭州、上海，每个集群下可以有多个实例，形成分级模型。微服务互相访问时，应该尽可能访问同集群实例，因为本地访问速度更快。当本集群内不可用时，才访问其它集群。

给user-service配置集群

修改user-service的application.yml文件，添加集群配置：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名称

重启两个user-service实例后，我们可以在nacos控制台看到下面结果：

同集群优先的负载均衡

默认的ZoneAvoidanceRule并不能实现根据同集群优先来实现负载均衡。因此Nacos中提供了一个NacosRule的实现，可以优先从同集群中挑选实例。

1）给order-service配置集群信息

修改order-service的application.yml文件，添加集群配置：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名称

2）修改负载均衡规则

修改order-service的application.yml文件，修改负载均衡规则：

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则

权重配置

实际部署中会出现这样的场景：服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。但默认情况下NacosRule是同集群内随机挑选，不会考虑机器的性能问题。因此，Nacos提供了权重配置来控制访问频率，权重越大则访问频率越高。在nacos控制台，找到user-service的实例列表，点击编辑，即可修改权重。如果权重修改为0，则该实例永远不会被访问，通过这个特性可以做到微服务器实例的热部署。

环境隔离

Nacos提供了namespace来实现环境隔离功能。

nacos中可以有多个namespace
namespace下可以有group、service等
不同namespace之间相互隔离，例如不同namespace的服务互相不可见

默认情况下，所有service、data、group都在同一个namespace，名为public。可以在网页管理后台点击页面新增按钮，添加一个namespace。然后给微服务配置namespace，给微服务配置namespace只能通过修改配置来实现。

例如，修改order-service的application.yml文件：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ
        namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空间，填ID，从网页管理后台复制来的

此时访问order-service，因为namespace不同，会导致找不到userservice，控制台会报错.

Nacos与Eureka的区别

Nacos的服务实例分为两种类型：

临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。
非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

配置一个服务实例为永久实例：

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为非临时实例

Nacos和Eureka整体结构类似，服务注册、服务拉取、心跳等待，但是也存在一些差异：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-v2f4h5gZ-1685800252530)(E:/BaiduNetdiskDownload/2022黑马/黑马旅游/实战篇/学习资料/day01-SpringCloud01/讲义/assets/image-20210714001728017.png)]

Nacos与eureka的共同点
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别
- Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
- 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
- Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
- Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

Nacos配置管理

Nacos除了可以做注册中心，同样可以做配置管理来使用。当微服务部署的实例越来越多，达到数十、数百时，逐个修改微服务配置就会让人抓狂，而且很容易出错。我们需要一种统一配置管理方案，可以集中管理所有实例的配置。Nacos一方面可以将配置集中管理，另一方可以在配置变更时，及时通知微服务，实现配置的热更新。

在nacos中添加配置文件

然后在弹出的表单中，填写配置信息：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hoIT9RGY-1685800252530)(E:\BaiduNetdiskDownload\2022黑马\黑马旅游\实战篇\学习资料\day02-SpringCloud02\讲义\assets\image-20210714164856664.png)]

注意：项目的核心配置，需要热更新的配置才有放到nacos管理的必要。基本不会变更的一些配置还是保存在微服务本地比较好。

从微服务拉取配置

微服务要拉取nacos中管理的配置，并且与本地的application.yml配置合并，才能完成项目启动。

但如果尚未读取application.yml，又如何得知nacos地址呢？

因此spring引入了一种新的配置文件：bootstrap.yaml文件，会在application.yml之前被读取，流程如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tR12PQHs-1685800252531)(E:\BaiduNetdiskDownload\2022黑马\黑马旅游\实战篇\学习资料\day02-SpringCloud02\讲义\assets\L0iFYNF.png)]

1）引入nacos-config依赖

首先，在user-service服务中，引入nacos-config的客户端依赖：

<!--nacos配置管理依赖-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

2）添加bootstrap.yaml

然后，在user-service中添加一个bootstrap.yaml文件，内容如下：

spring:
  application:
    name: userservice # 服务名称
  profiles:
    active: dev #开发环境，这里是dev 
  cloud:
    nacos:
      server-addr: localhost:8848 # Nacos地址
      config:
        file-extension: yaml # 文件后缀名

这里会根据spring.cloud.nacos.server-addr获取nacos地址，再根据

${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}作为文件id，来读取配置。

本例中，就是去读取userservice-dev.yaml：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-F3jZzIWd-1685800252531)(E:\BaiduNetdiskDownload\2022黑马\黑马旅游\实战篇\学习资料\day02-SpringCloud02\讲义\assets\image-20210714170845901.png)]

3）读取nacos配置

在user-service中的UserController中添加业务逻辑，读取pattern.dateformat配置：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FnmT6X7B-1685800252532)(E:\BaiduNetdiskDownload\2022黑马\黑马旅游\实战篇\学习资料\day02-SpringCloud02\讲义\assets\image-20210714170337448.png)]

在页面访问，可以看到效果：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SP1Zgp61-1685800252532)(E:\BaiduNetdiskDownload\2022黑马\黑马旅游\实战篇\学习资料\day02-SpringCloud02\讲义\assets\image-20210714170449612.png)]

配置热更新

在@Value注入的变量所在类上添加注解@RefreshScope：

配置共享的优先级

当nacos、服务本地同时出现相同属性时，优先级有高低之分：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UT6ETfh7-1685800252533)(E:\BaiduNetdiskDownload\2022黑马\黑马旅游\实战篇\学习资料\day02-SpringCloud02\讲义\assets\image-20210714174623557.png)]

其实微服务启动时，会去nacos读取多个配置文件，而服务器名称.yaml不包含环境，因此可以被多个环境共享。

搭建Nacos集群

Nacos生产环境下一定要部署为集群状态，

其中包含3个nacos节点，然后一个负载均衡器代理3个Nacos。这里负载均衡器可以使用nginx。

我们计划的集群结构：

搭建集群的基本步骤：

搭建数据库，初始化数据库表结构，Nacos默认数据存储在内嵌数据库Derby中，不属于生产可用的数据库。

官方推荐的最佳实践是使用带有主从的高可用数据库集群。
下载nacos安装包
配置nacos，进入nacos的conf目录，修改配置文件cluster.conf.example，重命名为cluster.conf：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1JOH1xum-1685800252533)(E:\BaiduNetdiskDownload\2022黑马\黑马旅游\实战篇\学习资料\day02-SpringCloud02\资料\assets\image-20210409212459292.png)]

然后添加内容：
```
127.0.0.1:8845
127.0.0.1.8846
127.0.0.1.8847
```
然后修改application.properties文件，添加数据库配置
```
spring.datasource.platform=mysql
db.num=1
db.url.0=jdbc:mysql://127.0.0.1:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC
db.user.0=root
db.password.0=123
```
启动nacos集群，将nacos文件夹复制三份，分别命名为：nacos1、nacos2、nacos3分别启动。

nginx反向代理

修改conf/nginx.conf文件，配置如下：

upstream nacos-cluster {
    server 127.0.0.1:8845;
	server 127.0.0.1:8846;
	server 127.0.0.1:8847;
}
server {
    listen       80;
    server_name  localhost;
    location /nacos {
        proxy_pass http://nacos-cluster;
    }
}

而后在浏览器访问：http://localhost/nacos即可。

代码中application.yml文件配置如下：

spring:
  cloud:
    nacos:
      server-addr: localhost:80 # Nacos地址

注意，集群之后只需要指定集群的Nginx的地址即可，不需要给定微服务的服务名称！

OpenFeign远程调用

先来看我们以前利用RestTemplate发起远程调用的代码：

存在下面的问题：

代码可读性差，编程体验不统一
参数复杂URL难以维护

Feign是一个声明式的http客户端，其作用就是帮助我们优雅的实现http请求的发送，解决上面提到的问题。

Feign替代RestTemplate

引入依赖

我们在order-service服务的pom文件中引入feign的依赖：

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

添加注解

在order-service的启动类添加注解开启Feign的功能：

编写Feign的客户端

在order-service中新建一个接口，内容如下：

import cn.itcast.order.pojo.User;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;

@FeignClient("userservice")
public interface UserClient {
    @GetMapping("/user/{id}")
    User findById(@PathVariable("id") Long id);
}

这个客户端主要是基于SpringMVC的注解来声明远程调用的信息，比如：

服务名称：userservice
请求方式：GET
请求路径：/user/{id}
请求参数：Long id
返回值类型：User

这样，Feign就可以帮助我们发送http请求，无需自己使用RestTemplate来发送了。修改order-service中的OrderService类中的queryOrderById方法，使用Feign客户端代替RestTemplate：

总结：使用Feign的步骤：

① 引入依赖

② 添加@EnableFeignClients注解

③ 编写FeignClient接口

④ 使用FeignClient中定义的方法代替RestTemplate

自定义配置

Feign可以支持很多的自定义配置，如下表所示：

类型	作用	说明
feign.Logger.Level	修改日志级别	包含四种不同的级别：NONE、BASIC、HEADERS、FULL
feign.codec.Decoder	响应结果的解析器	http远程调用的结果做解析，例如解析json字符串为java对象
feign.codec.Encoder	请求参数编码	将请求参数编码，便于通过http请求发送
feign. Contract	支持的注解格式	默认是SpringMVC的注解
feign. Retryer	失败重试机制	请求失败的重试机制，默认是没有，不过会使用Ribbon的重试

一般情况下，默认值就能满足我们使用，如果要自定义时，只需要创建自定义的@Bean覆盖默认Bean即可。

下面以日志为例来演示如何自定义配置。

配置文件方式

基于配置文件修改feign的日志级别可以针对单个服务：

feign:  
  client:
    config: 
      userservice: # 针对某个微服务的配置
        loggerLevel: FULL #  日志级别

也可以针对所有服务：

feign:  
  client:
    config: 
      default: # 这里用default就是全局配置，如果是写服务名称，则是针对某个微服务的配置
        loggerLevel: FULL #  日志级别

而日志的级别分为四种：

NONE：不记录任何日志信息，这是默认值。
BASIC：仅记录请求的方法，URL以及响应状态码和执行时间
HEADERS：在BASIC的基础上，额外记录了请求和响应的头信息
FULL：记录所有请求和响应的明细，包括头信息、请求体、元数据。

Feign使用优化

Feign底层发起http请求，依赖于其它的框架。其底层客户端实现包括：

URLConnection：默认实现，不支持连接池
Apache HttpClient ：支持连接池
OKHttp：支持连接池

因此提高Feign的性能主要手段就是使用连接池代替默认的URLConnection。

这里我们用Apache的HttpClient来演示。

1）引入依赖

在order-service的pom文件中引入Apache的HttpClient依赖：

<!--httpClient的依赖 -->
<dependency>
    <groupId>io.github.openfeign</groupId>
    <artifactId>feign-httpclient</artifactId>
</dependency>

2）配置连接池

在order-service的application.yml中添加配置：

feign:
  client:
    config:
      default: # default全局的配置
        loggerLevel: BASIC # 日志级别，BASIC就是基本的请求和响应信息
  httpclient:
    enabled: true # 开启feign对HttpClient的支持
    max-connections: 200 # 最大的连接数
    max-connections-per-route: 50 # 每个路径的最大连接数

总结，Feign的优化：

日志级别尽量用basic
使用HttpClient或OKHttp代替URLConnection

① 引入feign-httpClient依赖

② 配置文件开启httpClient功能，设置连接池参数

Gateway网关服务

gateway 它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。网关的核心功能特性：请求路由、权限控制、限流。

权限控制：网关作为微服务入口，需要校验用户是是否有请求资格，如果没有则进行拦截。

路由和负载均衡：一切请求都必须先经过gateway，但网关不处理业务，而是根据某种规则，把请求转发到某个微服务，这个过程叫做路由。当然路由的目标服务有多个时，还需要做负载均衡。

限流：当请求流量过高时，在网关中按照下流的微服务能够接受的速度来放行请求，避免服务压力过大。

快速入门

基本步骤如下：

创建SpringBoot工程gateway，引入网关依赖

引入依赖：

<!--网关-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<!--nacos服务发现依赖-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

编写启动类

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class GatewayApplication {
	public static void main(String[] args) {
		SpringApplication.run(GatewayApplication.class, args);
	}
}

编写基础配置和路由规则

创建application.yml文件，内容如下：

server:
  port: 10010 # 网关端口
spring:
  application:
    name: gateway # 服务名称
  cloud:
    nacos:
      server-addr: localhost:8848 # nacos地址
    gateway:
      routes: # 网关路由配置
        - id: user-service # 路由id，自定义，只要唯一即可
          # uri: http://127.0.0.1:8081 # 路由的目标地址 http就是固定地址
          uri: lb://userservice # 路由的目标地址 lb就是负载均衡，后面跟服务名称
          predicates: # 路由断言，也就是判断请求是否符合路由规则的条件
            - Path=/user/** # 这个是按照路径匹配，只要以/user/开头就符合要求

我们将符合Path 规则的一切请求，都代理到 uri参数指定的地址。本例中，我们将 /user/**开头的请求，代理到lb://userservice，lb是负载均衡，根据服务名拉取服务列表，实现负载均衡。

启动网关服务进行测试

整个访问的流程如下：

总结：

网关搭建步骤：

创建项目，引入nacos服务发现和gateway依赖
配置application.yml，包括服务基本信息、nacos地址、路由

路由配置包括：

路由id：路由的唯一标示
路由目标（uri）：路由的目标地址，http代表固定地址，lb代表根据服务名负载均衡
路由断言（predicates）：判断路由的规则，
路由过滤器（filters）：对请求或响应做处理

断言工厂

我们在配置文件中写的断言规则只是字符串，这些字符串会被Predicate Factory读取并处理，转变为路由判断的条件

例如Path=/user/**是按照路径匹配，这个规则是由

org.springframework.cloud.gateway.handler.predicate.PathRoutePredicateFactory类来

处理的，像这样的断言工厂在SpringCloudGateway还有十几个:

名称	说明	示例
After	是某个时间点后的请求	- After=2037-01-20T17:42:47.789-07:00[America/Denver]
Before	是某个时间点之前的请求	- Before=2031-04-13T15:14:47.433+08:00[Asia/Shanghai]
Between	是某两个时间点之前的请求	- Between=2037-01-20T17:42:47.789-07:00[America/Denver], 2037-01-21T17:42:47.789-07:00[America/Denver]
Cookie	请求必须包含某些cookie	- Cookie=chocolate, ch.p
Header	请求必须包含某些header	- Header=X-Request-Id, \d+
Host	请求必须是访问某个host（域名）	- Host=.somehost.org,.anotherhost.org
Method	请求方式必须是指定方式	- Method=GET,POST
Path	请求路径必须符合指定规则	- Path=/red/{segment},/blue/**
Query	请求参数必须包含指定参数	- Query=name, Jack或者- Query=name
RemoteAddr	请求者的ip必须是指定范围	- RemoteAddr=192.168.1.1/24
Weight	权重处理

After、Before在某个时间之后、之前才可以访问，可以使用前面的Nacos配置管理来进行动态修改热部署。

过滤器工厂

GatewayFilter是网关中提供的一种过滤器，可以对进入网关的请求和微服务返回的响应做处理：

路由过滤器的种类

Spring提供了31种不同的路由过滤器工厂。例如：

名称	说明
AddRequestHeader	给当前请求添加一个请求头
RemoveRequestHeader	移除请求中的一个请求头
AddResponseHeader	给响应结果中添加一个响应头
RemoveResponseHeader	从响应结果中移除有一个响应头
RequestRateLimiter	限制请求的流量

请求头过滤器

下面我们以AddRequestHeader 为例来讲解。

需求：给所有进入userservice的请求添加一个请求头：Truth=awesome

只需要修改gateway服务的application.yml文件，添加路由过滤即可：

spring:
  cloud:
    gateway:
      routes:
      - id: user-service 
        uri: lb://userservice 
        predicates: 
        - Path=/user/** 
        filters: # 过滤器
        - AddRequestHeader=Truth,awesome # 添加请求头

当前过滤器写在userservice路由下，因此仅仅对访问userservice的请求有效。

默认过滤器

如果要对所有的路由都生效，则可以将过滤器工厂写到default下。格式如下：

spring:
  cloud:
    gateway:
      routes:
      - id: user-service 
        uri: lb://userservice 
        predicates: 
        - Path=/user/** # 路由过滤器
      default-filters: # 默认过滤器
      - AddRequestHeader=Truth,awesome

总结

过滤器的作用是什么？

① 对路由的请求或响应做加工处理，比如添加请求头

② 配置在路由下的过滤器只对当前路由的请求生效

defaultFilters的作用是什么？

① 对所有路由都生效的过滤器

全局过滤器

上一节学习的过滤器，网关提供了31种，但每一种过滤器的作用都是固定的。如果我们希望拦截请求，做自己的业务逻辑则没办法实现。

全局过滤器作用

全局过滤器的作用也是处理一切进入网关的请求和微服务响应，与GatewayFilter的作用一样。区别在于GatewayFilter通过配置定义，处理逻辑是固定的；而GlobalFilter的逻辑需要自己写代码实现。

定义方式是实现GlobalFilter接口。

public interface GlobalFilter {
    /**
     *  处理当前请求，有必要的话通过{@link GatewayFilterChain}将请求交给下一个过滤器处理
     *
     * @param exchange 请求上下文，里面可以获取Request、Response等信息
     * @param chain 用来把请求委托给下一个过滤器 
     * @return {@code Mono<Void>} 返回标示当前过滤器业务结束
     */
    Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
}

在filter中编写自定义逻辑，可以实现下列功能：

登录状态判断
权限校验
请求限流等

自定义全局过滤器

需求：定义全局过滤器，拦截请求，判断请求的参数是否满足下面条件：

参数中是否有authorization，
authorization参数值是否为admin

如果同时满足则放行，否则拦截实现：

在gateway中定义一个过滤器：

import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.core.annotation.Order;
import org.springframework.http.HttpStatus;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

@Order(-1)
@Component
public class AuthorizeFilter implements GlobalFilter {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 1.获取请求参数
        MultiValueMap<String, String> params = exchange.getRequest().getQueryParams();
        // 2.获取authorization参数
        String auth = params.getFirst("authorization");
        // 3.校验
        if ("admin".equals(auth)) {
            // 放行
            return chain.filter(exchange);
        }
        // 4.拦截
        // 4.1.禁止访问，设置状态码
        exchange.getResponse().setStatusCode(HttpStatus.FORBIDDEN);
        // 4.2.结束处理
        return exchange.getResponse().setComplete();
    }
}

过滤器执行顺序

请求进入网关会碰到三类过滤器：当前路由的过滤器、DefaultFilter、GlobalFilter。请求路由后，会将当前路由过滤器和DefaultFilter、GlobalFilter，合并到一个过滤器链（集合）中，排序后依次执行每个过滤器：

排序的规则是什么呢？

每一个过滤器都必须指定一个int类型的order值，order值越小，优先级越高，执行顺序越靠前。
GlobalFilter通过实现Ordered接口，或者添加@Order注解来指定order值，由我们自己指定
路由过滤器和defaultFilter的order由Spring指定，默认是按照声明顺序从1递增。
当过滤器的order值一样时，会按照 defaultFilter > 路由过滤器 > GlobalFilter的顺序执行。

跨域问题

跨域问题：浏览器禁止请求的发起者与服务端发生跨域（域名或者端口不同）ajax请求，请求被浏览器拦截的问题。

在gateway服务的application.yml文件中，添加下面的配置：

spring:
  cloud:
    gateway:
      # 。。。
      globalcors: # 全局的跨域处理
        add-to-simple-url-handler-mapping: true # 解决options请求被拦截问题
        corsConfigurations:
          '[/**]':
            allowedOrigins: # 允许哪些网站的跨域请求 
              - "http://localhost:8090"
            allowedMethods: # 允许的跨域ajax的请求方式
              - "GET"
              - "POST"
              - "DELETE"
              - "PUT"
              - "OPTIONS"
            allowedHeaders: "*" # 允许在请求中携带的头信息
            allowCredentials: true # 是否允许携带cookie
            maxAge: 360000 # 这次跨域检测的有效期

Sentinel 服务降级|保护

微服务存在的问题

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

雪崩解决方案

超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待.
线程隔离：我们可以限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。
断路器：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。断路器会统计访问某个服务的请求数量，异常比例，当发现访问服务D的请求异常比例过高时，认为服务D有导致雪崩的风险，会拦截访问服务D的一切请求，形成熔断：当发现访问服务D的请求异常比例过高时，认为服务D有导致雪崩的风险，会拦截访问服务D的一切请求，形成熔断：
限流：流量控制，限制业务访问的QPS，避免服务因流量的突增而故障。

可以认为：限流是对服务的保护，避免因瞬间高并发流量而导致服务故障，进而避免雪崩。是一种预防措施。

超时处理、线程隔离、降级熔断是在部分服务故障时，将故障控制在一定范围，避免雪崩。是一种补救措施。

微服务整合Sentinel

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

1）引入sentinel依赖

<!--sentinel-->
<dependency>
    <groupId>com.alibaba.cloud</groupId> 
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

2）配置控制台

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

server:
  port: 8088
spring:
  cloud: 
    sentinel:
      transport:
        dashboard: localhost:8080

3）访问order-service的任意端点

打开浏览器，访问http://localhost:8088/order/101，这样才能触发sentinel的监控。

流量控制

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

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-O49XceF4-1685800252534)(E:/BaiduNetdiskDownload/2022黑马/黑马旅游/高级篇/day01-微服务保护/讲义/assets/image-20210715191757319.png)]

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

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

流控模式

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

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8qZYMMlA-1685800252535)(E:/BaiduNetdiskDownload/2022黑马/黑马旅游/高级篇/day01-微服务保护/讲义/assets/image-20210715201827886.png)]

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

配置规则：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hiZmRxT6-1685800252535)(E:/BaiduNetdiskDownload/2022黑马/黑马旅游/高级篇/day01-微服务保护/讲义/assets/image-20210715202540786.png)]

语法说明：当/write资源访问量触发阈值时，就会对/read资源限流，避免影响/write资源。

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

满足以下规则适用关联：

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

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

配置示例：

例如有两条请求链路：

/test1 --> /common
/test2 --> /common

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

实战案例

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

流控效果

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-U0CB8DnH-1685800252536)(E:/BaiduNetdiskDownload/2022黑马/黑马旅游/高级篇/day01-微服务保护/讲义/assets/image-20210716110225104.png)]

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

快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值。例如，我设置QPS的maxThreshold为10，预热时间为5秒，那么初始阈值就是 10 / 3 ，也就是3，然后在5秒后逐渐增长到10
排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长；当请求超过QPS阈值时，快速失败和warm up 会拒绝新的请求并抛出异常。而排队等待则是让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成，如果请求预期的等待时间超出最大时长，则会被拒绝。

工作原理

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

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

比如现在一下子来了12 个请求，因为每200ms执行一个请求，那么：
- 第6个请求的预期等待时长 = 200 * （6 - 1） = 1000ms
- 第12个请求的预期等待时长 = 200 * （12-1） = 2200ms
现在，第1秒同时接收到10个请求，但第2秒只有1个请求，此时QPS的曲线这样的：

如果使用队列模式做流控，所有进入的请求都要排队，以固定的200ms的间隔执行，QPS会变的很平滑：

平滑的QPS曲线，对于服务器来说是更友好的。

总结

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

热点参数限流

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

全局参数限流

例如，一个根据id查询商品的接口：

访问/goods/{id}的请求中，id参数值会有变化，热点参数限流会根据参数值分别统计QPS，统计结果：

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

配置示例：

隔离和降级

限流是一种预防措施，虽然限流可以尽量避免因高并发而引起的服务故障，但服务还会因为其它原因而故障。而要将这些故障控制在一定范围，避免雪崩，就要靠线程隔离（舱壁模式）和熔断降级手段了。而我们的微服务远程调用都是基于Feign来完成的，因此我们需要将Feign与Sentinel整合，在Feign里面实现线程隔离和服务熔断。

修改配置，开启sentinel功能

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

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

编写失败降级逻辑

业务失败后，不能直接报错，而应该返回用户一个友好提示或者默认结果，这个就是失败降级逻辑。给FeignClient编写失败后的降级逻辑；实现FallbackFactory，可以对远程调用的异常做处理。

import cn.itcast.feign.clients.UserClient;
import cn.itcast.feign.pojo.User;
import feign.hystrix.FallbackFactory;
import lombok.extern.slf4j.Slf4j;

@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();
            }
        };
    }
}

在feing-api项目中的DefaultFeignConfiguration类中将UserClientFallbackFactory注册为一个Bean：

@Bean
public UserClientFallbackFactory userClientFallbackFactory(){
    return new UserClientFallbackFactory();
}

步骤三：在feing-api项目中的UserClient接口中使用UserClientFallbackFactory：

import cn.itcast.feign.clients.fallback.UserClientFallbackFactory;
import cn.itcast.feign.pojo.User;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;

@FeignClient(value = "userservice", fallbackFactory = UserClientFallbackFactory.class)
public interface UserClient {
    @GetMapping("/user/{id}")
    User findById(@PathVariable("id") Long id);
}

总结

Sentinel支持的雪崩解决方案：

线程隔离（仓壁模式）
降级熔断

Feign整合Sentinel的步骤：

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

线程隔离

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

线程池隔离
信号量隔离（Sentinel默认采用）

如图：

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

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

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

QPS：就是每秒的请求数，在快速入门中已经演示过
线程数：是该资源能使用用的tomcat线程数的最大值。也就是通过限制线程数量，实现线程隔离（舱壁模式）。

总结

线程隔离的两种手段是？

信号量隔离
线程池隔离

信号量隔离的特点是？

基于计数器模式，简单，开销小

线程池隔离的特点是？

基于线程池模式，有额外开销，但隔离控制更强

熔断降级

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

状态机包括三个状态：

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

断路器熔断策略有三种：慢调用、异常比例、异常数

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

例如：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HBqt71TU-1685800252536)(E:/BaiduNetdiskDownload/2022黑马/黑马旅游/高级篇/day01-微服务保护/讲义/assets/image-20210716145934347.png)]

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

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

例如，一个异常比例设置：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ePGxemgD-1685800252537)(E:/BaiduNetdiskDownload/2022黑马/黑马旅游/高级篇/day01-微服务保护/讲义/assets/image-20210716131430682.png)]

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

异常数设置：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uKpKEZKC-1685800252537)(E:/BaiduNetdiskDownload/2022黑马/黑马旅游/高级篇/day01-微服务保护/讲义/assets/image-20210716131522912.png)]

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

授权规则

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

白名单：来源（origin）在白名单内的调用者允许访问
黑名单：来源（origin）在黑名单内的调用者不允许访问

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oqfqAKC6-1685800252537)(E:/BaiduNetdiskDownload/2022黑马/黑马旅游/高级篇/day01-微服务保护/讲义/assets/image-20210716152010750.png)]

资源名：就是受保护的资源，例如/order/{orderId}
流控应用：是来源者的名单，
- 如果是勾选白名单，则名单中的来源被许可访问。
- 如果是勾选黑名单，则名单中的来源被禁止访问。

比如：[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Iky8mN0M-1685800252538)(E:/BaiduNetdiskDownload/2022黑马/黑马旅游/高级篇/day01-微服务保护/讲义/assets/image-20210716152349191.png)]

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

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

这个需要利用之前学习的一个GatewayFilter来实现，AddRequestHeaderGatewayFilter。

修改gateway服务中的application.yml，添加一个defaultFilter：

spring:
  cloud:
    gateway:
      default-filters:
        - AddRequestHeader=origin,gateway
      routes:
       # ...略

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

配置授权规则

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4sX42U10-1685800252538)(E:/BaiduNetdiskDownload/2022黑马/黑马旅游/高级篇/day01-微服务保护/讲义/assets/image-20210716153250134.png)]

配置如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xnCjqU8c-1685800252538)(E:/BaiduNetdiskDownload/2022黑马/黑马旅游/高级篇/day01-微服务保护/讲义/assets/image-20210716153301069.png)]

现在，我们直接跳过网关，访问order-service服务，会返回错误；而只有通过gateway才能正常访问。

自定义异常结果

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

异常类型

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

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

这个方法有三个参数：

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

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

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

自定义异常处理

下面，我们就在order-service定义一个自定义异常处理类：文章来源地址https://www.toymoban.com/news/detail-472531.html

import com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.BlockExceptionHandler;
import com.alibaba.csp.sentinel.slots.block.BlockException;
import com.alibaba.csp.sentinel.slots.block.authority.AuthorityException;
import com.alibaba.csp.sentinel.slots.block.degrade.DegradeException;
import com.alibaba.csp.sentinel.slots.block.flow.FlowException;
import com.alibaba.csp.sentinel.slots.block.flow.param.ParamFlowException;
import org.springframework.stereotype.Component;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@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 + "}");
    }
}