Spring Cloud Alibaba 笔记

文章目录

前言
第一节 SCA Nacos 服务注册和配置中⼼
- 1.1 Nacos 介绍
- 1.2 Nacos 单例服务部署
- 1.3 Nacos 服务注册中⼼
- - 1.3.1 服务提供者注册到 Nacos(改造简历微服务)
  - 1.3.2 服务消费者从 Nacos 获取服务提供者(改造⾃动投递微服务)
  - 1.3.3 负载均衡
  - 1.3.4 Nacos 数据模型（领域模型）
  - 1.3.5 Nacos Server 数据持久化
  - 1.3.6 Nacos Server 集群
- 1.4 Nacos 配置中⼼
第二节 SCA Sentinel 分布式系统的流量防卫兵
- 2.1 Sentinel 介绍
- 2.2 Sentinel 部署
- 2.3 Sentinel 服务改造
- 2.4 Sentinel 关键概念
- 2.5 Sentinel 流量规则模块
- 2.6 Sentinel 降级规则模块
- 2.7 Sentinel 其他模块了解
- 2.8 Sentinel ⾃定义兜底逻辑
- 2.9 基于 Nacos 实现 Sentinel 规则持久化
第三节 Nacos + Sentinel + Dubbo 三剑合璧
- 3.1 服务提供者⼯程改造
- 3.2 服务消费者⼯程改造
第四节 SCA ⼩结
总结
- Spring Cloud
- Spring Cloud Alibaba

前言

第⼀代 Spring Cloud （主要是 SCN）很多组件已经进⼊停更维护模式。

Spring Cloud：Netﬂix，Spring 官⽅，SCA（被 Spring 官⽅认可）

注意：市场上主要使⽤的还是 SCN，SCA ⼀套框架的集合

Alibaba 更进⼀步，搞出了 Spring Cloud Alibaba（SCA），SCA 是由⼀些阿⾥巴巴的开源组件和云产品组成的，2018 年，Spring Cloud Alibaba 正式⼊住了 Spring Cloud 官⽅孵化器。

Nacos（服务注册中⼼、配置中⼼）
Sentinel 哨兵（服务的熔断、限流等）
Dubbo RPC/LB
Seata 分布式事务解决⽅案

注意

不要下载最新版本的，不要下载最新版本的，不要下载最新版本的

nacos2.02 版本集群修改了 20 次，还是要么启动成功一个要么启动成功两个，浪费了一个多小时，还是有服务端启动问题

更换成 1.2 版本的一次直接 OK

第一节 SCA Nacos 服务注册和配置中⼼

1.1 Nacos 介绍

Nacos （Dynamic Naming and Conﬁguration Service）是阿⾥巴巴开源的⼀个针对微服务架构中服务发现、配置管理和服务管理平台。 Nacos 就是注册中⼼ + 配置中⼼的组合（Nacos=Eureka+Conﬁg+Bus）

官⽹：https://nacos.io 下载地址：https://github.com/alibaba/Nacos

Nacos 功能特性

服务发现与健康检查

动态配置管理

动态 DNS 服务

服务和元数据管理（管理平台的⻆度，nacos 也有⼀个 ui ⻚⾯，可以看到注册的服务及其实例信息（元数据信息）等），动态的服务权重调整、动态服务优雅下线，都可以去做

1.2 Nacos 单例服务部署

下载解压安装包，执⾏命令启动（我们使⽤最近⽐较稳定的版本 nacos-server-1.2.0.tar.gz）

必须加上 -m standalone

#linux/mac：
sh startup.sh -m standalone
#windows：
cmd startup.cmd

访问 nacos 管理界⾯：http://127.0.0.1:8848/nacos/#/login（默认端⼝ 8848，账号和密码 nacos/nacos）

1.3 Nacos 服务注册中⼼

1.3.1 服务提供者注册到 Nacos(改造简历微服务)

在原有的微服务上面复制一份 resuem-8082

在⽗ pom 中引⼊ SCA 依赖

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

在服务提供者⼯程中引⼊ nacos 客户端依赖（注释 eureka 客户端）

  <!--nacos service discovery client依赖--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId></dependency>

application.yml 修改，添加 nacos 配置信息

server:port: 8082
spring:application:name: lane-service-resumedatasource:driver-class-name: com.mysql.jdbc.Driverurl: jdbc:mysql://localhost:3306/lagou?useUnicode=true&characterEncoding=utf8username: rootpassword: rootjpa:database: MySQLshow-sql: truehibernate:naming:physical-strategy: org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl  #避免将驼峰命名转换为下划线命名#nacos 配置cloud:nacos:discovery:server-addr: 127.0.0.1:8848# springboot中暴露健康检查等断点接口
management:endpoints:web:exposure:include: "*"# 暴露健康接口的细节endpoint:health:show-details: always

启动简历微服务，观察 nacos 控制台

保护阈值：可以设置为 0-1 之间的浮点数，它其实是⼀个⽐例值（当前服务健康实例数/当前服务总实例数）

场景：

⼀般流程下，nacos 是服务注册中⼼，服务消费者要从 nacos 获取某⼀个服务的可⽤实例信息，对于服务实例有健康/不健康状态之分，nacos 在返回给消费者实例信息的时候，会返回健康实例。这个时候在⼀些⾼并发、⼤流量场景下会存在⼀定的问题

如果服务 A 有 100 个实例，98 个实例都不健康了，只有 2 个实例是健康的，如果 nacos 只返回这两个健康实例的信息的话，那么后续消费者的请求将全部被分配到这两个实例，流量洪峰到来，2 个健康的实例也扛不住了，整个服务 A 就扛不住，上游的微服务也会导致崩溃，产⽣雪崩效应。

保护阈值的意义在于

当服务 A 健康实例数/总实例数 < 保护阈值的时候，说明健康实例真的不多了，这个时候保护阈值会被触发（状态 true）

nacos 将会把该服务所有的实例信息（健康的 + 不健康的）全部提供给消费者，消费者可能访问到不健康的实例，请求失败，但这样也⽐造成雪崩要好，牺牲了⼀些请求，保证了整个系统的⼀个可⽤。

注意：阿⾥内部在使⽤ nacos 的时候，也经常调整这个保护阈值参数。

1.3.2 服务消费者从 Nacos 获取服务提供者(改造⾃动投递微服务)

把原有的 8096 服务复制一份修改依赖配置文件及启动类，删除一些不需要的类

依赖修改后

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><parent><artifactId>lane-parent-project</artifactId><groupId>com.galaxy</groupId><version>1.0-SNAPSHOT</version></parent><modelVersion>4.0.0</modelVersion><artifactId>lane-service-autodeliver-8097-nacos</artifactId><dependencies><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-openfeign</artifactId></dependency><!--nacos service discovery client依赖--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId></dependency></dependencies>
</project>

配置文件修改后

server:port: 8097
spring:application:name: lane-service-autodelivercloud:nacos:discovery:server-addr: 127.0.0.1:8848# springboot中暴露健康检查等断点接口
management:endpoints:web:exposure:include: "*"# 暴露健康接口的细节endpoint:health:show-details: always
#针对的被调用方微服务名称,不加就是全局生效
lane-service-resume:ribbon:#请求连接超时时间ConnectTimeout: 20000#请求处理超时时间##########################################Feign超时时长设置ReadTimeout: 30000#对所有操作都进行重试OkToRetryOnAllOperations: true####根据如上配置，当访问到故障请求的时候，它会再尝试访问一次当前实例（次数由MaxAutoRetries配置），####如果不行，就换一个实例进行访问，如果还不行，再换一次实例访问（更换次数由MaxAutoRetriesNextServer配置），####如果依然不行，返回失败信息。MaxAutoRetries: 0 #对当前选中实例重试次数，不包括第一次调用MaxAutoRetriesNextServer: 0 #切换实例的重试次数NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule #负载策略调整
logging:level:# Feign日志只会对日志级别为debug的做出响应com.galaxy.service.ResumeServiceFeignClient: debug
# 开启Feign的熔断功能
feign:hystrix:enabled: true
hystrix:command:default:execution:isolation:thread:##########################################Hystrix的超时时长设置timeoutInMilliseconds: 60000

启动报错，clean 一下之后测试，测试页面

查看订阅者列表如下

1.3.3 负载均衡

Nacos 客户端引⼊的时候，会关联引⼊ Ribbon 的依赖包，我们使⽤ OpenFiegn 的时候也会引⼊ Ribbon 的依赖，Ribbon 包括 Hystrix 都按原来⽅式进⾏配置即可

此处，我们将简历微服务复制一份 8083，启动了⼀个 8083 端⼝，注册到 Nacos 上，便于测试负载均衡，我们通过后台也可以看出。

1.3.4 Nacos 数据模型（领域模型）

Namespace 命名空间、Group 分组、集群这些都是为了进⾏归类管理，把服务和配置⽂件进⾏归类，归类之后就可以实现⼀定的效果，⽐如隔离

⽐如，对于服务来说，不同命名空间中的服务不能够互相访问调⽤

Namespace：命名空间，对不同的环境进⾏隔离，⽐如隔离开发环境、测试环境和⽣产环境

Group：分组，将若⼲个服务或者若⼲个配置集归为⼀组，通常习惯⼀个系统归为⼀个组

Service：某⼀个服务，⽐如简历微服务

DataId：配置集或者可以认为是⼀个配置⽂件

Namespace + Group + Service 如同 Maven 中的 GAV 坐标，GAV 坐标是为了锁定 Jar，这⾥是为了锁定服务

Namespace + Group + DataId 如同 Maven 中的 GAV 坐标，GAV 坐标是为了锁定 Jar，这⾥是为了锁定配置⽂件

最佳实践 Nacos 抽象出了 Namespace、Group、Service、DataId 等概念，具体代表什么取决于怎么⽤（⾮常灵活），推荐⽤法如下

可以通过配置文件修改 namespace，不同 namespace 不可以互相调用，比如测试环境和线上环境

Nacos 服务的分级模型

1.3.5 Nacos Server 数据持久化

Nacos 默认使⽤嵌⼊式数据库进⾏数据存储，它⽀持改为外部 Mysql 存储

新建数据库 nacos_conﬁg

执行数据库初始化脚本⽂件/conf/nacos-mysql.sql

修改/conf/application.properties 增加 Mysql 数据源配置

#*************** Config Module Related Configurations ***************#
### If use MySQL as datasource:
spring.datasource.platform=mysql### Count of DB:
db.num=1### Connect URL of DB:
db.url.0=jdbc:mysql://127.0.0.1:3306/nacos_config?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC
db.user.0=root
db.password.0=root

在网页端添加一条用户信息可以持久化到数据库当中，下次重启就不会再丢失掉了

1.3.6 Nacos Server 集群

安装 3 个或 3 个以上的 Nacos 复制解压后的 nacos ⽂件夹，分别命名为 nacos-01、nacos-02、nacos-03

修改配置⽂件

同⼀台机器模拟，将上述三个⽂件夹中 application.properties 中的 server.port 分别改为 8848、8849、8850 同时给当前实例节点绑定 ip，因为服务器可能绑定多个 ip

nacos.inetutils.ip-address=127.0.0.1

复制⼀份 conf/cluster.conf.example ⽂件，命名为 cluster.conf 在配置⽂件中设置集群中每⼀个节点的信息

# 集群节点配置127.0.0.1:8848127.0.0.1:8849127.0.0.1:8850

分别启动每⼀个实例（可以批处理脚本完成）

sh startup.sh -m cluster

1.4 Nacos 配置中⼼

Spring Cloud Conﬁg + Bus

Github 上添加配置⽂件
创建 Conﬁg Server 配置中⼼—> 从 Github 上去下载配置信息
具体的微服务(最终使⽤配置信息的)中配置 Conﬁg Client—> ConﬁgServer 获取配置信息

有 Nacos 之后，分布式配置就简单很多 Github 不需要了（配置信息直接配置在 Nacos server 中），Bus 也不需要了(依然可以完成动态刷新)

1、去 Nacos server 中添加配置信息

2、改造具体的微服务，使其成为 Nacos Conﬁg Client，能够从 Nacos Server 中获取到配置信息

Nacos server 添加配置集

注意：必须加上后缀名才可以不然项目启动不来的

Nacos 服务端已经搭建完毕，那么我们可以在我们的微服务中开启 Nacos 配置管理

1）添加依赖

     <!--nacos config client 依赖--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId></dependency>

2）微服务中如何锁定 Nacos Server 中的配置⽂件（dataId）通过 Namespace + Group + dataId 来锁定配置⽂件，Namespace 不指定就默认 public，Group 不指定就默认 DEFAULT_GROUP

dataId 的完整格式如下

${prefix}-${spring.profile.active}.${file-extension}

配置信息

  # nacos配置cloud:nacos:discovery:# 集群中各节点信息都配置在这里（域名-VIP-绑定映射到各个实例的地址信息）server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850# nacos config 配置config:server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850# 锁定server端的配置文件（读取它的配置项）namespace: ba4f6d66-3a09-4a1f-a602-f71ab862b517  # 命名空间idgroup: DEFAULT_GROUP  # 默认分组就是DEFAULT_GROUP，如果使用默认分组可以不配置file-extension: yaml   #默认properties# 根据规则拼接出来的dataId效果：lane-service-resume.yaml

3）通过 Spring Cloud 原⽣注解 @RefreshScope 实现配置⾃动更新

package com.galaxy.controller;/*** 该类用于模拟，我们要使用共享的那些配置信息做一些事情* @author lane* @date 2021年06月25日 上午11:25*/
@RestController
@RequestMapping("/config")
@RefreshScope
public class ConfigController {// 和取本地配置信息一样@Value("${lane.message}")private String message;@Value("${mysql.url}")private String url;// 内存级别的配置信息// 数据库，redis配置信息@GetMapping("/viewconfig")public String viewconfig() {return "laneMessage==>" + message  + " mysqlUrl=>" + url;}}

测试效果如下，且可以随着 nacos 服务端修改而动态的刷新

思考：⼀个微服务希望从配置中⼼ Nacos server 中获取多个 dataId 的配置信息，可以的，扩展多个 dataId

服务端添加配置信息

配置文件添加信息

  # nacos配置cloud:nacos:discovery:# 集群中各节点信息都配置在这里（域名-VIP-绑定映射到各个实例的地址信息）server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850# nacos config 配置config:server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850# 锁定server端的配置文件（读取它的配置项）namespace: ba4f6d66-3a09-4a1f-a602-f71ab862b517  # 命名空间idgroup: DEFAULT_GROUP  # 默认分组就是DEFAULT_GROUP，如果使用默认分组可以不配置file-extension: yaml   #默认properties# 根据规则拼接出来的dataId效果：lane-service-resume.yamlext-config[0]:data-id: abc.yamlgroup: DEFAULT_GROUPrefresh: true  #开启扩展dataId的动态刷新ext-config[1]:data-id: def.yamlgroup: DEFAULT_GROUPrefresh: true  #开启扩展dataId的动态刷新

测试效果

修改服务端配置文件内容秒刷新

优先级：根据规则⽣成的 dataId > 扩展的 dataId（对于扩展的 dataId，[n] n 越⼤优先级越⾼）

原配置项优先级最高，其次是最后的扩展项 def.yaml 依次向前是 abc.yaml，扩展项是倒着来的

第二节 SCA Sentinel 分布式系统的流量防卫兵

2.1 Sentinel 介绍

Sentinel 是⼀个⾯向云原⽣微服务的流量控制、熔断降级组件。替代 Hystrix，

针对问题：服务雪崩、服务降级、服务熔断、服务限流

Hystrix：

服务消费者（⾃动投递微服务）—> 调⽤服务提供者（简历微服务）

在调⽤⽅引⼊ Hystrix—> 单独搞了⼀个 Dashboard 项⽬—>Turbine

1）⾃⼰搭建监控平台 dashboard

2）没有提供 UI 界⾯进⾏服务熔断、服务降级等配置（⽽是写代码，⼊侵了我们源程序环境）

Sentinel：

1）独⽴可部署 Dashboard/控制台组件

2）减少代码开发，通过 UI 界⾯配置即可完成细粒度控制（⾃动投递微服务）

Sentinel 分为两个部分:

核⼼库：（Java 客户端）不依赖任何框架/库，能够运⾏于所有 Java 运⾏时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的⽀持。

控制台：（Dashboard）基于 Spring Boot 开发，打包后可以直接运⾏，不需要额外的 Tomcat 等应⽤容器。

Sentinel 具有以下特征:

**丰富的应⽤场景：**Sentinel 承接了阿⾥巴巴近 10 年的双⼗⼀⼤促流量的核⼼场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填⾕、集群流量控制、实时熔断下游不可⽤应⽤等。

**完备的实时监控：**Sentinel 同时提供实时的监控功能。您可以在控制台中看到接⼊应⽤的单台机器秒级数据，甚⾄ 500 台以下规模的集群的汇总运⾏情况。

**⼴泛的开源⽣态：**Sentinel 提供开箱即⽤的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo 的整合。您只需要引⼊相应的依赖并进⾏简单的配置即可快速地接⼊ Sentinel。

**完善的 SPI 扩展点：**Sentinel 提供简单易⽤、完善的 SPI 扩展接⼝。您可以通过实现扩展接⼝来快速地定制逻辑。例如定制规则管理、适配动态数据源等。

Sentinel 的主要特性：

Sentinel 的开源⽣态：

2.2 Sentinel 部署

下载地址：https://github.com/alibaba/Sentinel/releases 我们使⽤ v1.7.1

启动：java -jar sentinel-dashboard-1.7.1.jar & （添加&符号可以关闭终端仍然运行）

⽤户名/密码：sentinel/sentinel

默认端口号：8080

访问地址：localhost:8080

2.3 Sentinel 服务改造

在我们已有的业务场景中，“⾃动投递微服务”调⽤了“简历微服务”，我们在⾃动投递微服务进⾏的熔断降级等控制，那么接下来我们改造⾃动投递微服务，引⼊ Sentinel 核⼼包。

为了不污染之前的代码，复制⼀个⾃动投递微服务 lane-service-autodeliver8098-sentinel

pom.xml 引⼊依赖

 <!--sentinel 核心环境 依赖--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-sentinel</artifactId></dependency>

application.yml 修改（配置 sentinel dashboard，暴露断点依然要有，删除原有 hystrix 配置，删除原有 OpenFeign 的降级配置）

server:port: 8098
spring:application:name: lane-service-autodelivercloud:nacos:discovery:server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850sentinel:transport:dashboard: 127.0.0.1:8080 # sentinel dashboard/console 地址port: 8719   #  sentinel会在该端口启动http server，那么这样的话，控制台定义的一些限流等规则才能发送传递过来，#如果8719端口被占用，那么会依次+1
# springboot中暴露健康检查等断点接口
management:endpoints:web:exposure:include: "*"# 暴露健康接口的细节endpoint:health:show-details: always
#针对的被调用方微服务名称,不加就是全局生效
lane-service-resume:ribbon:#请求连接超时时间ConnectTimeout: 20000#请求处理超时时间##########################################Feign超时时长设置ReadTimeout: 30000#对所有操作都进行重试OkToRetryOnAllOperations: true####根据如上配置，当访问到故障请求的时候，它会再尝试访问一次当前实例（次数由MaxAutoRetries配置），####如果不行，就换一个实例进行访问，如果还不行，再换一次实例访问（更换次数由MaxAutoRetriesNextServer配置），####如果依然不行，返回失败信息。MaxAutoRetries: 0 #对当前选中实例重试次数，不包括第一次调用MaxAutoRetriesNextServer: 0 #切换实例的重试次数NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule #负载策略调整
logging:level:# Feign日志只会对日志级别为debug的做出响应com.galaxy.service.ResumeServiceFeignClient: debug

此时我们发现控制台没有任何变化，因为懒加载，我们只需要发起⼀次请求触发即可

2.4 Sentinel 关键概念

2.5 Sentinel 流量规则模块

系统并发能⼒有限，⽐如系统 A 的 QPS ⽀持 1 个，如果太多请求过来，那么 A 就应该进⾏流量控制了，⽐如其他请求直接拒绝

资源名：默认请求路径

针对来源：Sentinel 可以针对调⽤者进⾏限流，填写微服务名称，默认 default（不区分来源）

阈值类型/单机阈值 QPS：（每秒钟请求数量）当调⽤该资源的 QPS 达到阈值时进⾏限流

线程数：当调⽤该资源的线程数达到阈值的时候进⾏限流（线程处理请求的时候，如果说业务逻辑执⾏时间很⻓，流量洪峰来临时，会耗费很多线程资源，这些线程资源会堆积，最终可能造成服务不可⽤，进⼀步上游服务不可⽤，最终可能服务雪崩）

是否集群：是否集群限流

流控模式：

直接：资源调⽤达到限流条件时，直接限流

关联：关联的资源调⽤达到阈值时候限流⾃⼰

链路：只记录指定链路上的流量

流控效果：快速失败：直接失败，抛出异常

Warm Up：根据冷加载因⼦（默认 3）的值，从阈值/冷加载因⼦，经过预热时⻓，才达到设置的 QPS 阈值

排队等待：匀速排队，让请求匀速通过，阈值类型必须设置为 QPS，否则⽆效

流控模式之关联限流

关联的资源调⽤达到阈值时候限流⾃⼰，⽐如⽤户注册接⼝，需要调⽤身份证校验接⼝（往往身份证校验接⼝），如果身份证校验接⼝请求达到阈值，使⽤关联，可以对⽤户注册接⼝进⾏限流。

当两个接口之间有关联关系的时候，比如用户注册和身份证校验接口，当身份证校验接口达到阀值的时候，限制下用户注册的请求数，进而降低身份证校验接口的访问数，防止两者出现雪崩

流控模式之链路限流

链路指的是请求链路（调⽤链）链路模式下会控制该资源所在的调⽤链路⼊⼝的流量。需要在规则中配置⼊⼝资源，即该调⽤链路⼊⼝的上下⽂名称。⼀棵典型的调⽤树如下图所示：（阿⾥云提供）

当两个链路都调用统一个资源的时候，可以配置只统计限流某一条链路

流控效果之 Warm up

当系统⻓期处于空闲的情况下，当流量突然增加时，直接把系统拉升到⾼⽔位可能瞬间把系统压垮，⽐如电商⽹站的秒杀模块。通过 Warm Up 模式（预热模式），让通过的流量缓慢增加，经过设置的预热时间以后，到达系统处理请求速率的设定值。

Warm Up 模式默认会在预热时长内从设置的 QPS 阈值的 1/3 开始慢慢往上增加⾄ QPS 设置值 从而避免瞬间被流量洪峰压垮

流控效果之排队等待

排队等待模式下会严格控制请求通过的间隔时间，请求会匀速通过，允许部分请求排队等待，通常⽤于消息队列削峰填⾕等场景。需设置具体的超时时间，当计算的等待时间超过超时时间时请求就会被拒绝。

很多流量过来了，并不是直接拒绝请求，⽽是请求进⾏排队，⼀个⼀个匀速通过（处理），请求能等就等着被处理，不能等（等待时间 > 超时时间）就会被拒绝

QPS 配置为 5，则代表每秒允许 5 个请求请求，既是每 1/5=200 ms 才能匀速通过⼀个，多出的请求将排队等待通过。超时时间代表最⼤排队时间，超出最⼤排队时间的请求将会直接被拒绝。排队等待模式下，QPS 设置值不要超过 1000（请求间隔 1 ms）。

2.6 Sentinel 降级规则模块

流控是对外部来的⼤流量进⾏控制，熔断降级的视⻆是对内部问题进⾏处理。 Sentinel 降级会在调⽤链路中某个资源出现不稳定状态时（例如调⽤超时或异常⽐例升⾼），对这个资源的调⽤进⾏限制，让请求快速失败，避免影响到其它的资源⽽导致级联错误。当资源被降级后，在接下来的降级时间窗⼝之内，对该资源的调⽤都⾃动熔断

Hystrix 中的熔断

Sentinel 熔断策略

Sentinel 不会像 Hystrix 那样放过⼀个请求尝试⾃我修复，就是明明确确按照时间窗⼝来，熔断触发后，时间窗⼝内拒绝请求，时间窗⼝后就恢复。

RT（平均响应时间）

当 1s 内持续进⼊ >=5 个请求，平均响应时间超过阈值（以 ms 为单位），那么在接下的时间窗⼝（以 s 为单位）之内，对这个⽅法的调⽤都会⾃动地熔断（抛出 DegradeException）。注意 Sentinel 默认统计的 RT 上限是 4900 ms，超出此阈值的都会算作 4900 ms，若需要变更此上限可以通过启动配置项 Dcsp.sentinel.statistic.max.rt=xxx 来配置。

异常⽐例

当资源的每秒请求量 >= 5，并且每秒异常总数占通过量的⽐值超过阈值之后，资源进⼊降级状态，即在接下的时间窗⼝（以 s 为单位）之内，对这个⽅法的调⽤都会⾃动地返回。异常⽐率的阈值范围是 [0.0, 1.0] ，代表 0% - 100%。

异常数

当资源近 1 分钟的异常数⽬超过阈值之后会进⾏熔断。注意由于统计时间窗⼝是分钟级别的，若 timeWindow ⼩于 60s，则结束熔断状态后仍可能再进⼊熔断状态。

时间窗⼝ >= 60s

2.7 Sentinel 其他模块了解

系统规则是对整个机器配置降级规则，而不是单单一个微服务

授权规则是黑白名单，相对于自己的微服务

机器列表是微服务所在的机器 IP 及端口号

集群流控要修改控制台哦亲，这边建议您移步阿里云

2.8 jmeter 下载与使用

网站 https://jmeter.apache.org/download_jmeter.cgi

2.8 Sentinel ⾃定义兜底逻辑

@SentinelResource 注解类似于 Hystrix 中的 @HystrixCommand 注解

@SentinelResource 注解中有两个属性需要我们进⾏区分，blockHandler 属性⽤来指定不满⾜ Sentinel 规则的降级兜底⽅法，fallback 属性⽤于指定 Java 运⾏时异常兜底⽅法

第一步改造直接添加降级方法

package com.galaxy.controller;/*** @author lane* @date 2021年07月03日 10：47*/
@RestController
@RequestMapping("/autodeliver")
public class AutoDeliverController {@AutowiredResumeServiceFeignClient resumeServiceFeignClient;/*** @SentinelResource value：定义资源名* blockHandlerClass：指定Sentinel规则异常兜底逻辑所在class类* blockHandler：指定Sentinel规则异常兜底逻辑具体哪个⽅法* fallbackClass：指定Java运⾏时异常兜底逻辑所在class类* fallback：指定Java运⾏时异常兜底逻辑具体哪个⽅法*/@GetMapping("/checkState/{userId}")@SentinelResource(value = "findResumeOpenState",blockHandler = "handlerFailBack")public Integer findResumeOpenState(@PathVariable("userId") Long userId){Integer defaultResumeState1 = resumeServiceFeignClient.findDefaultResumeState(userId);return defaultResumeState1;}public Integer handlerFailBack(Long userId, BlockException blockException){return -1024;}
}

添加 QPS 流控

快速访问出现兜底方法的返回值

第二步改造降级方法添加到自定义类中

添加降级所在的类和方法，注意方法必须 static

package com.galaxy.config;import com.alibaba.csp.sentinel.slots.block.BlockException;/*** @author lane* @date 2021年07月03日 上午10:52*/
public class SentinelFallBack {// 整体要求和当时Hystrix一样，这里还需要在形参中添加BlockException参数，用于接收异常// 注意：方法是静态的public static Integer handleException(Long userId, BlockException blockException) {return -100;}
}

方法指定降级类所在的 class

第三步改造

对于 hystrix 当出现异常和流控熔断走的是同一个方法

但是对于 sentinel 则是走不同的方法

指定流控熔断降级的方法是要指定

blockHandlerClass = SentinelFallBack.class,
blockHandler = "handleException",

对于出现 Java 错误要指定的方法是

fallbackClass = SentinelFallBack.class,
fallback = "handleError"

具体代码实现如下

/*** @SentinelResource value：定义资源名* blockHandlerClass：指定Sentinel规则异常兜底逻辑所在class类* blockHandler：指定Sentinel规则异常兜底逻辑具体哪个⽅法* fallbackClass：指定Java运⾏时异常兜底逻辑所在class类* fallback：指定Java运⾏时异常兜底逻辑具体哪个⽅法*/@GetMapping("/checkState/{userId}")@SentinelResource(value = "findResumeOpenState",blockHandlerClass = SentinelFallBack.class,blockHandler = "handleException",fallbackClass = SentinelFallBack.class,fallback = "handleError")public Integer findResumeOpenState(@PathVariable("userId") Long userId){Integer defaultResumeState1 = resumeServiceFeignClient.findDefaultResumeState(userId);return defaultResumeState1;}

熔断降级及 Java 错误指定的类

package com.galaxy.config;import com.alibaba.csp.sentinel.slots.block.BlockException;/*** @author lane* @date 2021年07月03日 上午10:52*/
public class SentinelFallBack {// 整体要求和当时Hystrix一样，这里还需要在形参中添加BlockException参数，用于接收异常// 注意：方法是静态的public static Integer handleException(Long userId, BlockException blockException) {return -100;}//这里是Java 出现error的时候自定义的兜底方法public static Integer handleError(Long userId) {return -500;}
}

注意：兜底类中的⽅法为 static 静态⽅法

2.9 基于 Nacos 实现 Sentinel 规则持久化

⽬前，Sentinel Dashboard 中添加的规则数据存储在内存，微服务停掉规则数据就消失，在⽣产环境下不合适。我们可以将 Sentinel 规则数据持久化到 Nacos 配置中⼼，让微服务从 Nacos 获取规则数据。

⾃动投递微服务的 pom.xml 中添加依赖

<!-- Sentinel支持采用 Nacos 作为规则配置数据源，引入该适配依赖 --><dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-datasource-nacos</artifactId></dependency>

⾃动投递微服务的 application.yml 中配置 Nacos 数据源

server:port: 8098
spring:application:name: lane-service-autodelivercloud:nacos:discovery:server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850sentinel:transport:dashboard: 127.0.0.1:8080 # sentinel dashboard/console 地址port: 8719   #  sentinel会在该端口启动http server，那么这样的话，控制台定义的一些限流等规则才能发送传递过来，#如果8719端口被占用，那么会依次+1# Sentinel Nacos数据源配置，Nacos中的规则会自动同步到sentinel流控规则中datasource:# 自定义的流控规则数据源名称flow:nacos:server-addr: ${spring.cloud.nacos.discovery.server-addr}data-id: ${spring.application.name}-flow-rulesgroupId: DEFAULT_GROUPdata-type: jsonrule-type: flow  # 类型来自RuleType类# 自定义的降级规则数据源名称degrade:nacos:server-addr: ${spring.cloud.nacos.discovery.server-addr}data-id: ${spring.application.name}-degrade-rulesgroupId: DEFAULT_GROUPdata-type: jsonrule-type: degrade  # 类型来自RuleType类

Nacos Server 中添加对应规则配置集（public 命名空间—>DEFAULT_GROUP 中添加）

流控规则配置集 lane-service-autodeliver-ﬂow-rules

[{"resource": "findResumeOpenState","limitApp": "default","grade": 1,"count": 1,"strategy": 0,"controlBehavior": 0,"clusterMode": false}]

所有属性来⾃源码 FlowRule 类

resource：资源名称

limitApp：来源应⽤

grade：阈值类型 0 线程数 1 QPS

count：单机阈值

strategy：流控模式，0 直接 1 关联 2 链路

controlBehavior：流控效果，0 快速失败 1 Warm Up 2 排队等待

clusterMode：true/false 是否集群

降级规则配置集 lane-service-autodeliver-degrade-rules

[{"resource": "findResumeOpenState","grade": 2,"count": 1,"timeWindow": 5}]

所有属性来⾃源码 DegradeRule 类

resource：资源名称

grade：降级策略 0 RT 1 异常⽐例 2 异常数

count：阈值

timeWindow：时间窗

重启服务测试下是否有配置的流控和降级规则，以前是存在内存当中，现在持久化后

注意：以后修改要修改 nacos 的配置中心当中的配置文件，不然还是只保存在内存当中。

Rule 源码体系结构

第三节 Nacos + Sentinel + Dubbo 三剑合璧

改造“⾃动投递微服务”和“简历微服务”，删除 OpenFeign 和 Ribbon，使⽤ Dubbo RPC 和 Dubbo LB

⾸先，需要删除或者注释掉⽗⼯程中的热部署依赖

注意要 clean 下父工程

我整合好开始运行，还是出现问题了，搞了半天没搞好，突然想到既然清除了热部署插件，忘了 clean 一下，clean 下父工程，可以正常启动了

3.1 服务提供者⼯程改造

添加 API 模块 lane-service-dubbo-api

只需要添加一个接口即可

package com.galaxy.service;/*** @author lane* @date 2021年07月03日 下午14:39*/
public interface ResumeService {Integer findDefaultResumeByUserId(Long userId);
}

改造提供者⼯程（简历微服务）

pom ⽂件添加 spring cloud + dubbo 整合的依赖，同时添加 dubbo 服务接⼝

依赖

  <!--spring cloud+dubbo 依赖--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-dubbo</artifactId></dependency><dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-apache-dubbo-adapter</artifactId></dependency><!--dubbo 服务接口依赖--><dependency><groupId>com.galaxy</groupId><artifactId>lane-service-dubbo-api</artifactId><version>1.0-SNAPSHOT</version></dependency>

删除原有 ResumeService 接⼝，引⼊ dubbo 服务接⼝⼯程中的 ResumeService 接⼝，适当调整代码，在 service 的实现类上添加 dubbo 的 @Service 注解

application.yml 或者 bootstrap.yml 配置⽂件中添加 dubbo 配置

dubbo:scan:# dubbo 服务扫描基准包base-packages: com.galaxy.service.implprotocol:# dubbo 协议name: dubbo# dubbo 协议端口（ -1 表示自增端口，从 20880 开始）port: -1host: 127.0.0.1registry:# 挂载到 Spring Cloud 的注册中心address: spring-cloud://localhostcheck: falseconsumer:check: falsetimeout: 20000

另外增加⼀项配置

运⾏发布之后，会发现 Nacos 控制台已经有了服务注册信息,从元数据中可以看出,是 dubbo 注册上来的

3.2 服务消费者⼯程改造

接下来改造服务消费者⼯程—> ⾃动投递微服务

pom.xml 中删除 OpenFeign 相关内容

application.yml 配置⽂件中删除和 Feign、Ribbon 相关的内容；

代码中删除 Feign 客户端内容；

pom.xml 添加内容和服务提供者⼀样

application.yml 配置⽂件中添加 dubbo 相关内容

dubbo:registry:# 挂载到 Spring Cloud 注册中心address: spring-cloud://locallhostcheck: falsecloud:# 订阅服务提供方的应用列表，订阅多个服务提供者使用 "," 连接subscribed-services: lane-service-resume

Controller 代码改造，其他不变

运⾏发布之后，同样会发现 Nacos 控制台已经有了服务注册信息

测试：http://localhost:8099/autodeliver/checkState/1545132

第四节 SCA ⼩结

1）因为内容重叠，SCA 中的分布式事务解决⽅案 Seata 会在紧接着的 Mysql 课程中讲解。

2）SCA 实际上发展了三条线

第⼀条线：开源出来⼀些组件

第⼆条线：阿⾥内部维护了⼀个分⽀，⾃⼰业务线使⽤

第三条线：阿⾥云平台部署⼀套，付费使⽤从战略上来说，SCA 更是为了贴合阿⾥云。

⽬前来看，开源出来的这些组件，推⼴及普及率不⾼，社区活跃度不⾼，稳定性和体验度上仍需进⼀步提升，根据实际使⽤来看 Sentinel 的稳定性和体验度要好于 Nacos。

总结

Spring Cloud

eureka 注册中心

hystrix 熔断降级

ribon 负载均衡

rest template 接口调用

feign = hystrix + ribon + rest template 接口调用为主负载均衡熔断降级

spring cloud config、spring cloud bus 配置中心

spring cloud dashboard、spring cloud turbine 配置监控

spring cloud stream mq 封装

spring cloud gateway 网关

spring cloud slueth 添加日志

spring cluoud zipken 抓取日志，图形展示，耗时监控

Spring Cloud Alibaba

Nacos 注册中心、配置中心 1 个应用 server

Sentinel 熔断、降级、限流 1 个 jar 包 server

Dubbo 远程接口调用负载均衡

Seata 分布式事务

GitHub代码地址