Sentinel实战

1. Sentinel规则推送模式

Sentinel规则的推送有下面三种模式:

推送模式	说明	优点	缺点
原始模式	API 将规则推送至客户端并直接更新到内存中，扩展写数据源（WritableDataSource）	简单，无任何依赖	不保证一致性；规则保存在内存中，重启即消失。严重不建议用于生产环境
Pull 模式	扩展写数据源（WritableDataSource）， 客户端主动向某个规则管理中心定期轮询拉取规则，这个规则中心可以是 RDBMS、文件 等	简单，无任何依赖；规则持久化	不保证一致性；实时性不保证，拉取过于频繁也可能会有性能问题。
Push 模式	扩展读数据源（ReadableDataSource），规则中心统一推送，客户端通过注册监听器的方式时刻监听变化，比如使用 Nacos、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。生产环境下一般采用 push 模式的数据源。	规则持久化；一致性；快速	引入第三方依赖

1.1 原始模式

如果不做任何修改，Dashboard 的推送规则方式是通过 API 将规则推送至客户端并直接更新到内存中：

这种做法的好处是简单，无依赖；坏处是应用重启规则就会消失，仅用于简单测试，不能用于生产环境。

1.2 拉模式

pull 模式的数据源（如本地文件、RDBMS 等）一般是可写入的。使用时需要在客户端注册数据源：将对应的读数据源注册至对应的 RuleManager，将写数据源注册至 transport 的 WritableDataSourceRegistry 中。

首先 Sentinel 控制台通过 API 将规则推送至客户端并更新到内存中，接着注册的写数据源会将新的规则保存到本地的文件中。使用 pull 模式的数据源时一般不需要对 Sentinel 控制台进行改造。这种实现方法好处是简单，坏处是无法保证监控数据的一致性。

1.3 推模式

生产环境下一般更常用的是 push 模式的数据源。对于 push 模式的数据源,如远程配置中心（ZooKeeper, Nacos, Apollo等等），推送的操作不应由 Sentinel 客户端进行，而应该经控制台统一进行管理，直接进行推送，数据源仅负责获取配置中心推送的配置并更新到本地。因此推送规则正确做法应该是 配置中心控制台/Sentinel 控制台 → 配置中心 → Sentinel 数据源 → Sentinel，而不是经 Sentinel 数据源推送至配置中心。这样的流程就非常清晰了

使用说明

1，在官网下载可视化版本

home | Sentinel

2.1 获取 Sentinel 控制台

可以从 release 页面 下载最新版本的控制台 jar 包。

您也可以从最新版本的源码自行构建 Sentinel 控制台：

• 下载 控制台 工程
• 使用以下命令将代码打包成一个 fat jar

mvn clean package

2.2 启动

注意：启动 Sentinel 控制台需要 JDK 版本为 1.8 及以上版本。

使用如下命令启动控制台：

java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar

其中 -Dserver.port=8080 用于指定 Sentinel 控制台端口为 8080。

从 Sentinel 1.6.0 起，Sentinel 控制台引入基本的登录功能，默认用户名和密码都是 sentinel。可以参考 鉴权模块文档 配置用户名和密码。

注：若您的应用为 Spring Boot 或 Spring Cloud 应用，您可以通过 Spring 配置文件来指定配置，详情请参考 Spring Cloud Alibaba Sentinel 文档。

3. 客户端接入控制台

控制台启动后，客户端需要按照以下步骤接入到控制台。

3.1 引入JAR包

客户端需要引入 Transport 模块来与 Sentinel 控制台进行通信。您可以通过 pom.xml 引入 JAR 包:

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-transport-simple-http</artifactId>
    <version>x.y.z</version>
</dependency>

3.2 配置启动参数

启动时加入 JVM 参数 -Dcsp.sentinel.dashboard.server=consoleIp:port 指定控制台地址和端口。若启动多个应用，则需要通过 -Dcsp.sentinel.api.port=xxxx 指定客户端监控 API 的端口（默认是 8719）。

除了修改 JVM 参数，也可以通过配置文件取得同样的效果。更详细的信息可以参考 启动配置项。

3.3 触发客户端初始化

确保客户端有访问量，Sentinel 会在客户端首次调用的时候进行初始化，开始向控制台发送心跳包。

注意：您还需要根据您的应用类型和接入方式引入对应的 适配依赖，否则即使有访问量也不能被 Sentinel 统计。

4. 查看机器列表以及健康情况

当您在机器列表中看到您的机器，就代表着您已经成功接入控制台；如果没有看到您的机器，请检查配置，并通过 ${user.home}/logs/csp/sentinel-record.log.xxx 日志来排查原因，详细的部分请参考 日志文档。

注意：若接入 Sentinel 控制台不成功，可以参考 FAQ 排查问题。

注意：请确保在使用较新版本的浏览器，我们不保证支持旧版本的浏览器。

5. 监控

5.1 "簇点链路"中显示刚刚调用的资源（单机实时）

簇点链路（单机调用链路）页面实时的去拉取指定客户端资源的运行情况。它一共提供两种展示模式：一种用树状结构展示资源的调用链路，另外一种则不区分调用链路展示资源的运行情况。

注意: 簇点监控是内存态的信息，它仅展示启动后调用过的资源。

6.场景

限流

1. 使用场景

服务限流是在高并发场景下，为了保护系统资源和稳定性而采取的一种手段，常用于保护核心服务。以下是一些常见的使用场景：

• 突发流量：当系统遇到某些特殊情况（比如抢购、秒杀、某些热门活动等），会出现短时间内大量的请求，这时就需要限流保护系统。
• 高峰期流量控制：针对一些特定的时间段或者一些高峰期，可以通过限流控制请求流量，避免系统被压垮。
• 不同客户端的流量控制：比如针对 API 接口，对来自不同客户端的请求进行流量控制，避免某个客户端的请求量过大影响整个系统。
• 同时访问共享资源的流量控制：比如访问数据库、缓存等共享资源，为了避免出现死锁、过载等问题，需要对访问频率进行限制。
• 防止恶意攻击：有些攻击行为是通过大量的请求来消耗系统资源，通过限流控制可以避免这种情况的发生。

总之，服务限流适用于需要保护核心服务，避免系统因过载而崩溃的场景。

2.方案实现

限流方案 | jhon的技术分享

熔断

服务熔断是指在微服务架构中，当某个服务出现故障或超时时，为了保护系统整体的可用性和稳定性，将该服务的调用自动切断，而不是继续请求并等待超时或故障恢复。熔断后，后续的请求将直接返回错误或缓存数据，避免对故障或超时服务的无效调用，从而避免了系统的连锁反应和雪崩效应。

什么是熔断器？

熔断器（Circuit Breaker）是一种用于处理分布式系统中的故障和延迟问题的设计模式。它可以防止出现故障的远程服务引起系统的崩溃，从而提高了系统的稳定性和可用性。下面是关于熔断器的一些问题的回答。

2.方案实现

通过集成 Sentinel 实现熔断，配置熔断的QPS阈值，当目标服务达到阈值时进行熔断

降级

1. 降级和熔断的比较

比较项	服务降级	服务熔断
定义	临时关闭一些非核心服务或功能，减少系统压力，保证核心服务正常运行	当系统出现不可避免的故障，自动断开不可用的服务节点，保证系统稳定性
触发条件	系统负载过高、外部依赖服务不可用等	服务响应时间过长、错误率过高等
作用	减少系统压力，保证核心服务可用	防止故障扩散，保证系统稳定性
应对策略	临时关闭非核心服务、服务降级等	断开不可用的服务节点，降低系统并发度
执行机制	人工干预或自动检测触发	自动检测触发
效果	提升系统的可用性和稳定性，保护核心服务	防止故障扩散，避免服务雪崩
适用场景	系统负载过高、外部依赖服务不可用等	长时间等待、错误率过高等
实现方式	代码层面的控制或配置文件控制	程序代码或第三方库实现

服务降级和服务熔断唯一区别是，降级是主动关闭服务导致依赖的服务被降级，而服务熔断是自动断开依赖的服务连接。

2.方案实现