Sentinel 流量控制

菜菜菜—-

527人浏览 · 2026-03-04 10:01:41

菜菜菜—- · 2026-03-04 10:01:41 发布

Sentinel 安装步骤与工作原理

一、Sentinel 安装步骤（推荐单机部署，适合新手入门）

Sentinel 安装核心分为「Sentinel Dashboard（控制台）部署」和「客户端（微服务）集成」两部分，单机部署适合测试环境，生产环境需部署集群，以下是基于 Windows/Linux 的通用单机部署流程，兼顾简单易操作和实用性。

1.1 环境准备

JDK 环境：确保已安装 JDK 1.8 及以上版本，配置 JAVA_HOME 环境变量，通过 java -version 验证安装成功（控制台输出 JDK 版本信息即为正常）。
下载 Sentinel 安装包：核心需下载两个资源——Sentinel Dashboard 控制台 jar 包、客户端依赖（集成到微服务），下载地址：https://github.com/alibaba/Sentinel/releases（推荐稳定版本 1.8.x）。
微服务环境（可选）：若需测试客户端集成，提前准备 Spring Boot/Spring Cloud 微服务项目（客户端集成以 Spring Boot 为例）。
端口准备：默认占用 8080 端口（控制台），若 8080 端口被占用，启动时可指定自定义端口，避免端口冲突。

1.2 Sentinel Dashboard（控制台）部署

Sentinel Dashboard 是可视化管理控制台，用于监控资源、配置规则（限流、熔断等）、查看监控数据，核心是一个可直接运行的 jar 包，部署步骤简单。

步骤1：下载并存放控制台 jar 包

从官方 GitHub 下载 Sentinel Dashboard 的 jar 包（如 sentinel-dashboard-1.8.6.jar），将其存放至指定目录（如 Windows：D:\sentinel；Linux：/usr/local/sentinel），无需解压，直接通过命令启动。

步骤2：启动控制台

打开终端（Windows：CMD/PowerShell；Linux：终端），进入 jar 包所在目录，执行启动命令，支持默认启动和自定义端口启动：

默认启动（占用 8080 端口）：

java -jar sentinel-dashboard-1.8.6.jar

自定义端口启动（若 8080 端口被占用，如指定 8858 端口）：

java -jar sentinel-dashboard-1.8.6.jar --server.port=8858

启动成功标志：控制台输出 “Tomcat started on port(s): 8080 (http) with context path ''”（或自定义端口），无报错信息。

步骤3：访问控制台

打开浏览器，输入访问地址：http://localhost:8080（默认端口）或 http://localhost:自定义端口，进入登录页面，默认账号和密码均为 sentinel。

登录成功后，进入控制台主页，此时暂无监控数据（需集成客户端并发起请求后，才会显示资源监控信息）。

1.3 客户端（微服务）集成（Spring Boot 示例）

客户端是嵌入在微服务中的组件，用于采集资源访问数据、执行控制台配置的规则（限流、熔断等），与控制台通信，上报监控数据，集成步骤如下：

步骤1：引入客户端依赖

在 Spring Boot 项目的 pom.xml 中，添加 Sentinel 客户端核心依赖（版本与控制台保持一致，避免兼容性问题）：


   <version>1.8</version>
<!-- 客户端与控制台通信依赖（必加，否则无法上报<dependency<groupId>com.alibaba.csp<artifactId>sentinel-transport-s</artifactId><version>1</version</dependency>

步骤2：配置客户端（application.yml）

添加 Sentinel 客户端配置，指定控制台地址，确保客户端能与控制台通信，核心配置如下：

spring:
  application:
    name: order-service # 微服务名称（控制台中显示的资源所属服务名）

# Sentinel 客户端配置
sentinel:
  transport:
    dashboard: localhost:8080 # 控制台地址和端口（与控制台启动端口一致）
    port: 8719 # 客户端与控制台通信的端口，默认 8719，若被占用自动递增（无需手动修改）
  # 取消控制台懒加载（默认懒加载，需发起请求才会注册到控制台）
  eager: true

步骤3：标记需要保护的资源

通过注解 @SentinelResource 标记需要被 Sentinel 保护的资源（如接口方法、业务方法），指定资源名，示例如下：

@RestController
@RequestMapping("/order")
public class OrderController {

    // 标记资源，resourceName 为资源唯一标识（控制台中可根据该名称配置规则）
    @SentinelResource(resourceName = "createOrder")
    @PostMapping("/create")
    public String createOrder() {
        // 模拟业务逻辑：创建订单
        return "订单创建成功";
    }
}

步骤4：测试客户端注册

启动微服务客户端，此时客户端会自动注册到 Sentinel 控制台（因配置了 eager: true，无需发起请求），登录控制台，在「簇点链路」中可看到标记的 createOrder 资源，说明客户端集成成功。

1.4 补充说明（可选）

生产环境部署：控制台可部署集群（通过 Nginx 负载均衡），客户端配置多个控制台地址（用逗号分隔），确保高可用；客户端无需集群，每个微服务节点单独集成即可。
规则持久化：默认情况下，控制台配置的规则（限流、熔断等）在控制台重启后会丢失，生产环境需配置规则持久化（如集成 Nacos、Apollo、数据库），避免规则丢失。

二、Sentinel 工作原理

Sentinel 核心定位是「分布式系统流量治理组件」，基于“流量控制 + 熔断降级 + 系统保护”三大核心能力，解决微服务架构下的流量激增、服务雪崩等问题，核心原理围绕「资源监控 + 规则执行」展开，架构简洁、性能高效。

2.1 核心架构（控制台 + 客户端）

Sentinel 采用「控制台（管理面）+ 客户端（数据面）」分离架构，两者各司其职、协同工作，无需依赖第三方中间件，部署简单、交互高效，核心分工如下：

2.1.1 控制台（管理面，Sentinel Dashboard）

独立部署的可视化管理端，不参与客户端的流量处理，仅负责“管理和配置”，核心职责：

接收客户端上报的资源监控数据（如请求量、响应时间、异常率），并进行可视化展示（簇点链路、监控图表）。
提供规则配置界面（限流、熔断、降级、系统保护等），支持手动配置规则，配置后实时推送至客户端。
管理客户端节点（查看已注册的客户端、资源列表），支持手动清除客户端规则、重置监控数据。
核心优势：轻量级、可视化，无需复杂配置，可快速完成规则配置和监控查看。

2.1.2 客户端（数据面，Sentinel Core）

嵌入在微服务中的核心组件，是 Sentinel 实现流量治理的关键，负责“流量采集、规则执行、数据上报”，核心职责：

资源采集：通过 @SentinelResource 注解或手动编码，采集需要保护的资源（接口、方法）的访问数据（请求量、QPS、响应时间等）。
规则执行：接收控制台推送的规则（或本地配置的规则），在资源被访问时，实时执行规则校验（如限流：超过QPS阈值则拦截请求；熔断：服务异常率过高则暂时熔断）。
数据上报：定期将资源访问数据、规则执行结果上报至控制台，供控制台展示和分析。
本地缓存：客户端会缓存控制台推送的规则，即使控制台故障，客户端仍可基于本地缓存的规则正常执行流量控制，不影响业务运行（保障高可用）。

2.2 核心工作流程（重点）

Sentinel 的完整工作流程围绕“资源访问 → 规则校验 → 数据上报”展开，步骤清晰，核心逻辑如下（按顺序执行）：

资源标记与采集：客户端通过@SentinelResource 注解标记需要保护的资源，当客户端接收请求、调用该资源时，Sentinel 客户端会采集该资源的访问信息（请求时间、请求状态、响应时间等）。
规则获取与缓存：客户端启动后，自动连接控制台，获取控制台配置的该资源的所有规则（限流、熔断等），并将规则缓存至本地内存，后续规则更新时，控制台会实时推送至客户端，更新本地缓存。
规则执行与流量控制：每次访问标记的资源时，客户端会先校验本地缓存的规则，根据规则类型执行对应的控制逻辑：

- 限流规则：判断当前请求QPS/并发数是否超过阈值，超过则拦截请求，返回自定义提示或默认提示。
- 熔断规则：判断当前资源的异常率/响应时间是否超过阈值，超过则熔断该资源（暂时停止接收请求），避免服务雪崩。
- 若规则校验通过，正常执行业务逻辑；若校验失败，拦截请求并执行降级逻辑（自定义降级方法或默认降级）。

监控数据上报：客户端定期（默认每隔1秒）将资源的访问数据（请求量、通过数、拦截数、异常率等）上报至控制台，控制台接收数据后，进行统计分析并可视化展示（如实时监控图表、簇点链路）。
规则动态更新：在控制台修改规则后，控制台会实时将新规则推送至对应的客户端，客户端更新本地缓存，无需重启微服务，规则即可实时生效（动态配置特性）。

2.3 核心特性工作原理（重点）

Sentinel 的核心能力的是流量控制、熔断降级、系统保护，三者工作原理各有侧重，共同保障分布式系统的稳定性，重点掌握前两者：

2.3.1 流量控制（核心能力）

流量控制（限流）的核心目的是“限制资源的访问速率”，避免因流量激增导致服务过载，核心原理是「令牌桶/漏桶算法」（Sentinel 底层默认采用令牌桶算法，优化后更适配分布式场景）。

核心逻辑：

预设一个“令牌桶”，系统按固定速率（如每秒10个）向桶中放入令牌，令牌桶有最大容量（超过容量的令牌会被丢弃）。
每次请求访问资源时，都需要从令牌桶中获取一个令牌，获取到令牌则允许访问，获取不到则拦截请求（限流）。
支持多种限流维度：QPS（每秒请求数）、并发数、IP、用户、请求参数等，可在控制台灵活配置，适配不同业务场景。

示例：为 createOrder 资源配置 QPS 限流阈值为5，即每秒最多允许5个请求访问该资源，超过5个则被拦截，避免该接口因流量过大而崩溃。

2.3.2 熔断降级（核心能力）

熔断降级的核心目的是“避免故障扩散”，当某个资源（或依赖的服务）出现异常（如响应超时、异常率过高）时，暂时“熔断”该资源，停止接收请求，等待一段时间后尝试恢复，防止因单个服务故障导致整个微服务集群雪崩。

核心原理（基于熔断器模式，分三个状态切换）：

闭合状态（正常状态）：资源正常运行，熔断器关闭，所有请求正常访问资源，同时统计资源的异常率/响应时间。
打开状态（熔断状态）：当资源的异常率/响应时间超过预设阈值（如异常率超过50%），熔断器从闭合切换为打开，此时所有请求都会被拦截，不允许访问该资源，避免故障扩散；同时设置一个“熔断时长”（如5秒）。
半打开状态（恢复状态）：熔断时长结束后，熔断器从打开切换为半打开，允许少量请求（如1个）访问该资源，若请求正常执行（无异常），则熔断器切换为闭合状态（资源恢复正常）；若请求仍异常，则熔断器重新切换为打开状态，延长熔断时长。

核心优势：无需手动干预，自动完成“熔断-恢复”流程，有效防止服务雪崩，保障系统整体稳定性。

2.3.3 系统保护（补充能力）

系统保护是从“系统整体维度”进行防护，避免因单个资源流量过大，导致整个系统 CPU、内存、IO 过载，核心原理是「监控系统指标，动态调整流量」。

核心逻辑：监控系统的 CPU 使用率、内存使用率、磁盘 IO、线程数等指标，当某个指标超过预设阈值，Sentinel 会自动限制所有资源的访问速率，优先保障系统核心资源的正常运行，避免系统崩溃。

2.4 关键特性工作原理补充

规则动态更新：基于客户端与控制台的长连接通信，控制台修改规则后，通过长连接实时推送至客户端，客户端更新本地缓存，无需重启微服务，实现规则热更新。
高性能：客户端底层采用 Netty 异步通信，规则校验逻辑轻量（基于本地缓存），对业务接口的性能影响极小（单机 QPS 可达几十万），适合高并发场景。
无侵入性：通过注解 @SentinelResource 标记资源，无需修改业务代码核心逻辑，集成成本低，适配现有微服务架构。
规则持久化：默认规则存储在控制台内存中，重启后丢失；生产环境可集成 Nacos、Apollo 等配置中心，将规则持久化到配置中心，控制台重启后从配置中心加载规则，避免规则丢失。