标签：调用 服务 请求 SpringCloud 熔断 Spring Sentinel
Spring Cloud Netflix
组件提供了服务治理、服务网关、智能路由、负载均衡、熔断器、监控跟踪、分布式消息队列、配置管理等领域的解决方案。
| 组件名 | 作用 |
|---|---|
| Eureka | 服务治理组件，包含服务注册中心、服务注册与发现机制的实现。 |
| Ribbon | 服务调用和客户端负载均衡 |
| Hystrix | 容错管理组件，为服务中出现的延迟和故障提供强大的容错能力。 |
| Feign | 基于 Ribbon 和 Hystrix 的声明式服务调用组件 |
| Zuul | 网关组件，提供了智能路由、访问过滤等功能。 |
| Gateway | 使用 Filter 链的方式提供了网关的基本功能，例如安全、监控/指标和限流等。 |
| Config | 配置管理工具，支持使用 Git 存储配置内容，实现应用配置的外部化存储，并支持在客户端对配置进行刷新、加密、解密等操作 |
| Bus | 事件和消息总线，主要用于在集群中传播事件或状态变化，以触发后续的处理，例如动态刷新配置。 |
| Stream | 消息中间件组件。通过定义绑定器作为中间层，完美地实现了应用程序与消息中间件之间的隔离 |
| Sleuth | 链路跟踪组件 |
Eureka （独立部署）
采用 CS（Client/Server，客户端/服务器） 架构，它包括以下两大组件：
- Eureka Server：Eureka 服务注册中心，主要用于提供服务注册功能。当微服务启动时，会将自己的服务注册到 Eureka Server。Eureka Server 维护了一个可用服务列表，存储了所有注册到 Eureka Server 的可用服务的信息，这些可用服务可以在 Eureka Server 的管理界面中直观看到。
- Eureka Client：Eureka 客户端，通常指的是微服务系统中各个微服务，主要用于和 Eureka Server 进行交互。在微服务应用启动后，Eureka Client 会向 Eureka Server 发送心跳（默认周期为 30 秒）。若 Eureka Server 在多个心跳周期内没有接收到某个 Eureka Client 的心跳，Eureka Server 将它从可用服务列表中移除（默认 90 秒）。
服务注册中心，服务提供者，服务消费者
Ribbon（工具框架，不独立部署）
微服务之间的调用，API 网关的请求转发
负载均衡
负载均衡（Load Balance） ，简单点说就是将用户的请求平摊分配到多个服务器上运行，以达到扩展服务器带宽、增强数据处理能力、增加吞吐量、提高网络的可用性和灵活性的目的。
常见的负载均衡方式有两种：
- 服务端负载均衡
- 客户端负载均衡
服务端负载均衡
服务端负载均衡是最常见的负载均衡方式，其工作原理如下图。
客户端负载均衡（Ribbon）
客户端负载均衡是将负载均衡逻辑以代码的形式封装到客户端上，即负载均衡器位于客户端。客户端通过服务注册中心（例如 Eureka Server）获取到一份服务端提供的可用服务清单。有了服务清单后，负载均衡器会在客户端发送请求前通过负载均衡算法选择一个服务端实例再进行访问，以达到负载均衡的目的。
客户端负载均衡也需要心跳机制去维护服务端清单的有效性，这个过程需要配合服务注册中心一起完成。
Ribbon默认采用轮询的策略
| 序号 | 实现类 | 负载均衡策略 |
|---|---|---|
| 1 | RoundRobinRule | 按照线性轮询策略，即按照一定的顺序依次选取服务实例 |
| 2 | RandomRule | 随机选取一个服务实例 |
| 3 | RetryRule | 按照 RoundRobinRule（轮询）的策略来获取服务，如果获取的服务实例为 null 或已经失效，则在指定的时间之内不断地进行重试（重试时获取服务的策略还是 RoundRobinRule 中定义的策略），如果超过指定时间依然没获取到服务实例则返回 null 。 |
| 4 | WeightedResponseTimeRule | WeightedResponseTimeRule 是 RoundRobinRule 的一个子类，它对 RoundRobinRule 的功能进行了扩展。 根据平均响应时间，来计算所有服务实例的权重，响应时间越短的服务实例权重越高，被选中的概率越大。刚启动时，如果统计信息不足，则使用线性轮询策略，等信息足够时，再切换到 WeightedResponseTimeRule。 |
| 5 | BestAvailableRule | 继承自 ClientConfigEnabledRoundRobinRule。先过滤点故障或失效的服务实例，然后再选择并发量最小的服务实例。 |
| 6 | AvailabilityFilteringRule | 先过滤掉故障或失效的服务实例，然后再选择并发量较小的服务实例。 |
| 7 | ZoneAvoidanceRule | 默认的负载均衡策略，综合判断服务所在区域（zone）的性能和服务（server）的可用性，来选择服务实例。在没有区域的环境下，该策略与轮询（RandomRule）策略类似。 |
OpenFeign（基于Ribbon）
改进：支持SpringMVC注解
OpenFeign 常用注解
使用 OpenFegin 进行远程服务调用时，常用注解如下表。
| 注解 | 说明 |
|---|---|
| @FeignClient | 该注解用于通知 OpenFeign 组件对 @RequestMapping 注解下的接口进行解析，并通过动态代理的方式产生实现类，实现负载均衡和服务调用。 |
| @EnableFeignClients | 该注解用于开启 OpenFeign 功能，当 Spring Cloud 应用启动时，OpenFeign 会扫描标有 @FeignClient 注解的接口，生成代理并注册到 Spring 容器中。 |
| @RequestMapping | Spring MVC 注解，在 Spring MVC 中使用该注解映射请求，通过它来指定控制器（Controller）可以处理哪些 URL 请求，相当于 Servlet 中 web.xml 的配置。 |
| @GetMapping | Spring MVC 注解，用来映射 GET 请求，它是一个组合注解，相当于 @RequestMapping(method = RequestMethod.GET) 。 |
| @PostMapping | Spring MVC 注解，用来映射 POST 请求，它是一个组合注解，相当于 @RequestMapping(method = RequestMethod.POST) 。 |
Hystrix
当微一个服务出现故障时，在调用链路疯狂蔓延，最终导致整个微服务系统的瘫痪。“熔断器”的一系列服务容错和保护机制。
具有服务降级、服务熔断、线程隔离、请求缓存、请求合并以及实时故障监控等强大功能。
Hystrix 能够帮助我们实现以下目标：
- 保护线程资源：防止单个服务的故障耗尽系统中的所有线程资源。
- 快速失败机制：当某个服务发生了故障，不让服务调用方一直等待，而是直接返回请求失败。
- 提供降级（FallBack）方案：在请求失败后，提供一个设计好的降级方案，通常是一个兜底方法，当请求失败后即调用该方法。
- 防止故障扩散：使用熔断机制，防止故障扩散到其他服务。
- 监控功能：提供熔断器故障监控组件 Hystrix Dashboard，随时监控熔断器的状态
Gateway（API 网关）
系统对外的唯一入口。可以在 API 网关中处理一些非业务功能的逻辑，例如权限验证、监控、缓存、请求路由等。
安全、流控、过滤、缓存、计费以及监控等 API 管理功能。
功能就是路由转发
| 核心概念 | 描述 |
|---|---|
| Route（路由） | 网关最基本的模块。它由一个 ID、一个目标 URI、一组断言（Predicate）和一组过滤器（Filter）组成。 |
| Predicate（断言） | 路由转发的判断条件，我们可以通过 Predicate 对 HTTP 请求进行匹配，例如请求方式、请求路径、请求头、参数等，如果请求与断言匹配成功，则将请求转发到相应的服务。 |
| Filter（过滤器） | 过滤器，我们可以使用它对请求进行拦截和修改，还可以使用它对上文的响应进行再处理。 |
注意：其中 Route 和 Predicate 必须同时声明
工作流程
- 客户端将请求发送到 Spring Cloud Gateway 上。
- Spring Cloud Gateway 通过 Gateway Handler Mapping 找到与请求相匹配的路由，将其发送给 Gateway Web Handler。
- Gateway Web Handler 通过指定的过滤器链（Filter Chain），将请求转发到实际的服务节点中，执行业务逻辑返回响应结果。
- 过滤器之间用虚线分开是因为过滤器可能会在转发请求之前（pre）或之后（post）执行业务逻辑。
- 过滤器（Filter）可以在请求被转发到服务端前，对请求进行拦截和修改，例如参数校验、权限校验、流量监控、日志输出以及协议转换等。
- 过滤器可以在响应返回客户端之前，对响应进行拦截和再处理，例如修改响应内容或响应头、日志输出、流量监控等。
- 响应原路返回给客户端。
Predicate 断言
Predicate 是路由转发的判断条件，请求只有满足了 Predicate 的条件，才会被转发到指定的服务上进行处理。
使用 Predicate 断言需要注意以下 3 点：
- Route 路由与 Predicate 断言的对应关系为“一对多”，一个路由可以包含多个不同断言。
- 一个请求想要转发到指定的路由上，就必须同时匹配路由上的所有断言。
- 当一个请求同时满足多个路由的断言条件时，请求只会被首个成功匹配的路由转发。
Filter 过滤器
| 过滤器类型 | 说明 |
|---|---|
| Pre 类型 | 这种过滤器在请求被转发到微服务之前可以对请求进行拦截和修改，例如参数校验、权限校验、流量监控、日志输出以及协议转换等操作。 |
| Post 类型 | 这种过滤器在微服务对请求做出响应后可以对响应进行拦截和再处理，例如修改响应内容或响应头、日志输出、流量监控等。 |
作用范围划分，Spring Cloud gateway 的 Filter 可以分为 2 类：
- GatewayFilter：应用在单个路由或者一组路由上的过滤器。
- GlobalFilter：应用在所有的路由上的过滤器。
GatewayFilter 网关过滤器
GatewayFilter 是 Spring Cloud Gateway 网关中提供的一种应用在单个或一组路由上的过滤器。它可以对单个路由或者一组路由上传入的请求和传出响应进行拦截，并实现一些与业务无关的功能，比如登陆状态校验、签名校验、权限校验、日志输出、流量监控等。
内置了多达 31 种 GatewayFilter
GlobalFilter 全局过滤器
全局过滤器，通过它，我们可以实现一些统一化的业务功能，例如权限认证、IP 访问限制等。当某个请求被路由匹配时，那么所有的 GlobalFilter 会和该路由自身配置的 GatewayFilter 组合成一个过滤器链。
Config
包含以下两个部分：
- Config Server：也被称为分布式配置中心，它是一个独立运行的微服务应用，用来连接配置仓库并为客户端提供获取配置信息、加密信息和解密信息的访问接口。
- Config Client：指的是微服务架构中的各个微服务，它们通过 Config Server 对配置进行管理，并从 Config Sever 中获取和加载配置信息。
Config+Bus 实现配置的动态刷新
Spring Cloud Bus 支持两种消息代理：RabbitMQ 和 Kafka
全局广播（所有实例）,定点刷新（指定实例）
Spring Cloud Alibaba
| 组件 | 作用 |
|---|---|
| Nacos | 动态服务发现,配置管理和服务管理平台。 |
| Sentinel | 流量切入点,从流量控制,熔断降级,系统负载保护等多个维度保护服务的稳定性。 |
| RocketMQ | 分布式消息和流计算平台。 |
| Dubbo | RPC 框架 |
| Seata | 分布式事务解决方案 |
| OSS | 对象存储服务器，云存储服务 |
| Schedulerx | 分布式调度产品,支持周期性的任务与固定时间点触发任务。 |
| Spring Cloud 第一代实现（Netflix） | 状态 | Spring Cloud 第二代实现（Alibaba） | 状态 |
|---|---|---|---|
| Ereka | 2.0 孵化失败 | Nacos Discovery | 性能更好，感知力更强 |
| Ribbon | 停更进维 | Spring Cloud Loadbalancer | Spring Cloud 原生组件，用于代替 Ribbon |
| Hystrix | 停更进维 | Sentinel | 可视化配置，上手简单 |
| Zuul | 停更进维 | Spring Cloud Gateway | 性能为 Zuul 的 1.6 倍 |
| Spring Cloud Config | 搭建过程复杂，约定过多，无可视化界面，上手难点大 | Nacos Config | 搭建过程简单，有可视化界面，配置管理更简单，容易上手 |
Nacos
服务注册中心和配置中心的组合体
| 组成部分 | 全称 | 描述 |
|---|---|---|
| Na | naming/nameServer | 即服务注册中心，与 Spring Cloud Eureka 的功能类似。 |
| co | configuration | 即配置中心，与 Spring Cloud Config+Spring Cloud Bus 的功能类似。 |
| s | service | 即服务，表示 Nacos 实现的服务注册中心和配置中心都是以服务为核心的。 |
Nacos 的特性：
- 服务发现
- 服务健康监测
- 动态配置服务
- 动态 DNS 服务
- 服务及其元数据管理
集群化（高可用）
Sentinel
高可用流量控制组件
Sentinel 具有以下优势:
- 丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的“双十一”大促流量的核心场景，例如秒杀（将突发流量控制在系统可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用服务等。
- 完备的实时监控：Sentinel 提供了实时监控功能。用户可以在控制台中看到接入应用的单台机器的秒级数据，甚至是 500 台以下规模集群的汇总运行情况。
- 广泛的开源生态：Sentinel 提供了开箱即用的与其它开源框架或库（例如 Spring Cloud、Apache Dubbo、gRPC、Quarkus）的整合模块。我们只要在项目中引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。此外，Sentinel 还提供 Java、Go 以及 C++ 等多语言的原生实现。
- 完善的 SPI 扩展机制：Sentinel 提供简单易、完善的 SPI 扩展接口，我们可以通过实现这些扩展接口快速地定制逻辑，例如定制规则管理、适配动态数据源等。
SPI ，全称为 Service Provider Interface，是一种服务发现机制。它可以在 ClassPath 路径下的 META-INF/services 文件夹查找文件，并自动加载文件中定义的类。
Sentinel 由以下两个部分组成：
- Sentinel 核心库：Sentinel 的核心库不依赖任何框架或库，能够运行于 Java 8 及以上的版本的运行时环境中，同时对 Spring Cloud、Dubbo 等微服务框架提供了很好的支持。
- Sentinel 控制台（Dashboard）：Sentinel 提供的一个轻量级的开源控制台，它为用户提供了机器自发现、簇点链路自发现、监控、规则配置等功能。
Sentinel 核心库不依赖 Sentinel Dashboard，但两者结合使用可以有效的提高效率，让 Sentinel 发挥它最大的作用。
基本概念
| 基本概念 | 描述 |
|---|---|
| 资源 | 资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容，例如由应用程序提供的服务或者是服务里的方法，甚至可以是一段代码。 我们可以通过 Sentinel 提供的 API 来定义一个资源，使其能够被 Sentinel 保护起来。通常情况下，我们可以使用方法名、URL 甚至是服务名来作为资源名来描述某个资源。 |
| 规则 | 围绕资源而设定的规则。Sentinel 支持流量控制、熔断降级、系统保护、来源访问控制和热点参数等多种规则，所有这些规则都可以动态实时调整。 |
Sentinel 控制台
提供了机器发现与健康情况管理、监控（单机和集群）、规则管理与推送等多种功能。
- 查看机器列表以及健康情况：Sentinel 控制台能够收集 Sentinel 客户端发送的心跳包，判断机器是否在线。
- 监控（单机和集群聚合）：Sentinel 控制台通过 Sentinel 客户端暴露的监控 API，可以实现秒级的实时监控。
- 规则管理和推送：通过 Sentinel 控制台，我们还能够针对资源定义和推送规则。
- 鉴权：从 Sentinel 1.6.0 起，Sentinel 控制台引入基本的登录功能，默认用户名和密码都是 sentinel。
定义资源
资源是 Sentinel 中的核心概念之一。在项目开发时，我们只需要考虑这个服务、方法或代码是否需要保护，如果需要保护，就可以将它定义为一个资源。
Sentinel 为我们提供了多种定义资源的方式：
-
适配主流框架自动定义资源
-
通过 SphU 手动定义资源
-
通过 SphO 手动定义资源
-
注解方式定义资源
适配主流框架自动定义资源
关的适配模块（例如 spring-cloud-starter-alibaba-sentinel），Snetinel 就会自动将项目中的服务（包括调用端和服务端）定义为资源，资源名就是服务的请求路径。此时，我们只要再定义一些规则，这些资源就可以享受到 Sentinel 的保护。
通过 SphU 手动定义资源
提供了一个名为 SphU 的类，在业务代码中使用try-catch 手动定义资源。
通过 SphO 手动定义资源
名为 SphO 的类，在业务代码中使用if-else手动定义资源。发生了限流之后会返回 false，此时我们可以根据返回值，进行限流之后的逻辑处理。
注解方式定义资源
@SentinelResource
@SentinelResource注解
| 属性 | 说明 | 必填与否 | 使用要求 |
|---|---|---|---|
| value | 用于指定资源的名称 | 必填 | - |
| entryType | entry 类型 | 可选项（默认为 EntryType.OUT） | - |
| blockHandler | 服务限流后会抛出 BlockException 异常，而 blockHandler 则是用来指定一个函数来处理 BlockException 异常的。 简单点说，该属性用于指定服务限流后的后续处理逻辑。 | 可选项 | blockHandler 函数访问范围需要是 public；返回类型需要与原方法相匹配；参数类型需要和原方法相匹配并且最后加一个额外的参数，类型为 BlockException；blockHandler 函数默认需要和原方法在同一个类中，若希望使用其他类的函数，则可以指定 blockHandler 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。 |
| blockHandlerClass | 若 blockHandler 函数与原方法不在同一个类中，则需要使用该属性指定 blockHandler 函数所在的类。 | 可选项 | 不能单独使用，必须与 blockHandler 属性配合使用；该属性指定的类中的 blockHandler 函数必须为 static 函数，否则无法解析。 |
| fallback | 用于在抛出异常（包括 BlockException）时，提供 fallback 处理逻辑。 fallback 函数可以针对所有类型的异常（除了 exceptionsToIgnore 里面排除掉的异常类型）进行处理。 | 可选项 | 返回值类型必须与原函数返回值类型一致；方法参数列表需要和原函数一致，或者可以额外多一个 Throwable 类型的参数用于接收对应的异常；fallback 函数默认需要和原方法在同一个类中，若希望使用其他类的函数，则可以指定 fallbackClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。 |
| fallbackClass | 若 fallback 函数与原方法不在同一个类中，则需要使用该属性指定 blockHandler 函数所在的类。 | 可选项 | 不能单独使用，必须与 fallback 或 defaultFallback 属性配合使用；该属性指定的类中的 fallback 函数必须为 static 函数，否则无法解析。 |
| defaultFallback | 默认的 fallback 函数名称，通常用于通用的 fallback 逻辑（即可以用于很多服务或方法）。 默认 fallback 函数可以针对所以类型的异常（除了 exceptionsToIgnore 里面排除掉的异常类型）进行处理。 | 可选项 | 返回值类型必须与原函数返回值类型一致；方法参数列表需要为空，或者可以额外多一个 Throwable 类型的参数用于接收对应的异常；defaultFallback 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 fallbackClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。 |
| exceptionsToIgnore | 用于指定哪些异常被排除掉，不会计入异常统计中，也不会进入 fallback 逻辑中，而是会原样抛出。 | 可选项 | - |
Sentinel 流量控制
一条流量规则主要由下表中的属性组成
| 属性 | 说明 | 默认值 |
|---|---|---|
| 资源名 | 流控规则的作用对象。 | - |
| 阈值 | 流控的阈值。 | - |
| 阈值类型 | 流控阈值的类型，包括 QPS 或并发线程数。 | QPS |
| 针对来源 | 流控针对的调用来源。 | default，表示不区分调用来源 |
| 流控模式 | 调用关系限流策略，包括直接、链路和关联。 | 直接 |
| 流控效果 | 流控效果（直接拒绝、Warm Up、匀速排队），不支持按调用关系限流。 | 直接拒绝 |
- @SentinelResource 注解定义资源名称，并在 blockHandler 属性指定一个限流函数，自定义服务限流信息，进行限流之后的后续处理
- 调用 FlowRuleManager 类的 loadRules() 方法来定义流控规则
熔断降级规则
3 种熔断策略
| 熔断策略 | 说明 |
|---|---|
| 慢调用比例 (SLOW_REQUEST_RATIO） | 选择以慢调用比例作为阈值，需要设置允许的慢调用 RT（即最大响应时间），若请求的响应时间大于该值则统计为慢调用。 当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。 经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断，若大于设置的慢调用 RT 则再次被熔断。 |
| 异常比例 (ERROR_RATIO) | 当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目且异常的比例大于阈值，则在接下来的熔断时长内请求会自动被熔断。 经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%。 |
| 异常数 (ERROR_COUNT) | 当单位统计时长内的异常数目超过阈值之后会自动进行熔断。 经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。 |
Sentinel 熔断状态
熔断降级中共涉及 3 种状态，熔断状态的之间的转换过程如下图。
Sentinel 熔断降级中共涉及 3 种状态，如下表。
| 状态 | 说明 | 触发条件 |
|---|---|---|
| 熔断关闭状态 （CLOSED） | 处于关闭状态时，请求可以正常调用资源。 | 满足以下任意条件，Sentinel 熔断器进入熔断关闭状态：全部请求访问成功。单位统计时长（statIntervalMs）内请求数目小于设置的最小请求数目。未达到熔断标准，例如服务超时比例、异常数、异常比例未达到阈值。处于探测恢复状态时，下一个请求访问成功。 |
| 熔断开启状态 （OPEN） | 处于熔断开启状态时，熔断器会一定的时间（规定的熔断时长）内，暂时切断所有请求对该资源的调用，并调用相应的降级逻辑使请求快速失败避免系统崩溃。 | 满足以下任意条件，Sentinel 熔断器进入熔断开启状态：单位统计时长内请求数目大于设置的最小请求数目，且已达到熔断标准，例如请求超时比例、异常数、异常比例达到阈值。处于探测恢复状态时，下一个请求访问失败。 |
| 探测恢复状态 （HALF-OPEN） | 处于探测恢复状态时，Sentinel 熔断器会允许一个请求调用资源。则若接下来的一个请求成功完成（没有错误）则结束熔断，熔断器进入熔断关闭（CLOSED）状态；否则会再次被熔断，熔断器进入熔断开启（OPEN）状态。 | 在熔断开启一段时间（降级窗口时间或熔断时长，单位为 s）后，Sentinel 熔断器自动会进入探测恢复状态。 |
Sentinel 熔断规则属性
Sentinel 熔断降级规则包含多个重要属性，如下表所示。
| 属性 | 说明 | 默认值 | 使用范围 |
|---|---|---|---|
| 资源名 | 规则的作用对象。 | - | 所有熔断策略 |
| 熔断策略 | Sentinel 支持3 中熔断策略：慢调用比例、异常比例、异常数策略。 | 慢调用比例 | 所有熔断策略 |
| 最大 RT | 请求的最大相应时间，请求的响应时间大于该值则统计为慢调用。 | - | 慢调用比例 |
| 熔断时长 | 熔断开启状态持续的时间，超过该时间熔断器会切换为探测恢复状态（HALF-OPEN），单位为 s。 | - | 所有熔断策略 |
| 最小请求数 | 熔断触发的最小请求数，请求数小于该值时即使异常比率超出阈值也不会熔断（1.7.0 引入）。 | 5 | 所有熔断策略 |
| 统计时长 | 熔断触发需要统计的时长（单位为 ms），如 60*1000 代表分钟级（1.8.0 引入）。 | 1000 ms | 所有熔断策略 |
| 比例阈值 | 分为慢调用比例阈值和异常比例阈值，即慢调用或异常调用占所有请求的百分比，取值范围 [0.0,1.0]。 | - | 慢调用比例 、异常比例 |
| 异常数 | 请求或调用发生的异常的数量。 | - | 异常数 |
Sentinel 实现熔断降级过程
Sentinel 实现熔断降级的步骤如下：
- 在项目中，使用 @SentinelResource 注解的 fallback 属性可以为资源指定熔断降级逻辑（方法）。
- 通过 Sentinel 控制台或代码定义熔断规则，包括熔断策略、最小请求数、阈值、熔断时长以及统计时长等。
- 若单位统计时长（statIntervalMs）内，请求数目大于设置的最小请求数目且达到熔断标准（例如请求超时比例、异常数、异常比例达到阈值），Sentinel 熔断器进入熔断开启状态（OPEN）。
- 处于熔断开启状态时， @SentinelResource 注解的 fallback 属性指定的降级逻辑会临时充当主业务逻辑，而原来的主逻辑则暂时不可用。当有请求访问该资源时，会直接调用降级逻辑使请求快速失败，而不会调用原来的主业务逻辑。
- 在经过一段时间（在熔断规则中设置的熔断时长）后，熔断器会进入探测恢复状态（HALF-OPEN），此时 Sentinel 会允许一个请求对原来的主业务逻辑进行调用，并监控其调用结果。
- 若请求调用成功，则熔断器进入熔断关闭状态（CLOSED ），服务原来的主业务逻辑恢复，否则重新进入熔断开启状态（OPEN）。
Seata
分布式事务相关概念
- 事务：由一组操作构成的可靠、独立的工作单元，具备 ACID特性
- 本地事务：本地事务由本地资源管理器管理，严格地支持 ACID 特性，高效可靠。只能对自己数据库的操作进行控制
- 全局事务：一组分支事务组成。
- 分支事务：受全局事务管辖和协调的本地事务。0
Seata 整体工作流程
分布式事务的协调和控制，主要是通过 XID 和 3 个核心组件实现的。
XID
XID 是全局事务的唯一标识，绑定到服务的事务上下文中。
核心组件
Seata 定义了 3 个核心组件：
- TC（Transaction Coordinator）：事务协调器，它是事务的协调者（这里指的是 Seata 服务器），主要负责维护全局事务和分支事务的状态，驱动全局事务提交或回滚。
- TM（Transaction Manager）：事务管理器，它是事务的发起者，负责定义全局事务的范围，并根据 TC 维护的全局事务和分支事务状态，做出开始事务、提交事务、回滚事务的决议。
- RM（Resource Manager）：资源管理器，它是资源的管理者（这里可以将其理解为各服务使用的数据库）。它负责管理分支事务上的资源，向 TC 注册分支事务，汇报分支事务状态，驱动分支事务的提交或回滚。
以上三个组件相互协作，TC 以 Seata 服务器（Server）形式独立部署，TM 和 RM 则是以 Seata Client 的形式集成在微服务中运行，其整体工作流程如下图。
图1：Sentinel 的工作流程
Seata 的整体工作流程如下：
- TM 向 TC 申请开启一个全局事务，全局事务创建成功后，TC 会针对这个全局事务生成一个全局唯一的 XID；
- XID 通过服务的调用链传递到其他服务;
- RM 向 TC 注册一个分支事务，并将其纳入 XID 对应全局事务的管辖；
- TM 根据 TC 收集的各个分支事务的执行结果，向 TC 发起全局事务提交或回滚决议；
- TC 调度 XID 下管辖的所有分支事务完成提交或回滚操作。
Seata AT 模式
标签：调用,服务,请求,SpringCloud,熔断,Spring,Sentinel 来源： https://www.cnblogs.com/ppku/p/16503227.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。