SpringCloud组件学习

Nacos

Nacos致力于帮助您发现、配置和管理微服务。Nacos提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos帮助您更敏捷和容易地构建、交付和管理微服务平台。Nacos是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

服务发现

RestTemplate服务调用：

在定义RestTemplate的时候，增加了@LoadBalanced注解，而在真正调用服务接口的时候，直接采用服务名的时候来写请求路径即可。在真正调用的时候，Spring Cloud会将请求拦截下来，然后通过负载均衡器选出节点，并替换服务名部分为具体的ip和端口，从而实现基于服务名的负载均衡调用。

Feign服务调用：

主要先通过@EnableFeignClients注解开启扫描Spring Cloud Feign客户端的功能；然后又创建一个Feign的客户端接口定义。使用@FeignClient注解来指定这个接口所要调用的服务名称，接口中定义的各个函数使用Spring MVC的注解就可以来绑定服务提供方的REST接口，比如下面就是绑定alibaba-nacos-discovery-server服务的/hello接口的例子。最后，在Controller中，注入了Client接口的实现，并调用hello方法来触发对服务提供方的调用。

这些是Spring Cloud LoadBalancer（或旧版的Ribbon）与Nacos客户端的协同工作。

流程：

客户端注册: 服务提供者（如alibaba-nacos-discovery-server）启动时，Nacos Client会将其服务名、IP、端口等信息封装成一个Instance对象，通过心跳机制注册到Nacos Server。

服务列表拉取与订阅: 服务消费者（调用方）启动时，Nacos Client会从Nacos Server拉取其所需服务（如alibaba-nacos-discovery-server）的健康实例列表，并缓存在本地。同时，客户端会与服务端建立一个长连接（在Nacos 2.x中是gRPC），实现服务列表变更的实时推送。

请求拦截: 当您发起一个RestTemplate或Feign调用时，@LoadBalanced或Feign的拦截器会捕获这个请求。

负载均衡: 拦截器从请求URL中解析出服务名（如alibaba-nacos-discovery-server），然后从本地缓存的服务列表中，通过负载均衡算法（默认为轮询）选择一个具体的实例（如192.168.1.100:8080）。

请求重写: 拦截器将URL中的服务名替换为选定实例的IP和端口，然后发起最终的HTTP请求。

核心实现：

心跳机制: 客户端会周期性地向服务端发送心跳包，证明自己“还活着”。如果服务端在一定时间内（可配置）未收到某个实例的心跳，会将其标记为不健康，并从服务列表中剔除。

健康检查: Nacos Server自身也会主动对注册的实例进行健康检查（可配置），确保服务列表的准确性。

数据推送 (UDP Push & gRPC): 在Nacos 1.x中，当服务列表发生变化时，服务端会通过UDP协议向客户端推送一个变更通知，客户端收到通知后会立即发起HTTP请求来拉取最新的服务列表。在Nacos 2.x中，这一机制升级为基于gRPC的长连接，变更信息可以直接通过长连接推送，效率更高，实时性更强。

临时实例 vs 持久化实例: Nacos中的服务实例分为两种。

  • 临时实例 (Ephemeral): 默认类型，依赖心跳维持，服务下线后会自动从服务端摘除。适用于大多数业务服务。
  • 持久化实例 (Persistent): 不依赖心跳，由服务端主动进行健康检查。即使服务实例宕机，服务端也不会主动摘除，需要通过API手动上下线。适用于一些需要手动控制状态的中间件或数据库服务。

配置中心

Nacos除了实现了服务的注册发现之外，还将配置中心功能整合在了一起。通过Nacos的配置管理功能，我们可以将整个架构体系内的所有配置都集中在Nacos中存储。这样做的好处，在以往的教程中介绍Spring Cloud Config时也有提到，主要有以下几点：

  • 分离的多环境配置，可以更灵活的管理权限，安全性更高
  • 应用程序的打包更为纯粹，以实现一次打包，多处运行的特点

@SpringBootApplication定义是个Spring Boot应用；还定义了一个Controller，其中通过@Value注解，注入了key为didispace.title的配置（默认为空字符串），这个配置会通过/test接口返回，后续我们会通过这个接口来验证Nacos中配置的加载。另外，这里还有一个比较重要的注解@RefreshScope，主要用来让这个类下的配置内容支持动态刷新，也就是当我们的应用启动之后，修改了Nacos中的配置内容之后，这里也会马上生效。创建配置文件bootstrap.properties，并配置服务名称和Nacos地址

@RefreshScope详解：

工作流程:

  1. 首次拉取: 应用启动时，Nacos Client从Nacos Server拉取配置。
  2. 建立长轮询: 拉取成功后，客户端会向服务端发起一个新的HTTP请求，询问配置是否有变更。这个请求的特点是，如果服务端检查发现配置没有变更，它不会立即返回，而是会hold住这个连接，直到：
    • 配置发生变更。
    • 连接超时（默认30秒）。
  3. 变更推送: 当管理员在Nacos控制台修改配置并发布后，服务端会感知到这个变更，并立即对所有hold住的、监听该配置的请求返回响应。
  4. 客户端更新: 客户端收到响应后，发现配置有变，会立刻去拉取最新的配置内容。
  5. 触发刷新: Nacos Client更新本地配置后，会发布一个Spring的EnvironmentChangeEvent事件。@RefreshScope所在的Bean会监听这个事件，销毁当前的Bean实例，并在下次使用时重新创建一个新的实例。这个过程中会重新注入@Value等配置，从而实现了配置的动态刷新。

为什么是长轮询?:

  • 实时性: 相比于普通轮询（客户端定时拉取），长轮询大大提高了配置变更的实时性。
  • 性能: 相比于WebSocket等长连接，长轮询对服务端的连接资源消耗更小，实现也相对简单。它是一种在实时性和资源消耗之间的优秀平衡方案。

环境搭建

我们对于Nacos服务端自身并没有做过什么特殊的配置，一切均以默认的单机模式运行，完成了上述所有功能的学习。但是，Nacos的单机运行模式仅适用于学习与测试环境，对于有高可用要求的生产环境显然是不合适的。那么，我们是否可以直接启动多个单机模式的Nacos，然后客户端指定多个Nacos节点就可以实现高可用吗？答案是否定的。

在搭建Nacos集群之前，我们需要先修改Nacos的数据持久化配置为MySQL存储。默认情况下，Nacos使用嵌入式数据库实现数据的存储。所以，如果启动多个默认配置下的Nacos节点，数据存储是存在一致性问题的。为了解决这个问题，Nacos采用了集中式存储的方式来支持集群化部署，目前只要支持MySQL的存储。

  1. 初始化MySQL数据库，数据库初始化文件：nacos-mysql.sql，该文件可以在Nacos程序包
  2. 修改conf/application.properties文件，增加支持MySQL数据源配置，添加（目前只支持mysql）数据源的url、用户名和密码。配置样例如下：

关于Nacos数据的持久化实现，与其他的中间件相比，在实现上并没有采用分布式算法来解决一致性问题，而是采用了比较常规的集中化存储来实现。由于采用单一数据源的方式，直接解决了分布式一致性问题，所以从学习成本的角度上来说，Nacos的实现原理会更容易被理解和接受。但是，从部署的负责度和硬件投入成本上来说，与etcd、consul、zookeeper这些通过算法方式解决一致性问题的中间件相比，就显得不足了。

同时，在引入MySQL的存储时，由于多了一个中间件的存在，整个Nacos系统的整体可用性一定是会所有下降的。所以为了弥补可用性的下降，在生产上MySQL的高可用部署也是必须的，成本再次提高。不论如何提高，可用性都难以达到100%，所以这种方式，不论如何提升存储的可用性，理论上都会对Nacos集群的自身可用性造成微小的下降。

nacos集群架构：

在Nacos的conf目录下有一个cluster.conf.example，可以直接把example扩展名去掉来使用，也可以单独创建一个cluster.conf文件，然后打开将后续要部署的Nacos实例地址配置在这里。

在Nacos的集群启动完毕之后，根据架构图所示，我们还需要提供一个统一的入口给我们用来维护以及给Spring Cloud应用访问。简单地说，就是我们需要为上面启动的的三个Nacos实例做一个可以为它们实现负载均衡的访问点。这个实现的方式非常多，这里就举个用Nginx来实现的简单例子吧。

在Nginx配置文件的http段中，我们可以加入下面的配置内容：配置nacos，实现负载均衡

Nacos 2.x为了解决不同场景下的一致性需求，采用了混合一致性协议。

  • AP协议 (Distro): 用于服务发现模块中的临时实例数据。Distro是Nacos自研的一种类Gossip协议，它保证了集群的最终一致性。
    • 为什么是AP?: 对于服务实例列表，短暂的不一致是可以容忍的（例如，一个新节点上线，A客户端比B客户端晚1秒知道）。最重要的是保证服务的高可用性（Availability），即使部分Nacos节点宕机，服务注册和发现功能依然可用。
  • CP协议 (JRaft): 用于配置管理模块和持久化实例数据。JRaft是Raft协议的Java实现，它保证了数据的强一致性。
    • 为什么是CP?: 配置信息（如数据库密码、功能开关）和持久化实例的元数据，绝对不能出现不一致的情况。必须保证一旦写入成功，所有客户端读到的都是最新值。因此，牺牲部分可用性来换取强一致性是必要的。

配置加载

Spring Cloud Alibaba Nacos模块默认情况下是如何加载配置信息的：

  • Data ID中的alibaba-nacos-config-client：对应客户端的配置spring.cloud.nacos.config.prefix，默认值为${spring.application.name}，即：服务名
  • Data ID中的properties：对应客户端的配置spring.cloud.nacos.config.file-extension，默认值为properties
  • Group的值DEFAULT_GROUP：对应客户端的配置spring.cloud.nacos.config.group，默认值为DEFAULT_GROUP

在采用默认值的应用要加载的配置规则就是：Data ID=${spring.application.name}.properties，Group=DEFAULT_GROUP。

多环境的配置如何实现与管理？

在Nacos中，本身有多个不同管理级别的概念，包括：Data ID、Group、Namespace。只要利用好这些层级概念的关系，就可以根据自己的需要来实现多环境的管理。

  • Data ID在Nacos中，我们可以理解为就是一个Spring Cloud应用的配置文件名。默认情况下Data ID的名称格式是这样的：${spring.application.name}.properties，即：以Spring Cloud应用命名的properties文件。可以通过spring.profiles.active来指定具体的环境名称，此时客户端就会把要获取配置的Data ID组织为：${spring.application.name}-${spring.profiles.active}.properties。
  • Group在Nacos中是用来对Data ID做集合管理的重要概念，
  • Namespace，用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的Group或Data ID的配置。Namespace的常用场景之一是不同环境的配置的区分隔离，例如：开发测试环境和生产环境的资源（如配置、服务）隔离等。

所以我们实现多环境配置有哪些方案呢？

第一种：通过Data ID与profile实现。

  • 优点：这种方式与Spring Cloud Config的实现非常像，用过Spring Cloud Config的用户，可以毫无违和感的过渡过来，由于命名规则类似，所以要从Spring Cloud Config中做迁移也非常简单。
  • 缺点：这种方式在项目与环境多的时候，配置内容就会显得非常混乱。配置列表中会看到各种不同应用，不同环境的配置交织在一起，非常不利于管理。
  • 建议：项目不多时使用，或者可以结合Group对项目根据业务或者组织架构做一些拆分规划。

第二种：通过Group实现。

  • 优点：通过Group按环境讲各个应用的配置隔离开。可以非常方便的利用Data ID和Group的搜索功能，分别从应用纬度和环境纬度来查看配置。
  • 缺点：由于会占用Group纬度，所以需要对Group的使用做好规划，毕竟与业务上的一些配置分组起冲突等问题。
  • 建议：这种方式虽然结构上比上一种更好一些，但是依然可能会有一些混乱，主要是在Group的管理上要做好规划和控制。

第三种：通过Namespace实现。

  • 优点：官方建议的方式，通过Namespace来区分不同的环境，释放了Group的自由度，这样可以让Group的使用专注于做业务层面的分组管理。同时，Nacos控制页面上对于Namespace也做了分组展示，不需要搜索，就可以隔离开不同的环境配置，非常易用。
  • 缺点：没有啥缺点，可能就是多引入一个概念，需要用户去理解吧。
  • 建议：直接用这种方式长远上来说会比较省心。虽然可能对小团队而言，项目不多，第一第二方式也够了，但是万一后面做大了呢？

不论用哪一种方式实现。对于指定环境的配置（spring.profiles.active=DEV、spring.cloud.nacos.config.group=DEV_GROUP、spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a），都不要配置在应用的bootstrap.properties中。而是在发布脚本的启动命令中，用-Dspring.profiles.active=DEV的方式来动态指定，会更加灵活！。

如何加载多个配置，以及如何共享配置。

如何做到？我们希望可以将Actuator模块的配置放在独立的配置文件actuator.properties文件中，而对于日志输出的配置放在独立的配置文件log.properties文件中。通过拆分这两类配置内容，希望可以做到配置的共享加载与统一管理。

  • 在Nacos中创建Data ID=actuator.properties，Group=DEFAULT_GROUP和Data ID=log.properties，Group=DEFAULT_GROUP的配置内容。

  • 在Spring Cloud应用中通过使用spring.cloud.nacos.config.ext-config参数来配置要加载的这两个配置内容，比如：

1
2
3
4
5
6
spring.cloud.nacos.config.ext-config[0].data-id=actuator.properties
spring.cloud.nacos.config.ext-config[0].group=DEFAULT_GROUP
spring.cloud.nacos.config.ext-config[0].refresh=true
spring.cloud.nacos.config.ext-config[1].data-id=log.properties
spring.cloud.nacos.config.ext-config[1].group=DEFAULT_GROUP
spring.cloud.nacos.config.ext-config[1].refresh=true

可以看到，spring.cloud.nacos.config.ext-config配置是一个数组List类型。每个配置中包含三个参数：data-id、group，refresh；前两个不做赘述，与Nacos中创建的配置相互对应，refresh参数控制这个配置文件中的内容时候支持自动刷新，默认情况下，只有默认加载的配置才会自动刷新，对于这些扩展的配置加载内容需要配置该设置时候才会实现自动刷新。

通过上面加载多个配置的实现，实际上我们已经可以实现不同应用共享配置了。但是Nacos中还提供了另外一个便捷的配置方式，比如下面的设置与上面使用的配置内容是等价的：

1
2
spring.cloud.nacos.config.shared-dataids=actuator.properties,log.properties
spring.cloud.nacos.config.refreshable-dataids=actuator.properties,log.properties
  • spring.cloud.nacos.config.shared-dataids参数用来配置多个共享配置的Data Id，多个的时候用用逗号分隔
  • spring.cloud.nacos.config.refreshable-dataids参数用来定义哪些共享配置的Data Id在配置变化时，应用中可以动态刷新，多个Data Id之间用逗号隔开。如果没有明确配置，默认情况下所有共享配置都不支持动态刷新

加载顺序是什么呢？

在使用Nacos配置的时候，主要有以下三类配置：

  • A: 通过spring.cloud.nacos.config.shared-dataids定义的共享配置
  • B: 通过spring.cloud.nacos.config.ext-config[n]定义的加载配置
  • C: 通过内部规则（spring.cloud.nacos.config.prefix、spring.cloud.nacos.config.file-extension、spring.cloud.nacos.config.group这几个参数）拼接出来的配置

我们日志读取的到的配置是

1
2
3
4
2019-02-08 21:23:02.665  INFO 63804 --- [main] o.s.c.a.n.c.NacosPropertySourceBuilder   : Loading nacos data, dataId: 'log.properties', group: 'DEFAULT_GROUP'
2019-02-08 21:23:02.671  INFO 63804 --- [main] o.s.c.a.n.c.NacosPropertySourceBuilder   : Loading nacos data, dataId: 'actuator.properties', group: 'DEFAULT_GROUP'
2019-02-08 21:23:02.677  INFO 63804 --- [main] o.s.c.a.n.c.NacosPropertySourceBuilder   : Loading nacos data, dataId: 'alibaba-nacos-config-client.properties', group: 'DEFAULT_GROUP'

后面加载的配置会覆盖之前加载的配置，所以优先级关系是：A < B < C

Sentine

分布式系统的流量防卫兵。从名字上来看，很容易就能猜到它是用来作服务稳定性保障的。对于服务稳定性保障组件,目前Spring Cloud Alibaba下整合的Sentinel也是用户可以重点考察和选型的目标。

主要是分为两部分：

  • sentinel-dashboard：与hystrix-dashboard类似，但是它更为强大一些。除了与hystrix-dashboard一样提供实时监控之外，还提供了流控规则、熔断规则的在线维护等功能。
  • 客户端整合：每个微服务客户端都需要整合sentinel的客户端封装与配置，才能将监控信息上报给dashboard展示以及实时的更改限流或熔断规则等。

由于sentinel-dashboard是一个标准的spring boot应用，所以如果要自定义端口号等内容的话，可以通过在启动命令中增加参数来调整，比如：-Dserver.port=8888。

spring.cloud.sentinel.transport.dashboard参数配置sentinel dashboard的访问地址，然后在前端进行配置的更新

配置存储规则

Sentinel自身就支持了多种不同的数据源来持久化规则配置，目前包括以下几种方式：

  • 文件配置
  • Nacos配置
  • ZooKeeper配置
  • Apollo配置

nacos:

  1. 引入依赖
  2. 添加配置信息
  3. 新增接口
  4. Nacos中创建限流规则的配置，填入信息。json传输

apollo：

  1. 引入依赖
  2. 创建配置：创建apollo-env.properties
  3. 在Spring Cloud应用中添加配置信息
  4. 创建接口，创建限流规则，json传输

在使用Apollo存储规则配置的时候与Nacos存储一样，对于Sentinel控制台这些数据是只读的，也就是说：

  • Sentinel控制台中修改规则：仅存在于服务的内存中，不会修改Apollo中的配置值，重启后恢复原来的值。
  • Nacos控制台中修改规则：服务的内存中规则会更新，Apollo中持久化规则也会更新，重启后依然保持。

不论采用什么配置中心，限流规则都只能通过Nacos界面或Apollo界面来完成修改才能得到持久化存储，而在Sentinel Dashboard中修改限流规则虽然可以生效，但是不会被持久化到配置中心。而在这两个配置中心里存储的数据是一个Json格式，当存储的规则越来越多，对该Json配置的可读性与可维护性会变的越来越差。所以，下面我们就来继续探讨这个不足之处，并给出相应的解决方案。

配置中心的修改都可以实时的刷新到业务服务，从而被Sentinel Dashboard读取到，但是对于这些规则的更新到达各个业务服务之后，并没有一个机制去同步到配置中心，作为配置中心的客户端也不会提供这样的逆向更新方法。

Sentinel Dashboard通过DynamicRuleProvider和DynamicRulePublisher两个接口来获取和更新应用的动态规则。

那么如何做呢？

  1. Sentinel官方提供的Nacos数据源扩展依赖。这个依赖会引入Nacos Client。
  2. 修改前端sidebar.html，Dashboard的UI从默认的V1（内存模式）切换到V2（动态数据源模式）
  3. 在com.alibaba.csp.sentinel.dashboard.rule包下新建一个nacos包，用来存放我们针对Nacos的扩展实现。
  4. 创建Nacos的配置类 (NacosConfig)，负责初始化Nacos的ConfigService，在application.properties文件中添加Nacos的相关配置：
  5. 实现Nacos的配置拉取 (FlowRuleNacosProvider)，实现Nacos的配置推送 (FlowRuleNacosPublisher)
  6. 修改Controller，注入Nacos的实现，修改为Nacos的Provider Bean，Publisher Bean

@SentinelResource

限流：

  1. 在应用主类中增加注解支持的配置
  2. 在需要通过Sentinel来控制流量的地方使用@SentinelResource注解
  3. 在定义了资源点之后，我们就可以通过Dashboard来设置限流和降级策略来对资源点进行保护了。同时，也可以通过@SentinelResource来指定出现限流和降级时候的异常处理策略。

默认情况下，Sentinel对控制资源的限流处理是直接抛出异常，在没有合理的业务承接或者前端对接情况下可以这样，但是正常情况为了更好的用户业务，都会实现一些被限流之后的特殊处理

  • 通过@SentinelResource注解的blockHandler属性制定具体的处理函数
  • 实现处理函数，该函数的传参必须与资源点的传参一样，并且最后加上BlockException异常参数；同时，返回类型也必须一样。

熔断：

@SentinelResource注解除了可以用来做限流控制之外，还能实现与Hystrix类似的熔断降级策略。下面就来具体看看如何使用吧。

  1. 使用@SentinelResource注解标记资源点
  2. 如果异常率超过50%，那么后续2秒内的调用将直接出发熔断降级，默认情况会直接抛出DegradeException异常
  3. 自定义的话，只需要使用@SentinelResource注解的fallback属性来指定具体的方法名即可。这里也需要注意传参与返回必须一致。

核心

  • 资源 (Resource): 这是Sentinel要保护的对象。在代码中，它可以是一个方法、一段代码，甚至是一个URL请求。我们通过@SentinelResource注解或API调用来定义一个资源。
  • 规则 (Rule): 这是定义如何保护资源的核心。规则描述了在什么条件下，对资源采取何种保护措施。Sentinel的主要规则包括：
    1. 流量控制规则 (Flow Rule): 这是最常用的规则，即“限流”。它定义了当资源的某个指标（如QPS或并发线程数）达到阈值时，如何处理新的请求（如直接拒绝、排队等待）。
    2. 熔断降级规则 (Degrade Rule): 当资源的响应时间过长或异常比例过高时，Sentinel会暂时“熔断”该资源，在接下来的一段时间内，所有对该资源的调用都会被直接拒绝，直到恢复期过后，再尝试恢复调用。这可以防止故障服务拖垮整个系统。
    3. 系统保护规则 (System Rule): 从整个应用的维度进行保护。当应用的整体负载（如Load、CPU使用率）或入口QPS、并发线程数等达到阈值时，会限制所有入口流量，防止应用被冲垮。这是Sentinel的一个独特亮点。
    4. 来源访问控制规则 (Authority Rule): 也叫黑白名单控制。可以根据请求的来源（origin）来决定是否允许访问资源。
    5. 热点参数限流规则 (Param Flow Rule): 一种更精细化的限流。它允许我们对某个资源的特定参数值进行限流。例如，对查询商品详情的接口，可以针对被频繁访问的“热门商品ID”进行单独限流，而其他普通商品ID不受影响。

Sentinel的工作模式是：“实时统计，规则校验”。它在内存中为每个资源维护了一个滑动的“时间窗口”，实时统计该资源在窗口期内的各项指标（QPS、响应时间、异常数等），每次请求到来时，都会依次应用所有规则进行校验，一旦某个规则被触发，请求就会被阻止。

底层分析：

1.流量控制的底层实现：滑动窗口算法 (Sliding Window)

这是Sentinel实现精确、实时限流的基石，也是面试中的高频考点。

  • 数据结构 LeapArray: Sentinel并没有使用一个简单的计数器，而是采用了一种名为LeapArray的环形数组结构来实现滑动窗口。
    • 窗口 (Window): LeapArray默认创建一个长度为1秒（可配置）的统计窗口。
    • 时间桶 (Bucket): 这个1秒的窗口被进一步划分为多个（默认2个，即每500ms一个）更小的时间桶。每个时间桶独立记录这段时间内的请求成功数、失败数、响应时间等信息。
    • 滑动: 随着时间的推移，新的请求会落入当前最新的时间桶。当时间窗口向前滑动时，最老的时间桶会被清空并复用，成为新的当前时间桶。
  • 工作流程:
    1. 当一个请求进入某个资源时，Sentinel会根据当前时间定位到LeapArray中对应的时间桶。
    2. 对该时间桶的统计数据（如成功QPS）进行原子自增（CAS操作）。
    3. Sentinel会聚合整个时间窗口内所有桶的统计数据，得到最近1秒的总QPS。
    4. 将这个总QPS与流控规则中设定的阈值进行比较。如果超过阈值，则触发流控，拒绝请求。
  • 优点: 这种设计既保证了统计的实时性（数据总是在最新的时间窗口内），又通过分桶平滑了流量统计，避免了在窗口边界可能出现的“毛刺”问题，使得限流更加精准。

2.熔断降级的状态机机制

Sentinel的熔断器实现了一个经典的状态机模型，包含三种状态：

  1. Closed (闭合状态): 默认状态，所有请求正常通行，并持续收集异常和慢调用指标。当指标达到熔断规则的阈值时，熔断器切换到Open状态。
  2. Open (打开状态): 熔断开启，所有对该资源的请求都会被快速失败，直接返回错误。Open状态会持续一个预设的“熔断时长”（如10秒）。
  3. Half-Open (半开状态): 熔断时长结束后，熔断器进入Half-Open状态。它会尝试性地放行一次请求。
    • 如果这次请求成功，则认为服务已恢复，熔断器切换回Closed状态。
    • 如果这次请求失败，则认为服务仍未恢复，熔断器重新切换回Open状态，并开始新一轮的“熔断时长”计时。

这个状态机机制确保了服务在故障时能被快速隔离，并在其恢复后能被自动发现和重新纳入服务体系，实现了故障的自动隔离与恢复。

3.应用

给想用的方法加上@SentinelResource注解，然后注解上定义blockHandler和fallback

blockHandler和fallback的区别是面试高频题。

  • blockHandler：只处理因Sentinel规则（流控、熔断等）被触发而抛出的BlockException。
  • fallback：处理所有在方法执行过程中抛出的业务异常（Throwable）。

4.规则化和高可用

默认情况下，Sentinel的规则存储在应用的内存中，一旦应用重启，规则就会丢失。这在生产环境中是不可接受的。

  • 解决方案: Sentinel提供了DataSource扩展接口，允许我们将规则持久化到外部存储中。
  • 与Nacos的完美结合: 最常见的实践就是使用Nacos作为Sentinel规则的持久化数据源。
    1. 配置: 在Spring Cloud应用中，添加sentinel-datasource-nacos依赖。
    2. 规则推送: 在Nacos控制台创建配置，内容为JSON格式的Sentinel规则数组。
    3. 客户端拉取: 应用启动时，Sentinel的Nacos数据源会自动从Nacos拉取规则配置，并注册一个监听器。
    4. 动态刷新: 当您在Nacos控制台修改规则并发布后，Nacos会通知Sentinel客户端，客户端会立即更新内存中的规则，实现规则的动态、实时管理，无需重启应用。
  • Dashboard高可用: Sentinel的Dashboard主要用于监控展示和临时的规则配置，其本身是无状态的。核心的流量保护逻辑完全在客户端SDK中。因此，Dashboard宕机不影响已运行应用的防护能力。在生产中，可以部署多个Dashboard实例以实现其自身的高可用。