Gateway-Feign-Nacos-Ribbon-Sentinal

俊祺.

已于 2023-04-04 13:36:06 修改

阅读量450

点赞数

文章标签： dubbo java 分布式

于 2023-04-04 01:19:20 首次发布

本文链接：https://blog.csdn.net/weixin_73241486/article/details/129943292

版权

文章介绍了在微服务架构中，如何使用Sentinel、Ribbon和Feign等工具进行服务保护，包括流量控制、熔断降级、负载均衡等。Sentinel通过流量控制和熔断机制确保系统稳定性，Ribbon提供负载均衡策略，Feign则简化了服务调用。同时，Nacos作为配置中心，支持环境隔离和服务分级存储，确保配置的实时更新。文章还讨论了服务雪崩的原因和解决方案，强调了微服务架构中服务保护的重要性。

摘要由CSDN通过智能技术生成

Gateway

在你们的项目中用到了网关的哪些功能 ?

你在开发过程中经常使用的路由断言有哪些 ?

Feign的服务调用和Dubbo有什么区别?

使用Feign调用服务过程中超时怎么办?

使用Feign进行远程调用, 如何实现负载均衡 ?

如何提高Feign的服务调用效率 ?

Nacos

Nacos作为配置中心的原理

Nacos如何实现环境隔离 , namespace知道嘛 ?

什么是Nacos服务分级存储模型 ?

Nacos中注册的服务实例类型有哪些 ?

Nacos和Eureka有什么区别 ?

项目启动的时候是先加载本地文件还是Nacos中的文件 ?

如何实现配置的热更新 , 配置改变的情况下不修改源码即可实现配置的更新 ?

你们项目中是如何使用Sentinal的 ?

sentinel支撑的流控模式有哪些 ?

sentinel支持的流控效果有哪些 ?

sentinel是否可以实现对指定热点数据访问限流 ?

sentinel中如何对一个普通的方法限流 ?

sentinel断路器知道嘛 ? 他是怎么工作的 ?

sentinel什么情况下会触发熔断降级 ?

sentinel限流底层是通过什么机制实现的 ?

sentinel如何实现对访问来源的控制 ?

sentinel中配置的规则是如何保存的 ? 重启之后还生效嘛 ?

Gateway

在你们的项目中用到了网关的哪些功能 ?

路由

跨域

鉴权

限流

Spring Cloud Gateway 是 Spring Cloud 微服务框架下的网关组件，可以作为 API 网关来提供路由、过滤、负载均衡以及服务保护等功能。下面列出了 Spring Cloud Gateway 常见的几项功能：

路由(Route)转发功能
Spring Cloud Gateway 具有路由转发功能，可以根据请求内容（例如 URL、请求头、请求参数等），将请求路由到指定的服务实例中。路由可以根据正则表达式、通配符等方式进行模式匹配，也可以进行路径重写等操作。

过滤(Filter)功能
Spring Cloud Gateway 支持各种过滤器，可以拦截来自客户端的请求并进行处理。例如，可以使用过滤器进行请求验证、异常处理、请求重试、请求日志记录等。

负载均衡(Load Balance)功能
Spring Cloud Gateway 可以通过整合 Spring Cloud Ribbon，来实现多种负载均衡算法，并将请求分发到不同的服务节点上，从而提高了微服务架构的可扩展性和弹性。

断路器(Circuit Breaker)功能
Spring Cloud Gateway 整合了 Hystrix 来实现断路器功能，当后端服务因异常或超时而不可用时，可以通过断路器进行熔断，让请求快速失败而不是一直等待，有效保护客户端和服务器的运行稳定性。

支持 WebSocket
Spring Cloud Gateway 支持 WebSocket 协议，可以代理 WebSocket 请求并根据路径路由到指定的 WebSocket 服务端实例。

集成 Spring Security
Spring Cloud Gateway 可以和 Spring Security 集成，支持基于 OAuth2 的安全认证。它可以拦截所有外部请求，并进行认证与鉴权，从而保障了微服务架构的安全性。

请求缓存(Request Caching)功能
Spring Cloud Gateway 支持请求缓存，可以对一些无需实时返回的请求响应进行缓存，有效提升服务性能。

综上所述，Spring Cloud Gateway 是一款功能强大的 API 网关，其可以实现路由转发、过滤、负载均衡、断路器、WebSocket、安全认证等多种功能。这些功能可以共同有效地提升微服务系统的可扩展性、高可用性、可靠性和安全性。

你在开发过程中经常使用的路由断言有哪些 ?

Path : 根据请求路径匹配

Before/After : 根据时间路由 , 一般用于新版本上线

Header : 根据请求头路由, 一般用户灰度发布

Spring Cloud Gateway 中的路由断言（Predicate）用于根据请求匹配路由规则，通常需要与过滤器（Filter）一同使用。下面列举了开发过程中常用的路由断言：

1. Path Route Predicate（路径匹配规则）
Path Route Predicate 用于基于请求的路径来匹配路由规则，可以使用 Ant 风格的路径模式匹配，例如：
.routes()
  .route("path_route", r -> r.path("/foo/**")
   .uri("http://localhost:8080"))
  .build();
2. Host Route Predicate（主机名匹配规则）
Host Route Predicate 用于基于请求的 Host 来匹配路由规则，例如：
.routes()
  .route("host_route", r -> r.host("**.example.org")
   .uri("http://localhost:8080"))
  .build();
3. Query Route Predicate（请求参数匹配规则）
Query Route Predicate 用于根据请求的参数进行路由匹配，例如：
.routes()
  .route("query_route", r -> r.query("foo","bar")
   .uri("http://localhost:8080"))
  .build();
4. Methods Route Predicate（请求方法匹配规则）
Methods Route Predicate 用于基于请求的 HTTP 方法（GET、POST、PUT、DELETE等）进行匹配，例如：
.routes()
  .route("method_route", r -> r.method("POST")
   .uri("http://localhost:8080"))
  .build();
5. Header Route Predicate（请求头匹配规则）
Header Route Predicate 用于基于请求的 HTTP 头来匹配路由规则，例如：
.routes()
  .route("header_route", r -> r.header("X-Request-Id", "foobar")
   .uri("http://localhost:8080"))
  .build();
6. RemoteAddr Route Predicate（IP 地址匹配规则）
RemoteAddr Route Predicate 用于根据请求的远程 IP 地址匹配路由规则，例如：
.routes()
  .route("ip_route", r -> r.remoteAddr("192.168.0.1")
   .uri("http://localhost:8080"))
  .build();
上述是在 Spring Cloud Gateway 中经常使用的一些路由断言，开发人员可以根据实际需求选择合适的路由断言进行配置。

你们在开发中经常用到的过滤器有哪些 ?

AddRequestHeader : 添加请求头 , 用户sentinel黑白名单

RequestRateLimiter : 限流配置

StripPrefix : 取消路径前缀

Spring Cloud Gateway 支持多种类型的过滤器，可以根据实际需求来使用不同类型的过滤器。下面列举了开发中经常使用的过滤器：

网关全局过滤器
通过实现 GlobalFilter 接口，可以在网关请求的前后进行拦截处理，例如添加头部信息、记录日志等。

过滤器工厂类
通过实现 GatewayFilterFactory 接口，可以创建具有特定功能的过滤器。例如，使用 AddRequestHeader GatewayFilterFactory 可以添加请求头，使用 RewritePath GatewayFilterFactory 可以重写请求路径。

重试过滤器
在服务不可用或异常的情况下，使用 RetryGatewayFilter 可以进行请求重试。

限流过滤器
使用 RateLimiterGatewayFilter 可以进行限流操作，限制流量访问。

熔断过滤器
使用 Hystrix GatewayFilter 可以实现服务熔断，当服务出现故障时，可以暂时停止发送请求，以防止连锁反应，从而提高系统的可用性。

授权过滤器
在需要授权访问的情况下，使用 Spring Security Gateway Filter 可以在网关上进行授权校验，保护服务资源的安全访问。

综上所述，Spring Cloud Gateway 支持多种类型的过滤器，可以根据实际需求来使用相应的过滤器，例如全局过滤器、过滤器工厂类、重试过滤器、限流过滤器、熔断过滤器、授权过滤器等。这些过滤器可以为网关提供更加全面和强大的功能，也可以有效提升微服务架构的可扩展性和弹性。

有没有使用过网关的全局过滤器 ?

使用过, 主要通过自定义全局过滤器实现对请求的统一权限校验客户端发送请求携带token到网关, 由网关负责统一的token解析, 解析完毕之后获取token中的用户信息, 保存到请求头中, 路由到微服务

全局过滤器是 Spring Cloud Gateway 中的一种类型过滤器，它可以在每个请求的前后执行，不需要针对每个路由进行单独配置，可以实现一些通用的功能，例如处理请求日志、添加请求头、请求鉴权等。下面详细介绍一下网关的全局过滤器。

网关全局过滤器可以通过实现 GlobalFilter 接口实现，该接口定义了一个方法：
public interface GlobalFilter extends Ordered {
    Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
}
filter方法：在此方法中定义了过滤器在处理请求时需要执行的逻辑，其中 ServerWebExchange 对象提供了对请求和响应的一系列操作；
Ordered 接口：为过滤器提供了执行顺序策略，通过 getOrder() 方法来获取过滤器的执行优先级，默认值为 0，数值越小，优先级越高。

例如，下列代码展示了一个简单的全局过滤器，用于记录请求日志信息：
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.core.Ordered;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

@Component
public class LoggingGlobalFilter implements GlobalFilter, Ordered {

    private final Logger logger = LoggerFactory.getLogger(LoggingGlobalFilter.class);

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        logger.info("Request URI: {}", exchange.getRequest().getURI().toString());
        return chain.filter(exchange);
    }

    @Override
    public int getOrder() {
        return -1; // 优先级越高，数值越小
    }
}
        该过滤器可以打印出请求的 URI 信息，在请求路由之前做一些通用的前置处理。

        实现了 GlobalFilter 接口的 Bean 会自动注册到 Spring 应用程序上下文中，成为全局过滤器。

        综上所述，网关的全局过滤器可以实现一些通用功能，例如处理请求日志、添加请求头、请求鉴权等操作。开发人员可以根据业务场景进行定制化过滤器的编写，通过实现 GlobalFilter 接口并设置优先级来达到增强网关能力的目的。

Feign

什么是Feign？

Feign 是一个声明web服务客户端，这使得编写web服务客户端更容易
他将我们需要调用的服务方法定义成抽象方法保存在本地就可以了，不需要自己构建Http请求了，直接调用接口就行了，调用方法要和本地抽象方法的映射路径 , 参数和返回类型一致。

        Feign是一种用于声明式Web Service客户端的Java库。它基于Netflix的负载均衡器Ribbon和服务发现框架Eureka，采用接口的方式，将HTTP请求转换为Java方法调用，并以声明式方式来定义客户端的接口信息。使用Feign可以省去编写模板化的HTTP客户端的繁琐工作，在客户端与服务端之间形成一个类似于代理(proxy)的机制，使得对微服务实例的调用更方便、更高效。

        Feign有以下特点：

声明式的API：使用Java接口作为服务的抽象描述，不需要再使用RestTemplate或其他HTTP客户端进行请求的显式编写。

易于使用和集成：Feign是Spring Cloud项目中的一个子项目，容易和Spring Cloud集成，并且也能和其他服务发现组件集成。

支持Ribbon多节点：在访问服务时，Feign会自动向服务注册中心获取注册信息，并采用Ribbon的负载均衡器对请求进行负载均衡。

支持自定义拦截器：可以通过自定义拦截器来对请求进行加强，例如添加请求头、请求日志记录等。

支持插件扩展：可以通过自定义Decoder、Encoder、Contract来扩展Feign的功能。

        使用Feign可以大幅简化微服务间的调用方式，提高开发效率和可维护性，使开发人员更加专注于业务逻辑的编写。

Feign的服务调用和Dubbo有什么区别?

feign是基于HTTP协议的远程调用

Dubbo是基于RPC的远程调用

Feign 和 Dubbo 是两种不同的微服务调用框架，在一些方面存在一定的差异。

协议不同
Feign 是基于 HTTP 协议进行服务调用的微服务框架，而 Dubbo 则是基于 RPC 协议的微服务框架。

注册发现方式不同
Feign 采用 Spring Cloud 的服务发现组件（例如 Eureka），可以通过注册中心自动获取服务实例列表并进行负载均衡，而 Dubbo 有自己的注册中心组件（例如 ZooKeeper），可以发现可用服务实例。

编程模型不同
Feign 采用的是声明式客户端接口，并将 HTTP 请求转换为 Java 方法调用，使用更加简单明了；Dubbo 采用声明式客户端接口和事件编程模型进行服务调用，并使用代理模式实现服务暴露与引用。

传输协议不同
Feign 只支持 HTTP 协议，而 Dubbo 支持多种传输协议，包括 HTTP、Dubbo、Thrift、gRPC 等。

性能表现不同
基于 Dubbo 的性能测试与基于 Feign 的性能测试有所不同，但是总体来说基于 Dubbo 的性能表现更优秀。

分布式事务支持不同
Dubbo 支持分布式事务，而 Feign 不支持。

总体来说，两种框架各有优缺点，在不同的场景下选择适合的框架，可以更快速、高效地搭建、管理微服务系统。例如，对于 HTTP 服务调用较为简单场景，使用 Feign 较为轻便；而对于需要兼顾高性能、分布式事务等复杂场景，则可以选择 Dubbo 框架。

使用Feign调用服务过程中超时怎么办?

可以调整feign的超时时间

ConnectTimeout

ReadTimeout

在使用 Feign 进行微服务之间的调用时，由于网络等原因，可能出现超时的情况。针对这种情况，可以进行如下处理：

1. 调整超时时间
在 Feign 配置中，可以针对不同的服务设定不同的响应超时时间，如果超时时间设置过短，则有可能会在正常情况下产生误报，建议根据实际情况配置超时时间。例如，下面是一个配置连接超时时间和读取超时时间的 FeignClient 的示例：
@FeignClient(name = "xxxx", url = "http://localhost:8080",
    configuration = CustomFeignConfiguration.class)
public interface CustomFeignClient {
    @GetMapping("/timeout")
    String getTimeOut(@RequestParam long timeout);
}

@Configuration
public class CustomFeignConfiguration {

    @Bean
    public Request.Options options() {
        return new Request.Options(1000, 3000); // 超时时间设置为 1s 和 3s
    }
}
2. 重试
当调用失败时，可以选择进行重试。在 Feign 中，可以使用 Spring Retry 或者 Failsafe 等第三方库实现重试的逻辑。例如，下面是一个使用 Failsafe 库实现 FeignClient 调用重试的示例：
@FeignClient(name = "xxxx", url = "http://localhost:8080",
    fallback = CustomFeignClientFallback.class, configuration = CustomFeignConfiguration.class)
public interface CustomFeignClient {
    @Retryable(value = RuntimeException.class, maxAttempts = 3, backoff = @Backoff(delay = 1000, multiplier = 1))
    @GetMapping("/timeout")
    String getTimeOut(@RequestParam long timeout);
}

@Configuration
@EnableRetry
public class CustomFeignConfiguration {

    @Bean
    public RetryTemplate retryTemplate() {
        RetryTemplate retryTemplate = new RetryTemplate();
        SimpleRetryPolicy simpleRetryPolicy = new SimpleRetryPolicy(3);
        retryTemplate.setRetryPolicy(simpleRetryPolicy);
        FixedBackOffPolicy fixedBackOffPolicy = new FixedBackOffPolicy();
        fixedBackOffPolicy.setBackOffPeriod(2000L);
        retryTemplate.setBackOffPolicy(fixedBackOffPolicy);
        return retryTemplate;
    }
}
在该示例中，使用了 Failsafe 库，使用 @Retryable 注解进行重试操作，并在 CustomFeignConfiguration 类中对重试策略进行了配置。

3. 降级
当服务出现超时等异常时，可以选择使用 FallbackFactory 或者 Hystrix 等方式进行服务降级。例如，下面是一个使用 Hystrix 进行服务降级的示例：
@FeignClient(name = "xxxx", url = "http://localhost:8080",
    fallback = CustomFeignClientFallback.class, configuration = CustomFeignConfiguration.class)
public interface CustomFeignClient {
    @HystrixCommand(fallbackMethod = "customFallback")
    @GetMapping("/timeout")
    String getTimeOut(@RequestParam long timeout);
}

@Component
public class CustomFeignClientFallback implements CustomFeignClient {
    @Override
    public String getTimeOut(long timeout) {
        return "fallback";
    }
}

@Configuration
@EnableHystrix
public class CustomFeignConfiguration {

    @Bean
    public CustomFeignClientFallback customFallback() {
        return new CustomFeignClientFallback();
    }
}
在该示例中，使用了 Hystrix 进行服务降级，在 CustomFeignConfiguration 类中对服务降级逻辑进行了配置。

综上所述，针对 Feign 调用过程中出现超时的情况，可以通过调整超时时间、进行重试或者进行降级等方式进行处理，提高微服务的可用性和稳定性。

使用Feign进行远程调用, 如何实现负载均衡 ?

Ribbon

在使用 Feign 进行远程调用时，可以通过整合 Spring Cloud Ribbon 实现负载均衡。Ribbon 是一个负载均衡客户端，可以和多种服务注册中心以及多种协议进行结合使用。在默认情况下，Feign 实现了 Ribbon 的负载均衡能力，可以使用 @FeignClient 注解的 url 和 name 属性来指定服务的 URL 或名称，即可实现对服务实例的负载均衡调用。

以使用 Eureka 作为服务注册中心的示例如下：

1. 添加依赖

在 pom.xml 文件中添加如下的依赖：
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
</dependency>
2. 配置文件

在 application.yml 或 application.properties 文件中，添加如下配置：
eureka:
  client:
    service-url:
      defaultZone: ${EUREKA_SERVER:http://localhost:8761}/eureka/
    enabled: true
3. 创建 FeignClient

在代码中创建一个 FeignClient，示例如下：
@FeignClient(name = "service-demo", fallback = ServiceFallback.class)
public interface DemoClient {
    @GetMapping("/demo")
    String getDemo();
}
4. 写相关服务实现

编写服务的实现类，包含服务名称为 “service-demo”，例如：
@RestController
public class DemoController {
    @GetMapping("/demo")
    public String demo() {
        return "demo success";
    }
}
5. 测试

测试调用 FeignClient 接口的方法即可，例如：
@RestController
public class TestController {

    @Autowired
    private DemoClient client;

    @GetMapping("/test")
    public String test() {
        return client.getDemo();
    }
}
在上述示例中，使用了 FeignClient 进行远程调用，通过 @FeignClient 注解指定服务名为 “service-demo”，使用 Ribbon 实现服务的负载均衡。在编写 FeignClient 接口时，可以通过 url 属性指定服务的 URL 地址，也可以通过配置文件中的 ribbon 相关属性来配置 Ribbon 的负载均衡行为。

如何提高Feign的服务调用效率 ?

Feign底层采用URLConnection发起远程调用, 默认不支持连接池

我们可以修改底层实现使用OkHttp , HttpClient 实现远程调用 , 这样连接可以回收 , 提升了效率具体做法就是

添加feign-httpclient依赖
配置使用HttpClient

在使用 Feign 进行微服务之间的调用时，可能会遇到一些效率低下的问题，这里介绍几种方法来提高 Feign 的服务调用效率。

1. 增加连接池大小
在 Feign 的使用过程中，如果存在大量的 HTTP 请求，请求就会被阻塞在连接等待资源池中。可以通过在配置文件中修改 maxTotalConnections 属性配置值，从而增加连接池的大小。例如，可以在配置文件 application.yml 中添加如下配置：
httpclient:
  maxTotalConnections: 500
2. 关闭 SSL 验证
在使用 HTTPS 时，若不需要对服务端进行验证，则可以关闭 SSL 验证，从而提高性能。可以在配置文件中添加如下配置来关闭 SSL 验证：
ribbon:
  eureka:
    enabled: true
    ssl: false
3. 配置请求超时
在配置文件中配置请求超时时间，避免因请求超时导致线程堵塞。可以在 Feign 的配置类中使用 Request.Options 配置项来设置请求超时时间：
@Configuration
public class FeignConfig {
    @Value("${feign.client.config.default.connectTimeout:5000}")
    private int connectTimeout;
    @Value("${feign.client.config.default.readTimeout:30000}")
    private int readTimeout;

    @Bean
    public Request.Options requestOptions() {
        return new Request.Options(connectTimeout, readTimeout);
    }
}
4. 关闭日志
在 Feign 中，可以进行请求日志的记录，对于性能较差的请求，需要关闭日志。可以在配置文件中设置 Feign 的日志等级为 NONE 级别，从而关闭日志记录：
logging:
  level:
    com.netflix.discovery: OFF
    com.netflix.eureka: OFF
    com.netflix.ribbon: OFF
    com.netflix.hystrix: OFF
    com.netflix.zuul: OFF
    org.springframework.cloud.netflix.ribbon: OFF
5. 禁用重试
在 Feign 中默认开启了重试机制，但开启重试会增加请求耗时，如果业务允许可以禁用重试。在配置文件中设置 Feign 的重试机制为禁用：
feign:
  client:
    config:
      default:
        retry-on-all-operations: false
综上所述，以上是提高 Feign 的服务调用效率的几个方法：增加连接池大小、关闭 SSL 验证、配置请求超时、关闭日志、禁用重试。可以根据实际情况选择适合的方法来提高 Feign 的性能。

Nacos

Nacos作为配置中心的原理

1 服务提供者在nacos上注册服务信息,然后发送数据到服务端

2 服务消费者主动去服务端上拉取数据

Nacos 是阿里巴巴开源的一个动态服务发现、配置管理和服务治理平台，可以作为配置中心来为微服务提供集中式管理与配置。Nacos 作为配置中心的原理可以简单概括如下：

服务注册
服务提供者向 Nacos 注册服务，并将包括服务名、IP、端口号等信息注册到 Nacos 服务注册中心中，实现服务的动态发现与注册。

配置管理
服务消费者从 Nacos 中心读取配置信息，Nacos 支持多种格式的配置，包括 properties、xml、JSON、yml 等。在 Nacos 的管理界面，可以通过配置服务列表和配置详情页面快速管理和编辑配置信息。

实现动态配置
通过 Nacos 配置中心，可以实现配置与代码的分离，服务提供者可以动态修改配置信息，这样就不需要重新部署应用程序，提高了开发和运维的效率。

集成Spring Cloud
使用 Spring Cloud 集成 Nacos，可以进一步提高使用效率和降低开发成本。Spring Cloud 的配置抽象出配置 API 来支持不同的配置中心，并使用标准的 PropertySources 抽象来封装属性源的集合，以实现配置中心的透明使用。

综上所述，Nacos 作为动态服务发现、配置管理和服务治理平台，可以为微服务提供丰富的配置管理能力，帮助开发人员快速实现微服务开发和部署。

Nacos如何实现环境隔离 , namespace知道嘛 ?

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

nacos中可以有多个namespace

namespace下可以有group、service等

不同namespace之间相互隔离，例如不同namespace的服务互相不可见

namespace 命名空间

可以自己指定也可以默认产生UUID , 在application.yml配置文件中配置

        在使用 Nacos 作为配置中心时，可能需要在不同的环境中（例如开发环境、测试环境、生产环境）使用不同的配置信息，这就需要实现环境隔离。Nacos 中可以使用 Namespace 来实现环境隔离。

        Namespace 是 Nacos 配置中心的一个重要概念，它是一个逻辑隔离的概念空间，各个 Namespace 之间是相互隔离的，不同 Namespace 可以拥有不同的服务实例、配置信息和权限等，并且在默认情况下，一个 Namespace 下面的数据是不能被其他 Namespace 访问的。

        在 Nacos 中，Namespace 的作用主要有以下几个方面：

环境隔离
可以使用不同的 Namespace 来实现不同环境下的配置隔离，例如开发环境、测试环境、生产环境等。

权限控制
各个 Namespace 之间是相互隔离的，可以根据实际业务需求为不同 Namespace 分配不同的权限。

版本管理
在不同的 Namespace 中，可以针对不同的版本进行配置的管理和发布。

同步和复制
通过将不同的 Namespace 进行复制或同步，可以在多个地域、多个数据中心之间实现数据的可靠复制和同步。

        可以通过 Nacos 控制台，在 Namespace 管理页面进行 Namespace 的创建、删除、编辑以及切换等操作。在 Nacos 的 API 中，会通过 Namespace 的信息来进行服务的注册、发现和配置的读取等操作。

        在使用 Namespace 时，需要注意：

同一 Namespace 下的配置信息可以在不同的服务中共享。

Namespace 中的信息是相对隔离的，不同 Namespace 下的信息互相独立。

使用不同的 Namespace 时需要注意权限、版本等情况。

如果 Namespace 没有指定，则使用默认 Namespace。

        综上所述，Nacos 的 Namespace 功能提供了灵活的配置管理方式，可以实现环境隔离、权限控制、版本管理等功能，大大提高了系统的安全性和灵活性。

什么是Nacos服务分级存储模型 ?

一个服务可以有多个实例 , 假如这些实例分布于全国各地的不同机房 ,

Nacos就将同一机房内的实例划分为一个集群 , 一个服务可以包含多个集群，形成分级模型

配置 discovery: cluster-name: HZ # 集群名称即可实现

配置之后微服务互相访问时，会尽可能访问同集群实例，因为本地访问速度更快。当本集群内不可用时，才访问其它集群

        Nacos 服务分级存储模型是一种根据数据的关键性和访问频率，将数据进行分类存储和管理的模型。该模型将 Nacos 存储的数据划分为两个不同层级的存储模型：

1. 配置数据

        配置数据通常是根据服务的配置文件来进行存储。配置数据可能经常被访问，但是对于整个服务的运行来说是非常重要的，因此需要保持高可用性。

在 Nacos 的服务分级存储模型中，配置数据会被存储在 MySQL 数据库中，从而确保配置数据的高可用性。此外，Nacos 还提供了多种高可用性的保障机制，包括数据备份、数据恢复、心跳检测等。

2. 元数据

        元数据是指与服务本身相关的数据，例如服务的 IP 地址、端口号、心跳时间和状态等。通常来说，元数据更新的频率非常高，但是对于整个服务的稳定性来说，并不是非常关键。

        在 Nacos 的服务分级存储模型中，元数据会被存储在 Nacos 的内存中，即使用 Nacos 的集群模式部署时，元数据只会被存储在 Nacos 的一个节点上。这样虽然可能导致元数据不如配置数据可靠，但是从整体上来看，仍然可以保证服务不出现问题。

        综上所述，Nacos 服务分级存储模型将数据根据其关键性和访问频率分成两个层级存储，以满足各种不同的存储需求，并为系统提供高可用性的服务支持，保证了服务的可靠性和稳定性。

Nacos中注册的服务实例类型有哪些 ?

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

临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。

非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

在 Nacos 中，服务实例是指可以提供服务的应用程序、容器等。通过将服务实例注册到 Nacos 上，可以实现服务的动态发现和注册。Nacos 中可以注册多种类型的服务实例，具体包括以下几种：

常规服务实例
常规服务实例指运行在特定主机上的服务实例，例如基于 Tomcat、Jetty 或 Spring Boot 等容器的应用程序。

虚拟服务实例
虚拟服务实例指的是通过 DNS 或者负载均衡器等方式将多个服务实例组合成单独的虚拟 IP 地址的服务实例。虚拟服务实例的一个优点是可以让前端无需知道后端的真实 IP 地址和端口，在多服务实例情况下，负载均衡器可以根据负载情况动态分配请求。

子服务实例
子服务实例是指一个大的服务内部有多个小的服务，这些小的服务使用子服务的方式注册到 Nacos 服务注册中心，在服务提供方无法直接注册一个大服务的情况下使用。

健康检查实例
健康检查实例是指通过心跳机制来告知 Nacos 服务注册中心，该服务实例是否健康可用。健康检查实例的目的是让 Nacos 注册中心能够及时感知到服务实例的状态变更，及时更新服务实例列表，保证客户端能够访问到有效的服务。

综上所述，Nacos 中注册的服务实例类型包括常规服务实例、虚拟服务实例、子服务实例和健康检查实例，每一种实例类型都有其特定的应用场景和优点，可以根据实际需求选择适合的服务实例类型进行注册。

Nacos和Eureka有什么区别 ?

Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式

临时实例心跳不正常会被剔除，非临时实例则不会被剔除

Nacos支持服务列表变更的消息推送模式，服务列表更新更及时

Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；

Eureka采用AP方式

        Nacos 和 Eureka 都是服务注册中心，用于提供服务的动态发现和注册。虽然它们都具有类似的功能，但是在一些实现细节和特性上又有不同的地方。下面是 Nacos 和 Eureka 的主要区别：

1. 数据存储方式

        Nacos 使用了基于 Raft 协议的 MySQL 存储配置信息和服务实例信息，由于使用了 MySQL 数据库，因此 Nacos 在数据的安全性和可靠性方面更为优秀。而 Eureka 使用的是内存存储方式，虽然它在性能方面更为出色，但是在数据安全性和可靠性上还存在着一定的问题。

2. 统一配置管理

        Nacos 支持统一配置管理，并且支持数据变更的实时发布和推送，而 Eureka 不支持配置管理，并且需要使用第三方工具进行配置管理。

3. 健康检查机制

        Nacos 支持比 Eureka 更多的健康检查机制，如 TCP、HTTP、MySQL 等等，并且支持自定义扩展。而 Eureka 只支持基于 HTTP 的心跳机制。

4. 服务路由规则

        Nacos 支持服务之间的路由和流量控制，并支持动态配置路由规则，这个特点在微服务架构中非常有用。而 Eureka 不支持服务之间的路由和流量控制。

5. 开发者社区和生态系统

        Nacos 是由阿里巴巴开源的，自身在功能、性能、安全性等方面都有很大优势，并在国内有较为广泛的用户群体和生态系统。而 Eureka 发展较早，但是现在的开发者社区已经不如 Nacos 火热，其生态系统也不够完善。

        综上所述，虽然 Nacos 和 Eureka 在某些方面有相似之处，但是它们在技术实现、特性和生态环境等方面存在一定的不同。因此，在实际项目中，选择使用哪一种服务注册中心需要根据实际需求和项目特点来综合考虑。

项目启动的时候是先加载本地文件还是Nacos中的文件 ?

在本地文件中会配置Nacos配置中心地址, 所以肯定是先加载本地配置文件, 连接上Nacos再加载配置中心中的文件

        在使用 Nacos 作为配置中心时，程序启动时通常会从 Nacos 中读取配置信息。如果配置信息在 Nacos 中更新，应用程序会快速响应，自动进行配置更新。如果 Nacos 不可用，应用程序则会使用先前缓存的本地配置文件。

        具体来说，如果开发者在应用程序中使用 Spring Cloud 与 Nacos 集成，则应用程序启动时会通过 Spring Cloud 的 Config Client 从 Nacos Server 中获取配置信息。首先，Config Client 会通过 Config Server 端点来获取需要的配置信息，Nacos Config Server 会优先判断获取的配置版本是否与本地一致，如果一致，将读取本地缓存的配置文件，否则将从 Nacos 中心读取最新的配置文件替换本地文件。

        在没有使用 Spring Cloud 的情况下，如果应用程序使用 Nacos 的 SDK 来读取配置，则启动时也会从 Nacos 中心获取最新的配置信息，但是需要注意，此时应用程序需要自行判断配置版本是否与本地一致，并根据启动参数或其他机制来控制是否重新加载最新的配置文件。

        综上所述，既可以加载本地文件，也可以加载Nacos中的文件，但是在应用程序与Nacos集成时，通常会优先从Nacos中心获取最新的配置信息。如果Nacos不可用，则会使用之前的本地缓存配置文件。

如何实现配置的热更新 , 配置改变的情况下不修改源码即可实现配置的更新 ?

我们使用Nacos作为配置中心, 实现热更新非常简单, 有二种方式 ;

在需要热更新的类上添加@RefreshScope注解, 使用@Value注解读取需要更新的配置
使用@ConfigurationProperties注解代替@Value注解 , 可以直接实现热更新，当配置方式改变的时候, Nacos会主动向服务推送改变的内容

在使用 Nacos 作为配置中心时，可以基于 Nacos 提供的监听机制实现配置的热更新，以实现不修改源码即可实现配置的更新。具体来说，可以通过以下步骤来实现：

在应用程序中引入 Nacos 配置客户端依赖，可以是 Spring Cloud Config 或者 Nacos SDK。

在应用程序的配置文件中指定 Nacos 的配置信息，包括 Nacos 服务器地址、命名空间、应用名称等等。

在应用程序中定义需要动态刷新的配置项，同时通过调用 Nacos 配置客户端的 API 来初始化这些配置项，以保证应用程序启动时能够读取到最新的配置文件。

使用 Nacos 客户端提供的监听机制来监听配置的变化，当配置变化时，可以触发特定的处理逻辑，例如可以重新加载配置信息。

对于 Spring Cloud 应用程序，可以使用 Spring Cloud Bus 来发布配置更新事件，从而实现多节点应用程序之间的配置更新事件同步。

综上所述，通过使用 Nacos 提供的配置监听机制以及相关的客户端依赖库和 API，可以实现配置的热更新。在配置变化时，应用程序无需修改源码，就能够自动更新配置，从而达到更新部署、降低故障等目的。

Ribbon

Ribbon是如何实现负载均衡的 ?

1 发送请求，被LoadBalancerInterceptor拦截器拦截，请求被交给ribbon来处理

2 拦截器拦截请求，交给了RibbonLoadBalancerClient的execute方法（下面的逻辑都是包含在这个方法中）

3 在进行负载均衡之前首先得知道有哪些服务实例信息，所以通过DynamicServerListLoadBalancer的updateListOfServers方法从注册中心（Eureka）那里获取到了所有的服务实例信息，并且会定时更新

4 使用负载均衡算法（默认轮询算法）从所有的服务实例信息中选择一台机器出来

5 将请求发送给负载均衡选择出来的服务实例上去

        Ribbon 是 Netflix 开源的一个基于客户端的负载均衡框架，可以帮助服务消费者在调用远程服务时完成负载均衡。Ribbon 组件实现了均衡负载的算法，它基于客户端实现负载均衡，将请求分发到多个服务提供方节点上。

Ribbon 在实现负载均衡时，主要依赖于以下几个重要的组件和算法：

1. 服务列表

        Ribbon 通过服务注册中心来维护服务列表，将其存储在缓存中，以便于负载均衡器选择一个可用的服务实例。

2. 负载均衡算法

        Ribbon 提供了多种负载均衡算法，如轮询、随机、加权轮询、加权随机等，通过选择不同的算法实现不同类型的负载均衡策略。例如，在轮询算法中，每个请求按照顺序依次分配到不同的服务提供方上；而在加权随机算法中，每个服务提供方被分配到的请求数量是按照其权重比例随机确定的。

3. 状态检查

        Ribbon 使用心跳检测机制来检查服务提供方的健康状态，同时去除不可用的服务提供方，以确保只有可用的服务提供方被选择进行请求处理。

4. 失败重试

        当请求失败时，Ribbon 支持自动进行重试，以提高服务的可用性和负载均衡的准确性。

        综上所述，Ribbon 通过服务列表、负载均衡算法、状态检查和失败重试等机制，完成了对服务消费者请求的路由和负载均衡处理，实现了客户端负载均衡。通过负载均衡的技术，Ribbon 可以有效地提高服务的可用性、性能和扩展性，是微服务架构中的一个重要组件。

Ribbon支持的负载均衡策略有哪些?

RoundRobinRule 轮询策略默认采用线性负载轮询负载均衡策略
AvailabilityFilteringRule 可用性过滤策略该策略根据服务状态 (宕机和繁忙) 来分配权重，过滤掉那些因为一直连接失败或高并发的服务实例
WeightedResponseTimeRule 加权响应时间策略是 RoundRibbonRule 的一个子类，它对 RoundRibbonRule 的功能进行了扩展。它根据每一个服务实例的运行情况先计算出该服务实例的一个权重，然后根据权重进行服务实例的挑选，这样能够调用到更优的服务实例。
ZoneAvoidanceRule 区域感知轮询策略该策略以区域、可用的服务器为基础，选择服务实例并对服务实例进行分类
BestAvailableRule 最空闲策略该服务是逐个考察各服务实例，然后选择一个最小的并发请求的服务实例来提供实例
RandomRule 随机策略随机选择一个可用的服务实例。
RetryRule 重试策略

Ribbon 支持多种负载均衡策略，可以通过在配置文件中指定 Ribbon 负载均衡器的属性来定义使用哪种负载均衡策略。以下是 Ribbon 支持的几种负载均衡策略：

轮询（Round Robin）策略
轮询策略是 Ribbon 默认的负载均衡策略，它会按照服务器列表顺序轮流发送请求，均衡地分配流量到每一个服务节点，如果有节点宕机，则会自动跳过该节点。

随机（Random）策略
随机策略会从服务端列表中随机选择一个服务节点来处理请求，并且每个服务节点被选中的概率是相等的。

权重（Weighted）轮询策略
权重轮询策略会根据每个服务实例的权重来进行流量分配，权重越高的服务节点会被分配到更多的请求，通常可以用于处理一些性能差异较大的服务节点。

响应时间加权（Response Time Weighted）策略
响应时间加权策略会根据每个服务实例的平均响应时间来进行流量分配，响应时间越短的服务节点会被分配到更多的请求，通常可以用于处理服务实例响应延时较小的场景。

最小连接数（Least Connections）策略
最小连接数策略会选取当前连接数最小的节点来处理请求，这样可以保证相对较少的连接数承载更多的请求。

Session Stickiness（Session 方式的一致性哈希）策略
Session Stickiness 策略会根据请求的 SessionID 来选择服务节点，从而保证同一个 Session 的请求总是被路由到同一个服务节点处理。

综上所述，Ribbon 支持的几种负载均衡策略包括轮询、随机、权重轮询、响应时间加权、最小连接数和 Session Stickiness 策略。开发者可以根据具体的业务场景，选择合适的负载均衡策略。

如何修改Ribbon的负载均衡策略 ?

修改Ribbon负载均衡策略的方式有二种 :

在配置类中配置IRule
在application.yml配置文件中配置

在使用 Ribbon 作为负载均衡器时，可以通过指定配置文件中的 ribbon 系列属性来修改负载均衡策略。具体来说，可以通过以下步骤来修改 Ribbon 的负载均衡策略：

1. 在应用程序的配置文件中添加 Ribbon 的相关配置属性。

例如，在使用 Spring Cloud Netflix 构建的微服务应用中，可以在配置文件中添加以下内容来修改 Ribbon 的负载均衡策略：
```
ribbon:
  eureka:
    enabled: true
    listOfServers: localhost:8761
  NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
```
其中，ribbon.eureka.enabled 指定是否启用 Ribbon 和 Eureka 集成，ribbon.eureka.listOfServers 指定 Eureka 服务注册中心地址，NFLoadBalancerRuleClassName 指定 Ribbon 的负载均衡器实现类名。

2. 在 com.netflix.loadbalancer 包下编写自定义负载均衡器实现类。

如果想要修改 Ribbon 的负载均衡策略，可以继承其提供的 AbstractLoadBalancerRule 抽象类，实现自定义的负载均衡算法。例如，下面是一个自定义的基于随机数的负载均衡器实现类：
```
public class CustomRandomRule extends AbstractLoadBalancerRule {
    private Random random = new Random();

    @Override
    public void initWithNiwsConfig(IClientConfig clientConfig) {
    }

    @Override
    public Server choose(Object key) {
        List<Server> servers = this.getLoadBalancer().getReachableServers();
        if (servers == null || servers.size() == 0) {
            return null;
        }
        Server server = servers.get(random.nextInt(servers.size()));
        return server;
    }
}
```
3. 将自定义的负载均衡器实现类配置到应用程序中。

可以通过在应用程序的配置文件中设置 NFLoadBalancerRuleClassName 属性的值，来指定自定义的负载均衡器实现类名，例如：
```
ribbon:
  eureka:
    enabled: true
    listOfServers: localhost:8761
  NFLoadBalancerRuleClassName: com.example.CustomRandomRule
```
通过上述方法，可以实现对 Ribbon 的负载均衡策略进行自定义。可以选择提供的默认负载均衡策略，也可以编写自定义的负载均衡器实现类，根据具体的业务需求进行选择和配置。

如何自定义负载均衡策略?

Ribbon自定义负载均衡也很简单 , 自己创建类实现IRule接口 , 实现里面的choose方法即可 , 至于具体的负载均衡规则如何做是什么就要看具体的需求了

在使用 Ribbon 作为负载均衡器时，可以自定义负载均衡策略，通过继承 com.netflix.loadbalancer.AbstractLoadBalancerRule 抽象类，并实现 choose 方法来自定义负载均衡策略。具体的步骤如下：

1. 创建自定义负载均衡器

创建一个自定义的负载均衡器，在该负载均衡器中实现所需的负载均衡策略。
public class CustomLoadBalancer extends AbstractLoadBalancerRule {

    @Override
    public Server choose(Object key) {
        ILoadBalancer loadBalancer = this.getLoadBalancer();
        List<Server> serverList = loadBalancer.getAllServers();
 
        // 实现自定义的负载均衡策略....
 
        return null;
    }
}
在该类中，通过重写 choose 方法实现具体的负载均衡策略。其中，getLoadBalancer 方法可以获取当前负载均衡器的实例对象，并使用 getAllServers 方法获取所有可用的服务实例列表。

2. 配置自定义的负载均衡器

在应用程序的配置文件中，指定所使用的自定义负载均衡器的完整路径即可使用它对服务实例进行负载均衡。
# 指定自定义负载均衡器，并设置为默认策略
my.ribbon.NFLoadBalancerRuleClassName=com.example.CustomLoadBalancer
        在上述配置中，my.ribbon.NFLoadBalancerRuleClassName 属性指定了使用的自定义负载均衡器的完整路径，同时将其设置为默认的负载均衡策略。

3. 启用自定义的负载均衡器

        通过 Spring Cloud 的配置文件机制，将自定义的负载均衡器纳入应用程序启动流程，启动应用程序即可使用自定义的负载均衡器。

        综上所述，通过自定义负载均衡器，可以实现对 Ribbon 负载均衡策略进行更加灵活和定制化的控制。可以适配不同的业务场景，满足不同的负载均衡需求。

Sentinal

了解过服务雪崩 ?

微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务 ,

如果其中一个下游服务出现了问题 , 或者服务器负载比较高 , 处理缓慢,

这个时候就会导致上游服务等待 , 线程得不到释放 , 最后导致服务器资源耗尽宕机,

然后他的上游服务同样如此, 这样因为一个服务导致上游的所有服务都出现问题的线下称之为雪崩

        是的，服务雪崩是一种常见的系统故障，是指当一个服务不可用或响应缓慢时，其它依赖该服务的服务也出现了类似的故障，从而导致整个系统的不可用或延迟过高的情况。这种现象类似于雪崩，堆积在一起的问题最终导致系统的瘫痪。

        在微服务架构中，服务之间的调用关系通常形成一张复杂的依赖关系图，如果一个服务的故障引起其依赖的服务也出现故障，那么这些故障就会像连锁反应一样，不断扩大，直至所有服务都不可用。这种情况下，整个系统就会出现大规模故障，给业务和用户带来严重影响。

        服务雪崩通常是由于某些单点故障、过度依赖某个服务、资源竞争等原因引起的。为了避免服务雪崩，可以采取以下的一些措施：

1. 实现服务高可用

为服务添加冗余节点，保证服务的高可用性。当某个节点发生故障时，其他节点可以顶替它的工作，保证整个服务的可用性。

2. 限流与熔断

通过限流和熔断机制，可以在高峰期限制流量，防止服务在负载过高的情况下出现故障；同时，当服务发生故障时及时切断与之相关的调用，以避免故障的扩大。

3. 梳理依赖关系

尽可能降低服务间的依赖关系，通过合理的服务划分和对服务的拆分，减小服务之间的耦合，从而降低服务出现故障对整个系统的影响。

4. 监控与预警

及时对服务的状态、性能等进行监控，通过告警机制及时发现服务的异常情况，并及时采取应对措施。

综上所述，服务雪崩是一种常见的系统故障，可以通过服务高可用、限流与熔断、梳理依赖关系以及监控与预警等手段来预防和应对。

        Sentinel 是阿里巴巴开源的一种面向分布式系统的高可用保障组件，可以实现流量控制、熔断降级、系统负载保护等功能，有效预防服务雪崩，在服务不稳定或出现故障时保障系统的稳定性和可用性。

        Sentinel 在避免服务雪崩方面，主要通过以下两个方面实现：

1. 流量控制：

        Sentinel 可以对服务的流量进行实时控制和限制，当检测到某个服务发生性能瓶颈或超过负荷阈值时，可以立即采取限制流量的措施，避免流量过载导致服务雪崩。

2. 熔断降级：

        当一个服务出现故障或性能下降时，Sentinel 可以根据预先设置的规则对该服务的请求进行熔断降级处理，避免问题向下游服务传播并导致服务雪崩。通过熔断降级，可以在故障发生时快速切断与之相关的请求，防止问题扩散。

        综上所述，Sentinel 可以对服务进行流量控制和熔断降级等处理，避免服务雪崩的出现，保障系统的高可用和稳定性。Sentinel 在微服务应用中扮演着越来越重要的角色，可以帮助开发者有效地解决各种系统稳定性和可用性问题。

如何解决雪崩问题

超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待
线程隔离/信号量隔离
熔断降级

        服务雪崩问题是一种常见的系统故障，可能导致整个系统的不可用或延迟过高的情况。为了避免服务雪崩问题，可以考虑采取以下几种措施：

1. 实现服务高可用

        为服务添加冗余节点，保证服务的高可用性。在部署服务时要注意避免将所有的服务节点部署在同一台物理机上，以及将所有的服务节点部署在同一数据中心的同一可用区域中，这样一旦该节点或区域出现故障，整个系统就容易受到影响。采用分布式或云部署的方式，将服务节点分散在多台物理机或不同的可用区域中，可以有效降低服务出现雪崩的风险。

2. 限流与熔断

        通过限流和熔断机制，可以在高峰期限制流量，防止服务在负载过高的情况下出现故障；同时，当服务发生故障时及时切断与之相关的调用，以避免故障的扩大。限流和熔断规则应该根据具体服务和业务特点进行调整和优化。

3. 梳理依赖关系

        尽可能降低服务间的依赖关系，通过合理的服务划分和对服务的拆分，减小服务之间的耦合，从而降低服务出现故障对整个系统的影响。同时，对于一些被其他服务频繁调用的核心服务，可以考虑实现高可用、多副本部署、负载均衡等措施。

4. 监控与预警

        及时对服务的状态、性能等进行监控，通过告警机制及时发现服务的异常情况，并及时采取应对措施。监控和预警系统应该具备高可用性，以保证它们在服务雪崩事件发生时的可用性。

5. 系统设计和优化

        在系统设计和架构时，应该充分考虑系统的容错能力和可恢复性。例如，采用消息队列的方式将高峰期的流量缓存下来，避免流量直接冲击底层服务，导致服务雪崩。

        综上所述，服务雪崩问题是一种常见的系统故障，需要通过多方面的措施来避免和解决。除了上述措施外，还可以结合具体的业务场景和系统特点，制定更加具体、有效的防范措施。服务雪崩是一个综合性的问题，需要从多方面联合起来解决。

        Sentinel 作为分布式系统的高可用保障组件，可以通过流量控制、熔断降级等方式来解决服务雪崩问题，保障系统的稳定和可用性。具体来说，Sentinel 可以通过以下两种方式来解决服务雪崩问题：

1.流量控制

        Sentinel 可以对服务进行实时的流量控制和限制，当检测到某个服务接口的流量过高或者超出了一个预设的负载阈值时，可以立即采取限制流量的措施，避免流量过载导致服务雪崩。Sentinel 支持基于并发数、QPS、线程数等多种流量控制模式，可以根据具体的业务需要进行灵活配置。

2. 熔断降级

        当一个服务的响应时间超过了一定的阈值，或者出现了一定的错误率时，Sentinel 可以根据预设的规则对该服务进行熔断降级处理，快速切断与之相关的请求，避免问题向下游服务传播并导致服务雪崩。熔断降级可以有效解决服务间的故障扩散和传递问题，从而避免整个系统的崩溃。

        综上所述，Sentinel 可以通过流量控制和熔断降级等方式来解决服务雪崩问题。在实际的应用中，建议根据系统的实际情况和业务需求，合理配置 Sentinel 的流量控制和熔断规则，保障系统的可用性和稳定性。同时，为了更好地发现和解决服务雪崩问题，还可以配合日志分析、监控告警等机制，及时发现和处理服务异常和故障。

你们项目中是如何使用Sentinal的 ?

sentinel使用非常简单

启动sentinel服务端

在项目找那个引入sentinel启动器

在application.yml中配置sentinel地址

在sentinel中配置各种控制规则

Sentinel 是一种分布式系统的高可用保障组件，为服务提供流量控制、熔断降级、系统负载保护等功能。以下是一些使用 Sentinel 的基本步骤：

1. 引入 Sentinel 依赖

使用 Sentinel 需要在项目中引入 Sentinel 相关的依赖，例如 Maven 依赖：
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
    <version>{sentinel-version}</version>
</dependency>
2. 配置 Sentinel 控制台

Sentinel 提供了一个可视化的控制台，可以通过控制台实时监控系统运行状态、配置熔断降级规则、配置限流规则等。需要下载 Sentinel 控制台的 jar 包（下载地址），并运行：
java -jar sentinel-dashboard-{version}.jar
Sentinel 控制台默认端口为 8080，启动后可以通过浏览器访问 http://localhost:8080 进行管理和监控。

3. 配置 Sentinel 注解

Sentinel 提供了一些注解，可以帮助我们快速地为服务实现限流、熔断等功能。例如，@SentinelResource 可以对一个服务进行流量控制和熔断降级处理：
@Service
public class DemoServiceImpl implements DemoService {
  @Override
  @SentinelResource(value = "sayHello", blockHandler = "blockHandler")
  public String sayHello(String name) {
    return "Hello " + name;
  }

  public String blockHandler(String name, BlockException ex) {
    return "Blocked by Sentinel: " + ex.getClass().getSimpleName();
  }
}
4. 配置 Sentinel 规则

Sentinel 可以通过规则来限制流量和配置熔断降级策略。我们可以通过 Sentinel 控制台配置规则，也可以在项目中配置规则。例如，可以通过 Sentinel API 设置熔断降级阈值：
DegradeRule rule = new DegradeRule("hello");
rule.setGrade(RuleConstant.DEGRADE_GRADE_RT);
rule.setCount(10);

List<FlowRule> rules = new ArrayList<>();
rules.add(rule);

FlowRuleManager.loadRules(rules);
        上述代码表示，对 hello 接口的响应时间进行熔断，当响应时间超过 10 ms 时会触发熔断降级。



5. 推荐配置 Sentinel 控制台

        将 Sentinel 控制台和规则配置合在一起，可以使得 Sentinel 的使用更加便捷。在 Sentinel 控制台中可以实时监控和管理系统的运行情况，同时可以配置规则等操作，实现服务的实时监控和快速调整。

        以上是 Sentinel 的一个基本使用流程，具体使用应根据实际情况和业务需求进行适当调整和细化。

sentinel支撑的流控模式有哪些 ?

直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式

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

链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流

        Sentinel 支持多种流控模式，不同模式适用于不同的业务场景。以下是 Sentinel 支持的常见流控模式：

1. 直接限流模式

        直接限流模式是 Sentinel 最基础的限流模式。它为每个资源单独设置限流阈值，当资源的请求量达到阈值时，Sentinel 会直接拒绝请求。这种模式适用于应对一些临时的流量突增情况。直接限流模式的数据来源可以是请求数、并发数、QPS 等。

2. 关联限流模式

        关联限流模式针对发起请求的资源和被请求资源之间的关联关系进行限流。当发起请求的资源，访问被请求的资源时“关联量”达到预先设定的阈值时，就会触发限流。它适用于解决关联的多个服务同时出现问题的情况，提供了全局限流保护。关联限流模式常用阈值来源有同机房机器节点数、二级分类 ID 等。

3. 预热限流模式

        在预热时间段内，限流器会自动将通过的流量增加到配置的阈值上限，从而避免因瞬间流量过大导致限流器直接拦截服务。这种模式适用于流量突增预警，对资源进行提前预热以避免限流，例如秒杀场景、抢购场景等等。

4. 令牌桶模式

        令牌桶模式是一种固定容量的令牌桶，令牌每隔固定时间自动添加一定数量的令牌，请求需要从令牌桶中获取令牌才能访问资源。如果令牌桶中的令牌已满，则新的请求将被拦截或排队等待。这种模式适用于对请求的流量进行严格的控制，以避免系统过载。例如，在高峰期对接口的流量进行限制。

        除了上述常见流控模式，Sentinel 还支持更加定制化的流控模式，例如：热点参数限流，针对特定参数进行限流；授权规则，对通过 OAuth2 等标准授权的资源进行限制；自适应限流等等。Sentinel 的灵活性和可扩展性，可以满足多种不同业务场景下的流控需求。

sentinel支持的流控效果有哪些 ?

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

1 快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。

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

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

Sentinel是一个开源的分布式系统，可以用于实现流量控制、熔断降级、系统负载保护等功能。在流量控制方面，Sentinel支持以下几种流控效果：

直接拒绝：当请求量达到设定的阈值时，直接拒绝后续请求。这是一种简单但比较暴力的流控方式，适用于应对短时间内突发的请求高峰。

排队等待：当请求量超过阈值时，将请求放入队列中，等待处理能力空闲时再进行处理。这种方式可以避免请求直接被拒绝，但会增加请求的等待时间。

平均响应时间限流：通过统计一段时间内每个请求的响应时间，计算平均响应时间和阈值，当请求的响应时间超过阈值时进行流控。这种方式可以避免因某一时刻请求压力过大而导致的流量控制。

QPS限流：按照一定时间间隔（如1秒）统计请求的数量，计算请求的 QPS（Queries Per Second），当 QPS 超过设定的阈值时进行流控。这种方式可以避免单个请求耗时过长而导致的请求量不足。

线程数限流：通过统计当前进程中的线程数，设定线程数的上限阈值。当线程数达到阈值时进行流控。这种方式可以避免因请求过多而导致的服务器负载过高。

CPU使用率限流：通过统计当前进程的CPU占用率，设定CPU占用率的上限阈值。当占用率达到阈值时进行流控。这种方式可以避免因某一时刻请求压力过大而导致的CPU过度占用。

总之，每种流控方式都有其适用的场景，通过不同的方式进行流控可以提高系统的可用性和稳定性。

sentinel是否可以实现对指定热点数据访问限流 ?

可以, sentinel支持热点参数限流 , 具体就是分别统计参数值相同的请求，判断是否超过QPS阈值。

具体就是需要在控制面板配置热点参数和阈值

        是的，Sentinel可以实现对指定的热点数据访问进行限流。在应用中，通常会有一些热点数据，即访问频率较高的数据，例如一些常用的配置信息、广告位等。这些数据如果没做好限流，容易导致系统负载过高，影响系统的稳定性。

        Sentinel可以通过在流控规则中使用参数例外项从而实现对指定热点数据的访问限流。参数例外项是用于限制某些参数或参数值的例外流控规则。即在对一组参数进行限流时，可以为其中的某个或某些参数的特定值设置例外流控规则。如果符合例外规则的请求，在不违反流控规则的情况下可以被通过。

        例如，假设我们要对名为/api/getConfig的接口中的configKey参数进行限流，但是针对一些特定的configKey值，我们需要做例外处理，即不进行限流。那么可以在Sentinel的流控规则中设置参数例外项，指定configKey值为特定值时不进行限流。

        可以使用以下方式设置参数例外项：
String resourceName = "get-config";
FlowRule rule = new FlowRule(resourceName);

// 设置参数例外项
ParamFlowItem paramFlowItem = new ParamFlowItem().setParseStrategy(ParamFlowItem.ParseStrategy.URL_PARAM)
                .setFieldName("configKey")
                .setMatchStrategy(ParamFlowItem.MatchStrategy.EXACT)
                .setMatchValue("hotconfig1");// hotconfig1是要例外的configKey的值

// 设置流控规则
rule.setParamItem(paramFlowItem);
rule.setCount(10); // 限制访问次数
rule.setGrade(RuleConstant.FLOW_GRADE_QPS); //限流的维度是QPS
rule.setLimitApp("default"); //默认限流应用
FlowRuleManager.loadRules(Collections.singletonList(rule)); // 加载规则
这样，当请求的configKey等于hotconfig1时，即使请求频率超过限制，也不会进行限流。

sentinel中如何对一个普通的方法限流 ?

想要使用sentinel限流 , 必须把方法标注为一个sentinel资源，通过@SentinalResource注解来标注方法即可

在Sentinel中，对一个普通的方法进行限流，需要结合 AOP（面向切面编程）的思想，通过在方法执行前后插入代码，在方法执行前判断当前方法的访问是否超过了限制，如果超过了限制就进行限流，否则就正常执行。常见的实现方式有两种：

基于注解的限流：通过自定义注解，将需要进行限流的方法打上注解，然后通过AOP在执行方法前进行解析注解并进行限流处理。这种方式相对简单，代码复用性较高。

基于切面的限流：通过定义切面，在指定的切点中进行方法拦截并进行限流处理。这种方式可以复用切面，在多个方法中进行限流处理。

        下面分别介绍这两种方式的实现方法：

        1. 基于注解的限流

        首先定义一个注解，例如@RateLimiter，用来标识需要进行限流的方法：
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface RateLimiter {
    String resource();
    int count() default 10; // 默认的限流阈值
    int limitApp() default 0; // 默认的限流应用编号
}
然后在AOP的切面中实现注解的解析和限流处理：
@Aspect
@Component
public class RateLimiterAspect {

    private final Logger logger = LoggerFactory.getLogger(RateLimiterAspect.class);

    @Autowired
    private SentinelGatewayFilter sentinelGatewayFilter;

    @Pointcut("@annotation(com.example.demo.annotation.RateLimiter)")
    public void rateLimiterPointcut() {}

    @Around("rateLimiterPointcut()")
    public Object around(ProceedingJoinPoint joinPoint) throws Throwable {
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method method = signature.getMethod();

        // 解析注解
        RateLimiter rateLimiter = method.getAnnotation(RateLimiter.class);
        String resource = rateLimiter.resource();
        int count = rateLimiter.count();
        int limitApp = rateLimiter.limitApp();

        // 进行限流处理
        if (sentinelGatewayFilter.filter(new ServerWebExchangeStub(), new SentinelGatewayBlockException(resource), limitApp)) {
            logger.warn("Access to [{}] has been limited", resource);
            throw new RuntimeException("Access to [" + resource + "] has been limited");
        }

        return joinPoint.proceed();
    }
}
        在这个切面中，首先通过注解解析获取需要限流的资源名resource，限流的阈值count和限流的应用编号limitApp，然后调用SentinelGatewayFilter的filter方法进行限流处理。如果处理结果为限流，则抛出异常并打印日志，否则继续执行方法。

        2. 基于切面的限流

        首先定义一个切面，例如RateLimiterAspect，在该切面中定义一个方法拦截器，用于在指定的切点中进行方法拦截并进行限流处理：
@Aspect
@Component
public class RateLimiterAspect {

    private final Logger logger = LoggerFactory.getLogger(RateLimiterAspect.class);

    @Autowired
    private SentinelGatewayFilter sentinelGatewayFilter;

    @Around("@annotation(com.example.demo.annotation.RateLimiter)")
    public Object around(ProceedingJoinPoint joinPoint) throws Throwable {
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method method = signature.getMethod();

        // 获取资源名
        RateLimiter rateLimiter = method.getAnnotation(RateLimiter.class);
        String resource = rateLimiter.resource();

        // 进行限流处理
        if (sentinelGatewayFilter.filter(new ServerWebExchangeStub(), new SentinelGatewayBlockException(resource), 0)) {
            logger.warn("Access to [{}] has been limited", resource);
            throw new RuntimeException("Access to [" + resource + "] has been limited");
        }

        return joinPoint.proceed();
    }
}
其中，在@Around注解中指定拦截注解@annotation(com.example.demo.annotation.RateLimiter)，即对打上@RateLimiter注解的方法进行拦截。

最后，在需要进行限流的方法上加上@RateLimiter注解即可，例如：
@RateLimiter(resource = "method.foo", count = 10, limitApp = 0)
public void foo() {
    // ...
}
这样，在执行foo()方法时，就会自动启用限流功能，当达到设定限制时，就会阻止请求。

sentinel断路器知道嘛 ? 他是怎么工作的 ?

状态机包括三个状态：

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

half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。请求成功：则切换到closed状态请求失败：则切换到open状态

        Sentinel的熔断器（Circuit Breaker）功能可以有效地防止因服务雪崩而导致整个系统瘫痪。熔断器不仅仅可以使得不可用的服务从调用者的服务调用链路中断开，还可以自动恢复，保护调用者的应用程序不受过载的服务的影响。

        Sentinel熔断器实现了Hystrix的设计原则，具有如下特点：

快速失败：当请求次数超过熔断器所设定的阈值时，熔断器会触发并快速的失败，不再向下游服务发送请求，并直接返回结果给调用方。这样可以尽早地发现问题，从而保护系统健康。

慢启动：当熔断器从打开状态恢复到关闭状态时，熔断器不会立即恢复，而是启用慢启动功能，逐步增加请求处理能力，在保证服务及调用方的合理负载下逐步进行请求处理。

熔断器打开后进入半开状态：当熔断器打开后，经过一段时间后，进入半开状态，允许小部分请求流经系统，检验服务是否已经恢复正常，从而避免服务负载过高导致的系统雪崩。

监控状态：熔断器会统计并记录各个时间窗口内的服务请求成功率、平均响应时间等信息，便于随时监控服务的状态。

        为了使用Sentinel熔断器功能，需要首先在应用程序中引入Sentinel依赖，并配置Sentinel资源，即需要进行熔断的调用链路。然后，使用Sentinel的API，比如SphU.entry()进入资源，当调用次数超过设定阈值时熔断器就会打开并触发快速失败。当资源出现异常时，调用方会通过Tracer.trace()方法上报异常，同时Sentinel会对异常进行统计分析，并根据实际情况自动判断是否需要打开熔断器，并进入半开状态和关闭状态，从而实现熔断和自动恢复的功能。

        在Sentinel中，每个资源都可以设置熔断器相关的参数，通常有以下几个参数：

熔断器打开的错误率阈值：达到该错误率时，断路器会打开。例如，设置为60%则表示当请求的错误率超过60%时，断路器会打开。

熔断器打开的请求量阈值：达到该请求量时，断路器会打开。例如，设置为10个请求，则表示当10个请求都失败时，断路器会打开。

熔断器打开后的等待时间：断路器打开后，需要等待一定的时间后再次尝试将请求转发到服务上，以判断服务是否已经恢复。例如，设置为5000ms，则表示断路器打开后，需要等待5秒后再次发送请求。

慢启动时间：当断路器从打开状态恢复到关闭状态时，需要经过一定的慢启动时间，逐步增加请求处理能力。例如，设置为5000ms，则表示慢启动阶段需要5秒才能完成。

        Sentinel熔断器能够有效地保护调用方的应用程序不受过载的服务的影响，增加系统的可靠性和稳定性。

sentinel什么情况下会触发熔断降级 ?

断路器熔断策略有三种：慢调用、异常比例、异常数 , 可以在sentinel控制台中配置

Sentinel熔断降级是指在服务调用链路中出现异常或超过设定的阈值时，熔断器会打开并停止将请求转发至下游服务，而是返回预设的数据或进行服务降级。Sentinel可以根据不同的规则维度来判断是否需要触发熔断降级，触发熔断降级通常有以下情况：

请求异常或错误率超过阈值：如果一个服务的请求发生错误或异常比率超过设定的阈值，就会触发熔断降级。比如，如果这个阈值设定为50%，那么当服务请求错误率超过50%时就会触发熔断降级。

QPS 超出设定的阈值：如果一个服务的请求 QPS （Queries Per Second）超出设定的阈值，就会触发熔断降级。比如，如果这个阈值设定为100，那么当服务的 QPS 超过100时就会触发熔断降级。

响应时间超过设定的阈值：如果一个服务的请求响应时间超出设定的阈值，就会触发熔断降级。比如，如果这个阈值设定为5秒，那么当服务的请求响应时间超过5秒时就会触发熔断降级。

请求超时：如果一个服务的请求在设定的时间内没有响应，就会触发熔断降级。比如，如果这个时间设定为3秒，那么当服务的请求响应超过3秒时就会触发熔断降级。

异常数超过设定的阈值：如果一个服务的异常数超过设定的阈值，就会触发熔断降级。比如，如果这个阈值设定为10，那么当服务的异常数超过10时就会触发熔断降级。

当以上任一规则被触发时，Sentinel熔断器就会打开，停止将请求转发至下游服务，并根据设定规则返回预设的响应或进行服务降级。当然，Sentinel也提供了丰富的配置项，可以根据具体业务需求进行定制。

sentinel限流底层是通过什么机制实现的 ?

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

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

        Sentinel限流底层主要是通过令牌桶算法实现的，令牌桶算法是一种流量控制算法，通过对请求的流量进行控制，保证系统在高负载情况下的稳定性。

        令牌桶算法基于令牌桶的思想，每当一个请求到来时，会向令牌桶中放入一个令牌，当令牌桶满时，再有请求到来时将无法获得令牌进入系统，从而实现请求的流量控制。同时，令牌桶数据结构也可以用来平滑流量，保证系统在高峰期不会出现突发性质的流量。

        Sentinel底层实现了令牌桶算法的限流器，它会通过不断地计算请求速率和成功率，来动态调整令牌桶的填充速度和桶的容量，从而实现对请求的流量控制，确保系统的稳定性和可用性。

        除了限流器，Sentinel还通过熔断器机制，监控系统中的异常和错误响应，对流量进行熔断和降级处理，防止流量飙升导致系统崩溃。同时，Sentinel还提供实时数据统计，可视化的监控界面，以及语义化的流量控制等功能，帮助开发者更好的进行流量控制和服务保护。

Sentinel限流是通过实现一组底层机制来实现的。这些机制包括：

请求入口：对于每一个受管理的服务，Sentinel需要一个请求入口来拦截所有的请求。入口可以是HTTP(S)、WebSocket、Dubbo等应用层协议，也可以是TCP/UDP等底层网络层协议。Sentinel以此来获取关于请求的上下文信息，并根据这些信息进行限流和熔断。

实时数据统计：Sentinel需要实时统计请求数、RT（Response Time, 响应时间）、异常数等信息。这些指标用于计算滑动窗口中的请求量，并驱动限流器的行为。Sentinel也会根据实时数据的变化来自动适应限流策略，从而保证服务在不同负载情况下的稳定性和可用性。

限流器（Flow Control）：Sentinel以令牌桶算法（Token Bucket Algorithm）实现了流控限流器。请求入口会将每一个到达的请求进行封装为一个Token，如果当前Token数量未达到限流器阈值，则通过；如果达到限流器阈值，则会不能直接被执行，需要等待Token token）达到了并被消耗掉，才能继续执行。

熔断器（Circuit Breaker）：Sentinel通过实现熔断器机制，当出现服务异常或超时时，可能会触发熔断器并直接返回降级或错误的响应。熔断器通常基于一组统计数据（如异常率、慢调用率等）并采用类似令牌桶算法的方式来控制调用请求的流量，从而防止故障服务的扩散和累积。

总之，Sentinel通过请求入口、实时数据统计、限流器以及熔断器等一系列机制来控制服务的请求流量，保证服务系统的可用性和稳定性。

sentinel如何实现对访问来源的控制 ?

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

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

主要做法就是 :

实现RequestOriginParser接口 , 从request对象中，获取请求者的origin值并返回

        Sentinel可以通过黑白名单机制实现对访问来源的控制。

        黑白名单机制是一种常见的访问控制方法，通过在系统中维护一份黑名单或者白名单，来控制系统中的访问者。其中，黑名单是包含不允许访问系统的IP地址列表，而白名单则是允许访问系统的IP地址列表。基于这个机制，我们可以对系统中的访问者进行访问控制。

        对于Sentinel，我们可以通过配置黑白名单规则对访问进行控制。首先，在Sentinel的控制台中创建一个新的限流规则，规则类型选择“流量控制”，然后在“黑白名单控制”选项中，勾选“开启规则”并选择黑白名单类型为“IP”，然后配置允许或者禁止访问的IP地址列表即可。

        此外，Sentinel还支持动态的黑白名单机制，即在运行时动态更改黑白名单规则。通过调用Sentinel提供的API，我们可以动态添加或者删除黑白名单规则，从而实现更精细化、灵活化的访问控制。

        总的来说，Sentinel通过黑白名单机制，可以实现对访问来源的控制，帮助开发者保障系统的安全和稳定。

sentinel中配置的规则是如何保存的 ? 重启之后还生效嘛 ?

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

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

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

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

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

开源的sentinel版本中不支持push模式, 需要修改源码实现

        Sentinel中配置的规则会被保存在本地磁盘上，以确保规则的持久化和可靠性。具体来说，Sentinel会将规则序列化为JSON格式，并存储到本地磁盘中的规则配置文件中。默认情况下，规则配置文件保存在应用程序的当前工作目录下，文件名为flow-rule.json，也可以通过配置文件进行更改。

        当Sentinel启动时，会读取本地磁盘上的规则配置文件，并加载其中的规则。这些规则将被用于实施对系统流量的控制、熔断和降级操作。在运行时，Sentinel也支持动态地增加、删除和修改规则，这些修改操作也会写回到本地磁盘上的规则配置文件中。

        在重启Sentinel时，由于规则已经被保存在本地磁盘上，因此规则配置将与上一次运行Sentinel时保持一致。这意味着即使重启Sentinel，之前配置的规则仍然是有效的。当然，如果您进行了调整或修改，可以重新启动Sentinel以使更改生效。

        需要注意的是，如果您以编程方式在Sentinel中添加或删除规则，则这些更改不会自动写入本地磁盘上的规则配置文件中。如果您需要将规则更改永久保存到磁盘，请确保使用Sentinel API中提供的writeLocalRule()方法手动写入规则配置文件。

        Sentinel中的规则被保存在本地磁盘上，以确保规则持久化和可靠性。在默认情况下，Sentinel的规则配置文件存储在应用程序当前的工作目录下，文件名为flow-rule.json，也可以在配置文件中进行相应的修改。

        当Sentinel启动时，会读取本地磁盘上的规则配置文件，并将其中的规则加载到程序中。在运行时，Sentinel支持动态地修改、添加和删除已经加载的规则以满足不同场景下的服务保护需求。

        但是，在重启Sentinel时，由于之前的规则已经被保存在本地磁盘上，因此会按照之前的配置重新加载规则，这意味着之前的规则依然是有效的。如果需要对规则进行修改，可以对规则配置文件进行相应的修改，然后重启Sentinel使更改生效。

        需要注意的是，在动态修改、添加和删除规则时，这些更改通常不会自动写入规则配置文件。如果需要将规则更改永久地保留在磁盘上，需要手动调用Sentinel API中提供的writeLocalRule()方法将更新后的规则写入规则配置文件。

        总之，Sentinel中的规则通过配置文件进行持久化，支持动态地修改和删除，能够在Sentinel重启时重新加载，并对服务流量进行保护。