1. 项目概述为什么我们需要Sentinel在微服务架构里服务之间的调用关系变得像一张复杂的蜘蛛网。一个订单服务可能要调用用户服务、库存服务、支付服务而支付服务又可能依赖外部的银行网关。当“双十一”零点流量洪峰涌来或者某个下游服务因为数据库慢查询突然“卡壳”问题就会像多米诺骨牌一样传导开来。最典型的场景就是“服务雪崩”A服务调用B服务B服务因为自身原因响应变慢导致A服务的线程池被大量等待B响应的线程占满进而A服务也无法处理新的请求最终整个调用链上的服务全部瘫痪。这可不是危言耸听而是每个微服务开发者都可能踩到的“大坑”。这时候Sentinel就登场了。它不是一把物理的锁而是一个面向分布式服务架构的流量控制、熔断降级和系统自适应保护组件。简单来说它的核心工作就是“守门”在流量过大时进行限流防止系统被冲垮在依赖服务不稳定时进行熔断快速失败避免资源耗尽同时还能实时监控系统的各项指标实现自适应保护。我最初接触Sentinel是在一个电商项目中当时我们用的Hystrix已经停止维护团队正在寻找替代方案。Sentinel以其丰富的流量控制手段、实时的监控台和与Spring Cloud Alibaba生态的无缝集成最终成为了我们的选择。对于任何正在或计划使用Spring Cloud Alibaba构建微服务的团队来说理解并运用Sentinel是保障系统高可用的必修课。2. Sentinel核心概念与架构拆解要玩转Sentinel不能只停留在“怎么配”的层面必须理解其设计思想。它把“资源”和“规则”作为两个最核心的抽象整个控制流程都围绕它们展开。2.1 核心概念资源、规则与上下文资源Resource是Sentinel保护的核心对象。它可以是任何东西一个URL入口、一个服务方法、甚至一段代码块。在Sentinel眼里只要是需要被保护、被监控的都可以定义为一个资源。例如你的一个Controller的/order/create接口或者一个Service层的createOrder()方法。规则Rule是施加在资源上的控制策略。这是Sentinel强大功能的具体体现主要包括流量控制规则FlowRule控制每秒允许通过的请求数QPS或并发线程数。熔断降级规则DegradeRule当资源的响应时间过长或异常比例过高时自动熔断暂时切断对该资源的访问。系统保护规则SystemRule从整个系统的维度如Load、CPU使用率、总体平均RT等进行保护防止系统被拖垮。热点参数规则ParamFlowRule对资源调用中的热点参数如某个特定用户ID、商品ID进行精细化的限流。授权规则AuthorityRule根据调用来源origin进行黑白名单控制。上下文Context代表一次调用链的入口。Sentinel通过ContextUtil.enter(contextName, origin)来创建一个上下文同一个上下文下的资源调用会共享一些数据比如调用链、默认的流量控制规则等。通常一个Web请求的入口如Servlet Filter会自动创建一个上下文。2.2 工作流程与Slot责任链Sentinel内部采用责任链模式ProcessorSlotChain来处理每个资源的请求这个链条由一系列功能各异的“槽位Slot”组成。理解这个链条你就明白了Sentinel是如何工作的NodeSelectorSlot负责收集资源的调用路径并以树状结构存储用于实时统计和展示调用关系。ClusterBuilderSlot用于存储资源的集群节点数据如果启用集群限流功能会用到。LogSlot记录异常日志当规则被触发如被限流、熔断时会在此记录。StatisticSlot最关键的槽位之一。负责记录、统计资源的实时调用数据包括QPS、RT、线程数、异常数等。后续规则判断都依赖于它提供的数据。AuthoritySlot执行授权规则黑白名单检查。SystemSlot执行系统保护规则检查。FlowSlot执行流量控制规则检查。根据StatisticSlot统计的数据判断当前请求是否应该被限流。DegradeSlot执行熔断降级规则检查。判断当前资源是否应被熔断。当一个请求进入Sentinel的管辖范围它会像过安检一样依次通过这些“关卡”。任何一个Slot检查不通过比如FlowSlot判断需要限流请求就会立即被拒绝并抛出BlockException异常流程终止。实操心得很多同学配置了规则但感觉不生效第一步就应该检查你的资源定义是否正确以及请求是否真的经过了这条Slot责任链。在Spring Cloud Alibaba中通常通过注解或Gateway过滤器集成会自动完成资源定义和链路的构建。3. 在Spring Boot项目中快速集成Sentinel理论说再多不如动手跑一遍。我们从一个最干净的Spring Boot项目开始演示如何集成Sentinel核心库及其控制台。3.1 项目依赖与基础配置首先创建一个Spring Boot项目2.3.x以上版本较佳在pom.xml中引入必要依赖。这里我们分两步走先引入核心依赖再引入控制台Dashboard依赖。核心依赖这是让你的应用具备Sentinel能力的基础。dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-sentinel/artifactId version2022.0.0.0/version !-- 请根据你的Spring Cloud Alibaba版本选择 -- /dependency控制台依赖可选用于本地测试Sentinel控制台是一个独立的Java应用我们需要下载JAR包运行。但为了在代码中方便地指定控制台地址可以引入这个依赖。dependency groupIdcom.alibaba.csp/groupId artifactIdsentinel-transport-simple-http/artifactId version1.8.6/version !-- 版本需与starter保持一致 -- /dependency在application.yml中进行最基础的配置spring: application: name: sentinel-demo-app cloud: sentinel: transport: # 指定Sentinel控制台的地址和端口 dashboard: localhost:8080 # 本应用与Dashboard通信的端口随意指定一个未占用的即可 port: 8719 # 取消Sentinel对Spring MVC Context的懒加载确保一启动就初始化 eager: true这里dashboard: localhost:8080假设你将在本地8080端口启动控制台。port: 8719是你的应用向控制台发送心跳和监控数据的端口。3.2 启动并访问Sentinel控制台Sentinel控制台是一个标准的Spring Boot应用。你需要从Alibaba的GitHub Release页面下载对应版本的JAR包例如sentinel-dashboard-1.8.6.jar。通过命令行启动java -Dserver.port8080 -Dcsp.sentinel.dashboard.serverlocalhost:8080 -Dproject.namesentinel-dashboard -jar sentinel-dashboard-1.8.6.jar启动参数-Dserver.port8080指定了控制台自身的访问端口。启动成功后访问http://localhost:8080。默认用户名和密码都是sentinel。此时由于你的应用sentinel-demo-app已经启动并向控制台发送了心跳你会在控制台的“机器列表”中看到你的应用。但“链路”和“簇点链路”页面可能是空的这是因为我们还没有定义任何资源即没有被监控的接口。3.3 定义第一个受保护的资源并验证我们创建一个简单的REST接口作为资源。Sentinel提供了多种定义资源的方式最常用的是SentinelResource注解。创建一个TestControllerRestController public class TestController { GetMapping(/hello) SentinelResource(value resourceHello, blockHandler handleBlock) public String hello() { // 模拟业务处理 return Hello, Sentinel!; } // BlockException处理函数参数和返回值需与原方法一致最后多一个BlockException参数 public String handleBlock(BlockException ex) { return Oops, 被流控或降级了: ex.getClass().getSimpleName(); } }SentinelResource(value resourceHello)这行注解是关键。它将/hello这个接口方法定义为一个名为resourceHello的Sentinel资源。blockHandler handleBlock指定了当该资源被流量控制或熔断降级即抛出BlockException时的处理函数。这个函数必须和原方法在同一个类中拥有相同的返回类型并且最后一个参数是BlockException。启动你的Spring Boot应用并访问几次http://localhost:8081/hello假设你的应用跑在8081端口。然后刷新Sentinel控制台在“簇点链路”页面你应该能看到名为resourceHello的资源出现了。注意事项SentinelResource注解默认是不处理Web容器层面如Spring MVC的异常的它只处理Sentinel内部规则触发的BlockException。如果你的接口因为其他原因如代码bug抛出NullPointerException是不会触发blockHandler的。对于这种业务异常需要使用fallback属性来指定处理函数。4. 流量控制规则详解与实战流量控制Flow Control是Sentinel最基础也是使用最频繁的功能目的是避免瞬时流量冲垮服务。4.1 流量控制规则参数解析在控制台找到resourceHello资源点击“流控”按钮你会看到如下配置项资源名要保护的资源这里自动填充为resourceHello。针对来源默认为default表示对所有调用者生效。可以指定为某个特定的调用方通过ContextUtil.enter()时设置的origin。阈值类型QPS每秒请求数。这是最常用的模式。并发线程数同时处理该资源的线程数上限。适用于处理耗时较长、容易耗尽线程池资源的场景。单机阈值就是上面阈值类型的数值。例如设为5QPS模式下表示每秒最多允许5次请求通过。流控模式直接达到阈值后直接限制当前资源。关联当关联的资源达到阈值时就限制当前资源。适用于“读操作”和“写操作”有争抢资源的场景你可以为“写操作”设置一个低阈值当“写操作”繁忙时就限制“读操作”。链路只针对从某个入口资源上下文来的流量进行限流。更细粒度。流控效果快速失败默认方式直接抛出FlowException。Warm Up冷启动/预热模式。系统在启动初期允许的QPS从一个较低的值缓慢增长到设定的阈值。适用于防止冷系统突然被大流量打满。排队等待让请求匀速通过以固定的间隔时间允许请求通过。适用于处理突发流量但要求系统在接下来的时间以均匀速度处理。4.2 实战配置并测试QPS限流我们为resourceHello配置一个简单的QPS限流规则阈值类型选QPS单机阈值设为2流控模式选直接流控效果选快速失败。配置完成后使用工具如Postman、curl或浏览器快速刷新在1秒内连续访问/hello接口3次以上。前两次会返回“Hello, Sentinel!”从第三次开始你应该会看到返回“Oops 被流控或降级了: FlowException”。这说明限流规则生效了。同时在Sentinel控制台的“实时监控”页面你可以看到resourceHello资源的通过QPS、拒绝QPS等图表非常直观。4.3 高级场景Warm Up与排队等待Warm Up场景假设你的服务冷启动后数据库连接池、缓存等都是空的如果瞬间承受设定好的最高QPS比如1000可能会导致大量请求超时或失败。Warm Up模式允许你在设定的预热时长如10秒内让阈值从阈值 / coldFactor默认coldFactor3慢慢上升到设定的阈值。例如阈值设为300预热10秒那么系统启动后的最初10秒实际允许的QPS会从100逐渐线性增加到300。排队等待场景适用于消息队列处理、秒杀等场景。你希望突发的大量请求不是直接被拒绝而是排队以固定的速度例如每100毫秒处理一个通过。你需要设置一个“超时时间”请求排队超过这个时间还未被处理则会被拒绝。这种模式能很好地平滑流量但会增加请求的平均响应时间。踩坑记录曾经在配置“关联”流控模式时因为没理解清楚“关联资源”和“当前资源”的关系导致配置反了该限流的时候没限不该限的时候却被限了。一定要记住“当关联资源B的流量达到阈值时就限制当前资源A”。画个简单的调用图能帮助理解。5. 熔断降级规则从“快速失败”到“自我恢复”熔断降级解决的是另一个问题依赖的服务不稳定响应慢或频繁出错时如何保护自己不被拖垮。其灵感来源于电路保险丝。5.1 熔断策略与状态机Sentinel提供三种熔断策略慢调用比例 (SLOW_REQUEST_RATIO)当资源的响应时间RT超过设定的最大RT以毫秒计且这些慢调用的比例超过设定的阈值时触发熔断。异常比例 (ERROR_RATIO)当资源的异常调用比例超过阈值时触发熔断。异常数 (ERROR_COUNT)当资源在统计时长内的异常数量超过阈值时触发熔断。熔断器有三个状态关闭Closed正常状态请求畅通无阻。打开Open触发熔断所有请求快速失败直接调用blockHandler逻辑。半开Half-Open熔断开启一段时间熔断时长后会进入半开状态尝试放行一个请求。如果该请求成功则认为故障恢复熔断器关闭如果失败则继续保持打开状态。5.2 实战模拟慢调用触发熔断我们修改/hello接口让它随机睡眠一段时间来模拟慢调用GetMapping(/hello) SentinelResource(value resourceHello, blockHandler handleBlock) public String hello() throws InterruptedException { // 随机睡眠0-1000毫秒模拟处理耗时 Thread.sleep(new Random().nextInt(1000)); return Hello, Sentinel! RT: System.currentTimeMillis(); }然后在控制台为resourceHello配置熔断降级规则熔断策略慢调用比例最大RT200毫秒。响应时间超过200ms的请求算作“慢调用”。比例阈值0.550%。当慢调用比例超过50%时触发熔断。熔断时长5秒。熔断触发后持续5秒的打开状态。最小请求数5。统计窗口内至少要有5个请求才开始计算比例。统计时长10000毫秒。基于最近10秒的请求进行统计。配置完成后用脚本或工具快速连续访问接口10次。由于我们的接口RT在0-1000ms随机很大概率会超过200ms。当在统计窗口内慢调用比例超过50%时熔断触发。此时再访问接口会立即返回blockHandler的信息例如“DegradeException”。等待大约5秒熔断时长后Sentinel会进入半开状态放行一个探测请求。如果这个探测请求的RT小于200ms熔断器关闭服务恢复否则熔断器再次打开。5.3 熔断与降级的区别这是一个容易混淆的概念。在Sentinel的语境下熔断Circuit Breaking是一种自动的、系统层面的故障保护机制。由框架自动根据预设规则慢调用比例、异常比例等触发切断对不稳定资源的调用。降级Fallback更偏向于一种手动的、业务层面的容错策略。当服务不可用时提供一种备选方案。在SentinelResource注解中fallback属性指定的函数就是用来处理业务异常非BlockException的降级逻辑。通常熔断是触发降级的一种条件。当熔断发生时请求走blockHandler当发生其他业务异常时请求走fallback。你可以同时配置两者。6. 规则管理推拉模式与生产环境实践在本地测试时我们在控制台配置规则控制台会通过HTTP API将规则推送到客户端应用。但这只适用于演示和开发。在生产环境中你需要更可靠的规则管理方式。6.1 原始模式与控制台推送模式原始模式在应用启动时通过Java代码硬编码规则FlowRuleManager.loadRules(List)。规则保存在内存中应用重启则丢失。绝不适用于生产。控制台推送模式就是我们刚才用的。控制台将规则推送到客户端客户端也将其保存在内存中。同样存在重启丢失的问题且控制台本身是无状态的不支持集群。6.2 生产级方案规则持久化到配置中心生产环境需要将规则持久化到外部存储如文件、数据库、配置中心并在应用启动时拉取规则或监听规则变更。Sentinel提供了DataSource扩展接口。与Nacos集成是最常见的方案。你需要额外引入依赖dependency groupIdcom.alibaba.csp/groupId artifactIdsentinel-datasource-nacos/artifactId version1.8.6/version /dependency然后在application.yml中配置数据源spring: cloud: sentinel: datasource: ds-nacos: # 数据源名称可自定义 nacos: server-addr: ${NACOS_HOST:localhost}:8848 dataId: ${spring.application.name}-sentinel-flow groupId: DEFAULT_GROUP >dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-alibaba-sentinel-gateway/artifactId version2022.0.0.0/version /dependencySentinel会自动为Gateway的路由和自定义的分组API提供资源保护。你可以在Sentinel控制台上看到以[网关API前缀]命名的资源并为其配置特殊的API分组流控规则或路由ID流控规则。网关流控的规则维度更丰富可以针对请求路径、请求头、请求参数等进行匹配。7.2 热点参数限流实战热点参数限流ParamFlowRule是一个非常实用的高级特性。想象一个秒杀场景对商品A的访问QPS可能极高而商品B则无人问津。如果对整个查询接口限流对商品B不公平。热点参数限流可以对接口的某个参数如商品ID进行精细化限流。假设我们有一个根据商品ID查询详情的接口GetMapping(/product/{id}) SentinelResource(value getProductById, blockHandler paramFlowBlockHandler) public String getProduct(PathVariable(id) Long id) { return Product info for ID: id; } public String paramFlowBlockHandler(Long id, BlockException ex) { return 热点商品限流中ID: id; }在Sentinel控制台选择“热点规则”为资源getProductById添加规则参数索引0代表方法的第一个参数即id。单机阈值比如2。参数类型选择long。这样配置后每个不同的商品ID都将独立计数。商品ID为1001的请求每秒最多通过2次商品ID为1002的请求也独立拥有每秒2次的额度。你还可以为特定的参数值如爆款商品ID1001设置独立的、更低的阈值。8. 常见问题排查与性能调优在实际使用中你肯定会遇到各种“坑”。这里记录几个典型问题和排查思路。问题1规则配置了但为什么不生效检查点1资源名是否正确。确保SentinelResource的value与控制台配置的资源名完全一致注意大小写。检查点2请求是否经过Sentinel的Filter/Interceptor。对于Web应用确保spring-cloud-starter-alibaba-sentinel依赖已引入Sentinel的自动配置会生效。你可以检查日志看是否有Sentinel相关的初始化信息。检查点3规则是否已加载。在应用启动后可以通过FlowRuleManager.getRules()等方法在代码中打印当前内存中的规则看是否包含你配置的规则。检查点4控制台配置是否成功推送。查看应用日志当在控制台点击“新增流控规则”后应用端会收到日志提示“Receiving new flow rules...”。问题2控制台看不到我的应用或监控数据检查点1网络连通性。确保你的应用所在机器能访问控制台地址spring.cloud.sentinel.transport.dashboard。检查点2端口冲突。确保spring.cloud.sentinel.transport.port指定的端口默认8719未被占用。检查点3心跳间隔。客户端默认每10秒发送一次心跳到控制台。刚启动的应用可能需要等待几十秒才会出现在“机器列表”中。检查点4控制台版本兼容性。尽量保证客户端sentinel-core版本与控制台sentinel-dashboard版本一致。问题3Sentinel对性能影响大吗Sentinel的核心统计和规则检查逻辑非常高效其性能开销主要来自于资源埋点每次进入被SentinelResource注解的方法都会进行一些上下文和节点链的构建。对于QPS极高的接口如超过10万QPS这可能成为瓶颈。解决方案是避免过度保护只为关键入口和依赖服务配置规则。日志记录被限流或熔断的请求会记录日志。确保日志框架配置合理避免同步日志阻塞。与Dashboard通信心跳和监控数据上报是异步的且可以调整间隔。在生产环境如果不需要实时监控可以适当调低监控数据上报的频率。性能调优建议根据实际压测结果来设置阈值不要盲目设置过小的QPS。对于内部循环调用或极其高频的私有方法谨慎使用Sentinel注解。生产环境建议将规则持久化到Nacos等配置中心并关闭控制台的规则推送功能spring.cloud.sentinel.transport.dashboard可以不配以减少一个潜在的故障点。问题4blockHandler方法不执行这是最常见的问题之一。请严格遵守以下条件blockHandler方法必须是public的。返回类型必须与原方法完全一致。参数列表必须与原方法一致并且在最后额外添加一个BlockException类型的参数。默认情况下该方法必须与原始方法在同一个类中。如果希望使用其他类的函数可以指定blockHandlerClass但对应的函数必须是static的。集成Sentinel是一个从“能用”到“用好”的过程。初期可以先从核心接口的流量控制开始逐步加入熔断降级。在灰度发布或大促前通过压测确定合理的阈值。最重要的是将它视为一套保障系统稳定的“安全带”和“仪表盘”而不是开发完毕后才想起的补丁。它的实时监控数据对于分析系统瓶颈、定位慢调用链有不可替代的价值。 Sentinel微服务流量控制与熔断降级实战指南
1. 项目概述为什么我们需要Sentinel在微服务架构里服务之间的调用关系变得像一张复杂的蜘蛛网。一个订单服务可能要调用用户服务、库存服务、支付服务而支付服务又可能依赖外部的银行网关。当“双十一”零点流量洪峰涌来或者某个下游服务因为数据库慢查询突然“卡壳”问题就会像多米诺骨牌一样传导开来。最典型的场景就是“服务雪崩”A服务调用B服务B服务因为自身原因响应变慢导致A服务的线程池被大量等待B响应的线程占满进而A服务也无法处理新的请求最终整个调用链上的服务全部瘫痪。这可不是危言耸听而是每个微服务开发者都可能踩到的“大坑”。这时候Sentinel就登场了。它不是一把物理的锁而是一个面向分布式服务架构的流量控制、熔断降级和系统自适应保护组件。简单来说它的核心工作就是“守门”在流量过大时进行限流防止系统被冲垮在依赖服务不稳定时进行熔断快速失败避免资源耗尽同时还能实时监控系统的各项指标实现自适应保护。我最初接触Sentinel是在一个电商项目中当时我们用的Hystrix已经停止维护团队正在寻找替代方案。Sentinel以其丰富的流量控制手段、实时的监控台和与Spring Cloud Alibaba生态的无缝集成最终成为了我们的选择。对于任何正在或计划使用Spring Cloud Alibaba构建微服务的团队来说理解并运用Sentinel是保障系统高可用的必修课。2. Sentinel核心概念与架构拆解要玩转Sentinel不能只停留在“怎么配”的层面必须理解其设计思想。它把“资源”和“规则”作为两个最核心的抽象整个控制流程都围绕它们展开。2.1 核心概念资源、规则与上下文资源Resource是Sentinel保护的核心对象。它可以是任何东西一个URL入口、一个服务方法、甚至一段代码块。在Sentinel眼里只要是需要被保护、被监控的都可以定义为一个资源。例如你的一个Controller的/order/create接口或者一个Service层的createOrder()方法。规则Rule是施加在资源上的控制策略。这是Sentinel强大功能的具体体现主要包括流量控制规则FlowRule控制每秒允许通过的请求数QPS或并发线程数。熔断降级规则DegradeRule当资源的响应时间过长或异常比例过高时自动熔断暂时切断对该资源的访问。系统保护规则SystemRule从整个系统的维度如Load、CPU使用率、总体平均RT等进行保护防止系统被拖垮。热点参数规则ParamFlowRule对资源调用中的热点参数如某个特定用户ID、商品ID进行精细化的限流。授权规则AuthorityRule根据调用来源origin进行黑白名单控制。上下文Context代表一次调用链的入口。Sentinel通过ContextUtil.enter(contextName, origin)来创建一个上下文同一个上下文下的资源调用会共享一些数据比如调用链、默认的流量控制规则等。通常一个Web请求的入口如Servlet Filter会自动创建一个上下文。2.2 工作流程与Slot责任链Sentinel内部采用责任链模式ProcessorSlotChain来处理每个资源的请求这个链条由一系列功能各异的“槽位Slot”组成。理解这个链条你就明白了Sentinel是如何工作的NodeSelectorSlot负责收集资源的调用路径并以树状结构存储用于实时统计和展示调用关系。ClusterBuilderSlot用于存储资源的集群节点数据如果启用集群限流功能会用到。LogSlot记录异常日志当规则被触发如被限流、熔断时会在此记录。StatisticSlot最关键的槽位之一。负责记录、统计资源的实时调用数据包括QPS、RT、线程数、异常数等。后续规则判断都依赖于它提供的数据。AuthoritySlot执行授权规则黑白名单检查。SystemSlot执行系统保护规则检查。FlowSlot执行流量控制规则检查。根据StatisticSlot统计的数据判断当前请求是否应该被限流。DegradeSlot执行熔断降级规则检查。判断当前资源是否应被熔断。当一个请求进入Sentinel的管辖范围它会像过安检一样依次通过这些“关卡”。任何一个Slot检查不通过比如FlowSlot判断需要限流请求就会立即被拒绝并抛出BlockException异常流程终止。实操心得很多同学配置了规则但感觉不生效第一步就应该检查你的资源定义是否正确以及请求是否真的经过了这条Slot责任链。在Spring Cloud Alibaba中通常通过注解或Gateway过滤器集成会自动完成资源定义和链路的构建。3. 在Spring Boot项目中快速集成Sentinel理论说再多不如动手跑一遍。我们从一个最干净的Spring Boot项目开始演示如何集成Sentinel核心库及其控制台。3.1 项目依赖与基础配置首先创建一个Spring Boot项目2.3.x以上版本较佳在pom.xml中引入必要依赖。这里我们分两步走先引入核心依赖再引入控制台Dashboard依赖。核心依赖这是让你的应用具备Sentinel能力的基础。dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-sentinel/artifactId version2022.0.0.0/version !-- 请根据你的Spring Cloud Alibaba版本选择 -- /dependency控制台依赖可选用于本地测试Sentinel控制台是一个独立的Java应用我们需要下载JAR包运行。但为了在代码中方便地指定控制台地址可以引入这个依赖。dependency groupIdcom.alibaba.csp/groupId artifactIdsentinel-transport-simple-http/artifactId version1.8.6/version !-- 版本需与starter保持一致 -- /dependency在application.yml中进行最基础的配置spring: application: name: sentinel-demo-app cloud: sentinel: transport: # 指定Sentinel控制台的地址和端口 dashboard: localhost:8080 # 本应用与Dashboard通信的端口随意指定一个未占用的即可 port: 8719 # 取消Sentinel对Spring MVC Context的懒加载确保一启动就初始化 eager: true这里dashboard: localhost:8080假设你将在本地8080端口启动控制台。port: 8719是你的应用向控制台发送心跳和监控数据的端口。3.2 启动并访问Sentinel控制台Sentinel控制台是一个标准的Spring Boot应用。你需要从Alibaba的GitHub Release页面下载对应版本的JAR包例如sentinel-dashboard-1.8.6.jar。通过命令行启动java -Dserver.port8080 -Dcsp.sentinel.dashboard.serverlocalhost:8080 -Dproject.namesentinel-dashboard -jar sentinel-dashboard-1.8.6.jar启动参数-Dserver.port8080指定了控制台自身的访问端口。启动成功后访问http://localhost:8080。默认用户名和密码都是sentinel。此时由于你的应用sentinel-demo-app已经启动并向控制台发送了心跳你会在控制台的“机器列表”中看到你的应用。但“链路”和“簇点链路”页面可能是空的这是因为我们还没有定义任何资源即没有被监控的接口。3.3 定义第一个受保护的资源并验证我们创建一个简单的REST接口作为资源。Sentinel提供了多种定义资源的方式最常用的是SentinelResource注解。创建一个TestControllerRestController public class TestController { GetMapping(/hello) SentinelResource(value resourceHello, blockHandler handleBlock) public String hello() { // 模拟业务处理 return Hello, Sentinel!; } // BlockException处理函数参数和返回值需与原方法一致最后多一个BlockException参数 public String handleBlock(BlockException ex) { return Oops, 被流控或降级了: ex.getClass().getSimpleName(); } }SentinelResource(value resourceHello)这行注解是关键。它将/hello这个接口方法定义为一个名为resourceHello的Sentinel资源。blockHandler handleBlock指定了当该资源被流量控制或熔断降级即抛出BlockException时的处理函数。这个函数必须和原方法在同一个类中拥有相同的返回类型并且最后一个参数是BlockException。启动你的Spring Boot应用并访问几次http://localhost:8081/hello假设你的应用跑在8081端口。然后刷新Sentinel控制台在“簇点链路”页面你应该能看到名为resourceHello的资源出现了。注意事项SentinelResource注解默认是不处理Web容器层面如Spring MVC的异常的它只处理Sentinel内部规则触发的BlockException。如果你的接口因为其他原因如代码bug抛出NullPointerException是不会触发blockHandler的。对于这种业务异常需要使用fallback属性来指定处理函数。4. 流量控制规则详解与实战流量控制Flow Control是Sentinel最基础也是使用最频繁的功能目的是避免瞬时流量冲垮服务。4.1 流量控制规则参数解析在控制台找到resourceHello资源点击“流控”按钮你会看到如下配置项资源名要保护的资源这里自动填充为resourceHello。针对来源默认为default表示对所有调用者生效。可以指定为某个特定的调用方通过ContextUtil.enter()时设置的origin。阈值类型QPS每秒请求数。这是最常用的模式。并发线程数同时处理该资源的线程数上限。适用于处理耗时较长、容易耗尽线程池资源的场景。单机阈值就是上面阈值类型的数值。例如设为5QPS模式下表示每秒最多允许5次请求通过。流控模式直接达到阈值后直接限制当前资源。关联当关联的资源达到阈值时就限制当前资源。适用于“读操作”和“写操作”有争抢资源的场景你可以为“写操作”设置一个低阈值当“写操作”繁忙时就限制“读操作”。链路只针对从某个入口资源上下文来的流量进行限流。更细粒度。流控效果快速失败默认方式直接抛出FlowException。Warm Up冷启动/预热模式。系统在启动初期允许的QPS从一个较低的值缓慢增长到设定的阈值。适用于防止冷系统突然被大流量打满。排队等待让请求匀速通过以固定的间隔时间允许请求通过。适用于处理突发流量但要求系统在接下来的时间以均匀速度处理。4.2 实战配置并测试QPS限流我们为resourceHello配置一个简单的QPS限流规则阈值类型选QPS单机阈值设为2流控模式选直接流控效果选快速失败。配置完成后使用工具如Postman、curl或浏览器快速刷新在1秒内连续访问/hello接口3次以上。前两次会返回“Hello, Sentinel!”从第三次开始你应该会看到返回“Oops 被流控或降级了: FlowException”。这说明限流规则生效了。同时在Sentinel控制台的“实时监控”页面你可以看到resourceHello资源的通过QPS、拒绝QPS等图表非常直观。4.3 高级场景Warm Up与排队等待Warm Up场景假设你的服务冷启动后数据库连接池、缓存等都是空的如果瞬间承受设定好的最高QPS比如1000可能会导致大量请求超时或失败。Warm Up模式允许你在设定的预热时长如10秒内让阈值从阈值 / coldFactor默认coldFactor3慢慢上升到设定的阈值。例如阈值设为300预热10秒那么系统启动后的最初10秒实际允许的QPS会从100逐渐线性增加到300。排队等待场景适用于消息队列处理、秒杀等场景。你希望突发的大量请求不是直接被拒绝而是排队以固定的速度例如每100毫秒处理一个通过。你需要设置一个“超时时间”请求排队超过这个时间还未被处理则会被拒绝。这种模式能很好地平滑流量但会增加请求的平均响应时间。踩坑记录曾经在配置“关联”流控模式时因为没理解清楚“关联资源”和“当前资源”的关系导致配置反了该限流的时候没限不该限的时候却被限了。一定要记住“当关联资源B的流量达到阈值时就限制当前资源A”。画个简单的调用图能帮助理解。5. 熔断降级规则从“快速失败”到“自我恢复”熔断降级解决的是另一个问题依赖的服务不稳定响应慢或频繁出错时如何保护自己不被拖垮。其灵感来源于电路保险丝。5.1 熔断策略与状态机Sentinel提供三种熔断策略慢调用比例 (SLOW_REQUEST_RATIO)当资源的响应时间RT超过设定的最大RT以毫秒计且这些慢调用的比例超过设定的阈值时触发熔断。异常比例 (ERROR_RATIO)当资源的异常调用比例超过阈值时触发熔断。异常数 (ERROR_COUNT)当资源在统计时长内的异常数量超过阈值时触发熔断。熔断器有三个状态关闭Closed正常状态请求畅通无阻。打开Open触发熔断所有请求快速失败直接调用blockHandler逻辑。半开Half-Open熔断开启一段时间熔断时长后会进入半开状态尝试放行一个请求。如果该请求成功则认为故障恢复熔断器关闭如果失败则继续保持打开状态。5.2 实战模拟慢调用触发熔断我们修改/hello接口让它随机睡眠一段时间来模拟慢调用GetMapping(/hello) SentinelResource(value resourceHello, blockHandler handleBlock) public String hello() throws InterruptedException { // 随机睡眠0-1000毫秒模拟处理耗时 Thread.sleep(new Random().nextInt(1000)); return Hello, Sentinel! RT: System.currentTimeMillis(); }然后在控制台为resourceHello配置熔断降级规则熔断策略慢调用比例最大RT200毫秒。响应时间超过200ms的请求算作“慢调用”。比例阈值0.550%。当慢调用比例超过50%时触发熔断。熔断时长5秒。熔断触发后持续5秒的打开状态。最小请求数5。统计窗口内至少要有5个请求才开始计算比例。统计时长10000毫秒。基于最近10秒的请求进行统计。配置完成后用脚本或工具快速连续访问接口10次。由于我们的接口RT在0-1000ms随机很大概率会超过200ms。当在统计窗口内慢调用比例超过50%时熔断触发。此时再访问接口会立即返回blockHandler的信息例如“DegradeException”。等待大约5秒熔断时长后Sentinel会进入半开状态放行一个探测请求。如果这个探测请求的RT小于200ms熔断器关闭服务恢复否则熔断器再次打开。5.3 熔断与降级的区别这是一个容易混淆的概念。在Sentinel的语境下熔断Circuit Breaking是一种自动的、系统层面的故障保护机制。由框架自动根据预设规则慢调用比例、异常比例等触发切断对不稳定资源的调用。降级Fallback更偏向于一种手动的、业务层面的容错策略。当服务不可用时提供一种备选方案。在SentinelResource注解中fallback属性指定的函数就是用来处理业务异常非BlockException的降级逻辑。通常熔断是触发降级的一种条件。当熔断发生时请求走blockHandler当发生其他业务异常时请求走fallback。你可以同时配置两者。6. 规则管理推拉模式与生产环境实践在本地测试时我们在控制台配置规则控制台会通过HTTP API将规则推送到客户端应用。但这只适用于演示和开发。在生产环境中你需要更可靠的规则管理方式。6.1 原始模式与控制台推送模式原始模式在应用启动时通过Java代码硬编码规则FlowRuleManager.loadRules(List)。规则保存在内存中应用重启则丢失。绝不适用于生产。控制台推送模式就是我们刚才用的。控制台将规则推送到客户端客户端也将其保存在内存中。同样存在重启丢失的问题且控制台本身是无状态的不支持集群。6.2 生产级方案规则持久化到配置中心生产环境需要将规则持久化到外部存储如文件、数据库、配置中心并在应用启动时拉取规则或监听规则变更。Sentinel提供了DataSource扩展接口。与Nacos集成是最常见的方案。你需要额外引入依赖dependency groupIdcom.alibaba.csp/groupId artifactIdsentinel-datasource-nacos/artifactId version1.8.6/version /dependency然后在application.yml中配置数据源spring: cloud: sentinel: datasource: ds-nacos: # 数据源名称可自定义 nacos: server-addr: ${NACOS_HOST:localhost}:8848 dataId: ${spring.application.name}-sentinel-flow groupId: DEFAULT_GROUP >dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-alibaba-sentinel-gateway/artifactId version2022.0.0.0/version /dependencySentinel会自动为Gateway的路由和自定义的分组API提供资源保护。你可以在Sentinel控制台上看到以[网关API前缀]命名的资源并为其配置特殊的API分组流控规则或路由ID流控规则。网关流控的规则维度更丰富可以针对请求路径、请求头、请求参数等进行匹配。7.2 热点参数限流实战热点参数限流ParamFlowRule是一个非常实用的高级特性。想象一个秒杀场景对商品A的访问QPS可能极高而商品B则无人问津。如果对整个查询接口限流对商品B不公平。热点参数限流可以对接口的某个参数如商品ID进行精细化限流。假设我们有一个根据商品ID查询详情的接口GetMapping(/product/{id}) SentinelResource(value getProductById, blockHandler paramFlowBlockHandler) public String getProduct(PathVariable(id) Long id) { return Product info for ID: id; } public String paramFlowBlockHandler(Long id, BlockException ex) { return 热点商品限流中ID: id; }在Sentinel控制台选择“热点规则”为资源getProductById添加规则参数索引0代表方法的第一个参数即id。单机阈值比如2。参数类型选择long。这样配置后每个不同的商品ID都将独立计数。商品ID为1001的请求每秒最多通过2次商品ID为1002的请求也独立拥有每秒2次的额度。你还可以为特定的参数值如爆款商品ID1001设置独立的、更低的阈值。8. 常见问题排查与性能调优在实际使用中你肯定会遇到各种“坑”。这里记录几个典型问题和排查思路。问题1规则配置了但为什么不生效检查点1资源名是否正确。确保SentinelResource的value与控制台配置的资源名完全一致注意大小写。检查点2请求是否经过Sentinel的Filter/Interceptor。对于Web应用确保spring-cloud-starter-alibaba-sentinel依赖已引入Sentinel的自动配置会生效。你可以检查日志看是否有Sentinel相关的初始化信息。检查点3规则是否已加载。在应用启动后可以通过FlowRuleManager.getRules()等方法在代码中打印当前内存中的规则看是否包含你配置的规则。检查点4控制台配置是否成功推送。查看应用日志当在控制台点击“新增流控规则”后应用端会收到日志提示“Receiving new flow rules...”。问题2控制台看不到我的应用或监控数据检查点1网络连通性。确保你的应用所在机器能访问控制台地址spring.cloud.sentinel.transport.dashboard。检查点2端口冲突。确保spring.cloud.sentinel.transport.port指定的端口默认8719未被占用。检查点3心跳间隔。客户端默认每10秒发送一次心跳到控制台。刚启动的应用可能需要等待几十秒才会出现在“机器列表”中。检查点4控制台版本兼容性。尽量保证客户端sentinel-core版本与控制台sentinel-dashboard版本一致。问题3Sentinel对性能影响大吗Sentinel的核心统计和规则检查逻辑非常高效其性能开销主要来自于资源埋点每次进入被SentinelResource注解的方法都会进行一些上下文和节点链的构建。对于QPS极高的接口如超过10万QPS这可能成为瓶颈。解决方案是避免过度保护只为关键入口和依赖服务配置规则。日志记录被限流或熔断的请求会记录日志。确保日志框架配置合理避免同步日志阻塞。与Dashboard通信心跳和监控数据上报是异步的且可以调整间隔。在生产环境如果不需要实时监控可以适当调低监控数据上报的频率。性能调优建议根据实际压测结果来设置阈值不要盲目设置过小的QPS。对于内部循环调用或极其高频的私有方法谨慎使用Sentinel注解。生产环境建议将规则持久化到Nacos等配置中心并关闭控制台的规则推送功能spring.cloud.sentinel.transport.dashboard可以不配以减少一个潜在的故障点。问题4blockHandler方法不执行这是最常见的问题之一。请严格遵守以下条件blockHandler方法必须是public的。返回类型必须与原方法完全一致。参数列表必须与原方法一致并且在最后额外添加一个BlockException类型的参数。默认情况下该方法必须与原始方法在同一个类中。如果希望使用其他类的函数可以指定blockHandlerClass但对应的函数必须是static的。集成Sentinel是一个从“能用”到“用好”的过程。初期可以先从核心接口的流量控制开始逐步加入熔断降级。在灰度发布或大促前通过压测确定合理的阈值。最重要的是将它视为一套保障系统稳定的“安全带”和“仪表盘”而不是开发完毕后才想起的补丁。它的实时监控数据对于分析系统瓶颈、定位慢调用链有不可替代的价值。