企业官网建设流程全解析

1. 熔断到底在解决什么问题：先还原一次真实线上故障

前些年我维护过一个交易中台，平时流量平稳，一到整点活动流量就会冲上来。某个周五晚上大促预热，订单服务的依赖方——库存中心——因为数据库连接池被慢查询打满，响应时间从 20ms 一路飙到 3s 以上。我们这边调用库存接口的线程纷纷卡在等待响应上，Tomcat 线程池很快耗尽，紧接着订单服务自身也开始超时，最终整条链路雪崩。等我们发现的时候，库存中心已经恢复了，但我们的服务还在不停地重试那些注定失败的调用，把刚刚喘过气来的库存服务又压了回去。那一晚我们学会了三件事：重试不是越多越好，超时不是越短越好，没有熔断的服务等于裸奔。

当时我们把 Sentinel 接入进来，核心目的只有一个：当某一个依赖出现故障趋势时，快速切断对该依赖的调用，让服务自身先活下来，而不是陪着下游一起死。熔断降级不是一个锦上添花的优化，它是分布式系统里保护自身可用性的最后一道闸门。

1.1 一次性谈清楚：熔断、降级、限流三者有什么区别

很多人刚接触 Sentinel 时会把限流和熔断混在一起。这里我给出一个我常用的说法：

• 限流：站在自己这边，控制进入自己服务的请求量，防止自己被流量打死。它不关心下游是否健康，只关心“我这扇门一秒能进多少人”。
• 熔断：站在调用方这边，发现下游已经不行了，直接断开调用，避免自己也被拖垮。它关注的是“依赖方能不能在可接受时间内返回”。
• 降级：熔断之后的兜底动作，或者说是一种备选方案。比如熔断打开时，不再去调用库存服务，而是直接返回一个本地缓存的库存数据，或者返回一个默认值，把失败吞掉，保证主流程能继续跑。

用一个生活化的类比：限流是商场入口的保安，限定一分钟只能进 50 个人，人太多了就拦住；熔断是商场某一层电梯坏了之后，物业直接贴上“电梯停运”标牌，不再让客人进电梯；降级是电梯坏了之后，引导客人走楼梯，虽然慢一点，但客人还能上楼。三者往往配合使用：先限流保护自己，再熔断保护自己不被下游拖死，最后降级给用户一个可接受的响应。

在这三种机制里，熔断是“开关类”的机制，状态变化非常剧烈，也就衍生出一个问题：开关打开之后，什么时候才能关闭？这就是本文要说的重点——熔断的时间窗口和半开状态。

1.2 熔断状态机的三个基本状态：关闭、打开、半开

Sentinel 的熔断器内部是一个状态机，有三个状态：

• 关闭状态（CLOSED）：默认状态。请求正常通过，框架会统计调用成功、失败、慢调用的次数和比例。当异常比例或异常数超过阈值时，熔断器进入打开状态。
• 打开状态（OPEN）：熔断器跳闸，所有请求直接拒绝，通常返回一个被降级的默认值。打开状态会持续一个固定的时间，这个时间就是“熔断时间窗口”，由timeout参数或者maxAllowedRtMs相关的配置决定。
• 半开状态（HALF_OPEN）：熔断时间窗口结束后，熔断器不会直接恢复到关闭状态，而是先进入半开状态。半开状态下会放行少量探测请求，看一看下游是否恢复正常。如果探测请求成功，熔断器关闭；如果失败，熔断器重新打开，并且重新进入一个熔断时间窗口。

这个状态机的核心思想是：宁可错杀，不可硬扛；恢复需要验证，不能盲目信任。

2. 熔断时间窗口不是拍脑袋定的：参数设计与推算

Sentinel 的熔断策略主要有三种：慢调用比例、异常比例、异常数。不同策略下，时间窗口的语义略有差别，但底层状态机是一样的。我在实际配置中，最常用的是慢调用比例和异常比例两种，下面分开说。

2.1 三个最容易搞混的参数：statIntervalMs、timeout、minRequestAmount

首先明确一个点：Sentinel 的熔断器在工作时，本身也依赖一个滑动时间窗口来做统计，这个统计窗口由statIntervalMs控制，默认是 1000ms。熔断判断依据的是这个统计窗口内的数据，而不是从服务启动至今的累计数据。这个一定要和“熔断时间窗口”区分开，前者是统计数据用的窗口，后者是熔断器保持打开状态的时间。

三个参数的作用：

• statIntervalMs：统计窗口的长度，单位毫秒，默认 1000ms。每隔这么长的时间，Sentinel 会生成一个新的滑动窗口，淘汰掉旧的窗口数据。它决定了“最近一秒”的粒度。
• timeout（慢调用比例和异常比例用）或timeoutDuration：熔断器打开后，保持打开状态的时长，单位毫秒。这个就是通常意义上的“熔断时间窗口”。Sentinel 默认是 10000ms，即 10 秒。
• minRequestAmount：触发熔断判断的最小请求数。比如设置成 5，意思是统计窗口内至少得有 5 个请求，才去计算异常比例或慢调用比例，否则即便有 1 个请求失败，也不触发熔断。这是为了防止冷启动阶段请求量太少时发生误判。

还有一个参数叫maxAllowedRtMs，它是在慢调用比例策略下使用的，意思是“响应时间超过这个值的调用都被算作慢调用”。这个参数直接参与比例计算，也是一个很容易配错的点。

2.2 时间窗口的推算与常见配置误区

我们先来手动推算一组配置。假设：

• 慢调用阈值slowRatioThreshold：0.5
• 熔断时间窗口timeout：5000ms
• 统计窗口statIntervalMs：1000ms
• 最小请求数minRequestAmount：10
• 最大允许响应时间maxAllowedRtMs：500ms

在某个统计窗口内，有 20 个请求，其中 12 个响应时间超过了 500ms。此时慢调用比例 = 12 / 20 = 0.6，大于 0.5，且请求数大于 10，熔断器打开。接着，在接下来的 5 秒内，所有请求都会被拒绝。5 秒后，熔断器进入半开状态，尝试放行一个探测请求。这个探测请求如果成功，熔断器关闭；如果失败，熔断器重新打开，再保持 5 秒。

注意，这里有一个常见误区：很多人以为熔断时间窗口越短越好，比如设置成 1 秒，想着这样能快速恢复。但实际上，如果下游故障的本质原因没解决，比如数据库连接池没有恢复，你设置 1 秒窗口，半开探测请求大概率还是失败，然后熔断器再次打开，形成反复抖动的现象。这种短时间内频繁“打开—半开—打开”的状态，会让服务处于一种极不稳定的状态，请求一会儿被拒绝一会儿被放行，用户感受到的异常可能比持续熔断更严重。

还有一个误区是statIntervalMs设置得过短。有人为了追求实时性，把统计窗口设置为 100ms，结果在低流量场景下，窗口内连minRequestAmount都凑不够，熔断永远不会触发。统计窗口和最小请求数之间要做匹配：如果你设置minRequestAmount为 10，流量却只有每秒 2 个请求，那么统计窗口至少要能积累 5 秒的数据才能满足触发条件，而你却把窗口设置成了 1 秒，那熔断机制就形同虚设了。

3. 半开状态：允许放行试探的原理与细节

如果说熔断时间窗口是“防止雪崩的刹车”，那半开状态就是“确认可以起步的试探性油门”。我在 Sentinel 的源码里专门跟过一段半开状态的逻辑，这里挑重点说。

3.1 为什么必须存在半开状态

如果没有半开状态，熔断器到了时间就会直接从打开状态回到关闭状态。问题在于：下游服务是不是真的恢复了？如果没恢复，关闭状态下第一个请求就会再次失败，接着触发熔断，这时候等于给下游补了一刀。更糟糕的是，在熔断打开期间，我们对下游的健康状态毫无感知，时间一到就直接全量放量，一旦下游依然处于脆弱状态，瞬间涌入的请求又会把它打趴下。形成了“打死—恢复—再打死”的恶性循环。

半开状态解决的核心问题就是：在恢复阶段，先用最小成本验证下游健康状态，验证通过再逐步放量。这就像你看到一个病人刚退烧，不是一上来就让他跑马拉松，而是先让他走两步看看。Sentinel 的半开状态默认是放行一个请求做探测，这个叫“单飞探测”。

3.2 半开窗口内的放行策略与请求计数逻辑

这里有一个需要注意的地方：在半开状态下，Sentinel 是如何判断探测结果的？以慢调用比例为例，熔断器进入半开状态后，会记录被放行的探测请求。如果这个请求成功了，也就是响应时间没有超过maxAllowedRtMs，熔断器会将状态切换到关闭状态；如果失败了，熔断器重新切回打开状态，并且重置熔断时间窗口。

但如果你用的是较新版本的 Sentinel（1.8.0+），还引入了“比例探测”的概念。也就是说，在半开状态下，并不是只放行一个请求，而是按照配置的比例放行部分请求。比如设置为 0.1，意思是半开状态下，只有 10% 的请求会被放行到下游做探测，其余 90% 直接进入降级逻辑。这个设计更适合流量比较大的场景，单飞探测一个请求在低流量下没问题，但在高流量下，一个请求的探测结果不能代表整体的健康状态，比例探测能够用更平滑的方式试探。

比例探测的行为可以这样理解：

• 熔断器进入半开状态后，每次请求进来，先按照比例决定是否放行。
• 放行的请求会记录结果：成功计数 +1，失败计数 +1。
• 如果放行的请求失败，熔断器立刻重新打开。
• 如果放行的请求成功，并且成功次数达到一个设定的阈值（比如 5 次），熔断器才真正关闭。

这里的关键设计是：不是第一次成功就立刻关闭，而是积累一定数量的成功样本。这一点非常有价值，因为它避免了“碰巧成功”造成的误恢复。我在客户端源码里看到，这个成功阈值是可以配置的，默认是 5 次。很多人不知道这个细节，以为半开状态下放行一个请求成功就会马上关闭，其实不对，成功样本数不够会继续探测。

从原理解释一下半开状态为什么用“阈值”而不是“比例”来结束：如果按照比例决定什么时候关闭，那在低流量下可能很久都达不到关闭条件，服务会一直处于半开状态；而用固定阈值，只要探测试验攒够了成功样本，就能快速恢复。两者权衡之下，固定阈值在大多数场景更可靠。

4. 用 Nacos 动态下发熔断规则：限流配置样例与注意事项

很多人用 Sentinel 时，规则是通过代码初始化写死在应用里的。这种做法的缺点很明显：改一条规则要发一次版本，而且线上出现问题时，你没有机会慢慢改代码。所以我基本都会建议把规则放到 Nacos 里，用 Sentinel 的 Nacos 数据源动态加载。

4.1 一个可直接抄走的 Nacos 配置样例

这里以 Spring Cloud Alibaba 项目为例，演示如何把熔断规则放在 Nacos 中。

首先，引入依赖：

<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId> </dependency> <dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-datasource-nacos</artifactId> </dependency>

接着，在application.yml中配置数据源：

spring: cloud: sentinel: datasource: degrade: nacos: server-addr: ${NACOS_ADDR:127.0.0.1:8848} dataId: sentinel-degrade-rules groupId: DEFAULT_GROUP >[ { "resource": "inventoryService:getStock", "grade": 0, "count": 100.0, "timeout": 5000, "statIntervalMs": 1000, "minRequestAmount": 10, "slowRatioThreshold": 0.5, "maxAllowedRtMs": 500 }, { "resource": "inventoryService:getStock", "grade": 1, "count": 0.2, "timeout": 8000, "statIntervalMs": 1000, "minRequestAmount": 20 } ]

这段配置里，grade字段需要解释一下：0 表示慢调用比例熔断，1 表示异常比例熔断，2 表示异常数熔断。我上面同时配置了两条规则，一条慢调用比例，一条异常比例，有人说这样会冲突，其实不会。Sentinel 的熔断规则之间是“或”的关系，只要任意一条满足阈值，熔断器就会打开。这样做的意义在于：当服务出现请求量不大但错误率很高的故障时，异常比例规则能兜底；当请求量大但部分请求响应缓慢时，慢调用比例规则能兜底。

流控规则样例：

[ { "resource": "inventoryService:getStock", "grade": 1, "count": 500.0, "strategy": 0, "controlBehavior": 0 } ]

这里grade: 1表示 QPS 限流，count: 500表示每秒最多放行 500 个请求，controlBehavior: 0表示直接拒绝，controlBehavior: 1则表示使用冷启动预热的模式，让流量缓缓增加，避免刚启动就被打满。

4.2 规则动态生效机制与常见坑

数据源配置好后，Sentinel 会监听 Nacos 中对应 dataId 的配置变化，一旦配置变更，会在几秒内推送给客户端并刷新内存中的规则。这个机制在发布上是真的舒服：你不需要重启服务，改一下 Nacos 里的 JSON，熔断阈值立刻生效。

但这里有几个常见的坑：

• JSON 格式错误时，旧规则会被保留，新规则加载不进去。Nacos 数据源解析失败时，Sentinel 不会主动报错个没完，很容易让你误以为配置已经生效了。我的建议是每次改完规则，去 Sentinel 控制台的“熔断规则”页面看一眼，确认规则已经刷新为新版本。
• 多个数据源同时配置同类型规则时，会覆盖还是合并？Sentinel 的数据源加载规则时，默认是“整体替换”。也就是说，如果你有一个datasource配置了熔断规则，另一个datasource也配置了熔断规则，后加载的可能直接覆盖掉先加载的，而不是合并。这个坑我踩过，当时我在 Nacos 里配了一套规则，本地代码又加载了一套规则，结果发现线上运行的规则和我 Nacos 里的完全不一样。排查半天才发现是两套数据源互相覆盖。
• 规则刷新与滑动窗口统计不同步。当线上流量较大时，规则变化后，Sentinel 的滑动窗口还是以旧的统计周期继续计算，并不会因为规则变化而重置。所以会出现一种现象：刚改了熔断阈值，明明新阈值已经不满足了，熔断器却还是打开了一会儿。这不是 Bug，是因为统计窗口里还残留着新规则生效前的失败数据，需要一两个统计周期才能刷干净。

5. 容易误解的边界问题：统计时间窗口与熔断时间窗口的交叉

这一节我想聊一个很多资料里一笔带过、但实际排查时特别容易让人懵的话题——时间窗口交叉。先说一个来自数据库领域的类比，方便大家直观理解什么叫“时间窗口交叉”。

5.1 借助数据库索引回表来理解“窗口交叉”

MySQL 在通过二级索引更新数据时，会先锁二级索引项，再回表锁主键。在二级索引项锁定和回表主键锁定之间，存在一个极短的时间差。如果两个并发事务分别持有对方需要的锁，在这个时间差窗口内就可能产生交叉等待，进而形成死锁。这里的核心点是：两个时间窗口并非完全重叠，它们在某个临界点发生交叉，导致系统进入一种边界状态。

Sentinel 的时间窗口也有类似的味道。statIntervalMs负责统计，timeout负责熔断保持。两者并不在一条时间线上协同工作：统计窗口一直处于滚动状态，而熔断时间窗口是一个独立的“冷却期”。举个例子：

• 当前时刻 T0，熔断器打开，静止 5 秒。
• 在 T0 到 T0+5s 之间，统计窗口依然在滚动，依然在计算请求成功率、异常比例。
• 但此时所有请求都被降级拦截了，根本不会真正调用下游，所以统计窗口里看到的“异常”其实全部是降级产生的，而不是下游真实的状态。

等到 T0+5s，熔断器进入半开状态，放行少量请求时，统计窗口中可能还保留着上一轮熔断期间的降级记录。如果这些降级记录被纳入异常比例统计，就会影响半开状态下的判断。具体表现是：很多时候下游已经恢复了，但半开状态下的探测请求明明成功了，熔断器却迟迟不关闭。这是因为统计窗口里那段降级产生的异常记录还没滑出，异常比例依然超过阈值，导致熔断器在半开状态下又被重新触发为打开状态。

这个现象在线上非常隐蔽，因为它不是每一次都会出现，只有当统计窗口的大小和熔断保持时长的比例恰好让你踩到那个“交叉点”时才会发生。

5.2 线上如何判断熔断是不是被误触发的

如果你怀疑自己遇到了类似的时间窗口交叉误触发，可以按照这几个步骤排查：

第一，打开 Sentinel 控制台，查看“实时监控”里的每分钟数据，尤其是异常数、通过数和降级数的走势。如果发现熔断触发的前一秒有大量的降级记录，而这些降级记录并不是因为下游调用失败，而是因为之前的熔断处于打开状态，那么这个数据就是“脏数据”。

第二，检查你的statIntervalMs是否远小于timeout。如果统计窗口是 1 秒，而熔断保持时间是 30 秒，那在熔断打开的 30 秒内，统计窗口可能已经滚动了 30 次。每次滚动后统计结果都在更新，但这些更新里掺杂了降级数据，最终半开状态判断时用的就是这些数据。如果statIntervalMs更大，比如和timeout相同，那交叉的概率就会降低。

第三，用日志验证。在 Sentinel 的用法里，你可以在降级回调方法里记录当前熔断器状态、抛出异常的原始信息，以及当时统计窗口里的数据快照。对比熔断器重新打开的时间点和异常统计的时间点，就能判断是不是统计窗口交叉导致的误触发。

第四，考虑给熔断规则单独设置更合理的statIntervalMs。我目前的习惯是：statIntervalMs设置成 1000ms 不变，但minRequestAmount拉高一些，比如 20 到 50，这样即使有少量的降级脏数据混入统计，也不足以达到触发阈值。这是一种工程上的容错手法。

这里我不是在教你把熔断阈值调大来规避问题，而是提醒你：统计窗口是熔断判断的数据基础，如果你的数据基础本身被降级动作污染了，那熔断判断就失去了意义。这也是为什么我建议把“熔断期间被降级的请求”和“真实调用失败的请求”分开埋点统计，不要混在一起。

6. 压测验证与上线前的检查清单

规则配完了、原理也吃透了，但你要是没压测验证过，我劝你最好不要直接上生产。半开状态这个机制，平时流量平稳的时候根本看不出来，但活动流量一来，问题全暴露了。

6.1 如何用可控的实验模拟一次完整熔断

我在本地做实验时，常用一个非常简单的演练方式：

第一步，准备一个接口，它的实现人为地分成两段：前 5 秒正常，后 5 秒强制休眠 2 秒再返回。这样能模拟下游慢调用故障。

@RestController public class TestController { @GetMapping("/test") public String test() throws InterruptedException { long current = System.currentTimeMillis() % 10000; if (current > 5000) { Thread.sleep(2000); } return "ok"; } }

第二步，给/test接口配置一条慢调用比例熔断规则，maxAllowedRtMs设为 1000ms，slowRatioThreshold设为 0.5，timeout设为 5000ms，minRequestAmount设为 5。

第三步，用压测工具以 10 个并发持续打这个接口，得到的结果应该是这样的：

• 前 5 秒：全部正常，熔断关闭状态。
• 中 5 秒：响应时间超过 1000ms，统计窗口发现慢调用比例超过阈值，熔断器打开，后续请求全部被降级。
• 后 5 秒：服务恢复，但熔断器还处于打开状态，请求依然被降级，直到 timeout 时间结束进入半开状态，探测请求成功，熔断器关闭，请求恢复。

这个实验结果能帮你直观看到熔断时间窗口和半开状态的工作过程。我个人强烈建议你在公司环境也做一次这样的演练，因为只有亲眼看到请求被拒绝、恢复、再拒绝的过程，你才会对熔断参数产生直觉。

半开状态的压测需要特别注意：当你使用比例探测时，并发请求中只有一部分会被真正放行到下游。如果放行比例设置得太小，比如 0.1，那么在你 10 并发的情况下，平均每秒只有 1 个请求被放行，要攒够 5 个成功样本关闭熔断器，可能需要 5 秒以上。这个延迟体验，需要业务方心里有数。

6.2 上线前必查的几个点

基于我这些年踩过的坑，整理一份熔断规则上线前的检查清单，每一条都值得过一遍：

• minRequestAmount是否与业务流量匹配。低流量服务设置过高的最小请求数，熔断等于没配；高流量服务设置过低的请求数，冷启动阶段容易被误触发。一般建议按统计窗口内期望请求量的 1.5 到 2 倍来配。
• maxAllowedRtMs是否贴合业务真实 RT 分布。先看线上 P99 响应时间，再把阈值设置成 P99 的 1.5 到 2 倍。如果直接设置成几十毫秒，很容易出现“正常波动也被熔断”的情况。
• 降级回调里是否提供足够的日志。熔断触发后，回调里一定要记录：资源名、熔断状态、异常类型、统计窗口数据。不然故障发生时你连锅都找不到。
• 半开状态的恢复流程，业务方是否知晓。有些业务方看到请求被降级，会下意识地重试。如果半开状态恢复需要一定时间，重试反而会增加探测请求的通过量，造成下游压力。明确告诉业务方：熔断期间不要重试，等它自然恢复。
• Nacos 推送链路是否通畅。上生产前，手动改一次规则，观察 Sentinel 控制台规则是否在 3 秒内刷新。如果超过 10 秒还没刷新，优先检查 dataId、groupId、rule-type 三个字段是否匹配。
• 多个微服务是否共用同一个 Nacos dataId。如果多个服务共用一套熔断规则，比如一个网关服务和一个订单服务，它们的流量特征完全不同，共用一套参数基本不会有好的效果。建议每个服务独立 dataId。

最后再分享一个我个人的习惯：规则初始版本从保守开始，宁可多熔断几次，也不要因为阈值配得太宽导致雪崩。上线后先观察一周，再根据线上数据把minRequestAmount和slowRatioThreshold调到合理区间。熔断机制的价值不在于它被精确地触发，而在于该触发的时候它一定不会缺席。