企业官网建设流程全解析

做后端这几年，服务一拆成几十个模块，最先教我做人的往往不是业务逻辑，而是流量。某个晚上接口被爬虫刷爆，紧接着数据库连接池被打满，调用链一路雪崩，冲到监控台前面的时候，日志里全是 time out。后来我沉下心把 Sentinel 系统学了一遍，才真正搞明白这玩意儿的价值：它就是微服务场景下的流量防卫兵，专门干限流、熔断和系统保护这三件事。这篇文章是我从入门到实际接入的完整复盘，核心讲清楚 Sentinel 解决什么问题、内部机制怎么运作、如何快速搭一个能跑的 Demo、以及我在规则配置和上线准备上踩过的坑，适合正在研究微服务治理、想给服务加高可用保护的后端同学参考。

1. Sentinel解决的是什么问题：从一次线上雪崩事故说起

1.1 事故还原：一条调用链是这样被打垮的

先讲一个我自己经历过的场景。某个下午监控突然报警，订单服务整体耗时从 80ms 涨到 3s，紧接着商品服务和库存服务的错误率跟着往上爬。追了半天发现根源不在订单服务，而是底层会员服务依赖的数据库在做慢查询，会员接口的耗时从 50ms 直接变成了 2s。

会员服务的 Tomcat 线程池一共 200 个线程，一个请求要占 2 秒，意味着它每秒最多只能消化 100 个请求。可上游订单服务往它发的流量是 300 QPS，多出来的 200 个请求全部在队列里排队。队列一旦塞满，订单服务发现会员服务变慢，自己又不死心，加了重试逻辑，相当于把 300 QPS 放大成了 900 QPS。最后订单服务和会员服务一起把线程池耗尽，整条链路开始雪崩，前端页面一片超时。

这个事故最有教育意义的点不是"数据库变慢了"，而是：你没法保证下游永远不慢，但你可以决定自己在面对慢下游的时候能活多久。Sentinel 解决的就是这件事——在流量还没把系统打垮之前，提前把压力挡在外面。

1.2 限流、熔断、系统保护：防的不是同一个环节

我一开始把 Sentinel 理解成"限流 + 熔断"两个功能，后来才发现漏了第三个：系统保护。这三样东西防的根本不是同一个位置：

限流防的是上游流量太多。给入口设一个 QPS 上限，超出的请求直接拒绝或者排队，把压力挡在门外。打个比方，景区门口按门票量放人，进去了多少由门口说了算，不管里面游客多想往前冲。

熔断防的是下游已经不行了。当下游接口的错误率、慢调用占比超过阈值，立刻切断调用，快速失败，让下游有喘息机会。这就好比发现前面的桥断了，不等到了桥中央才发现，在上桥口就立牌子把人拦住。

系统保护防的是我自己也要被拖垮。当本机的 load、CPU、平均 RT 超过阈值，系统自动降低入口流量，优先保命。相当于商场里火警响了，先控制进场人数，免得里面的人出不去。

这三个功能在 Sentinel 里对应三个处理槽：FlowSlot、DegradeSlot 和 SystemSlot。先记住它们各自的职责，后面看规则配置、看告警、排查问题，思路都会清晰很多。

1.3 同赛道对比：为什么最后选了Sentinel

说实话，微服务容错组件并不只有 Sentinel 一个选择。Hystrix 基本停止维护，社区重心早就转向了 Resilience4j；Resilience4j 的熔断、舱壁做得不错，但限流只是一个简单的 RateLimiter，还很缺一个像样的可视化控制台。

Sentinel 在限流维度上做得更细：QPS、线程数、关联资源、链路入口、热点参数都能配；自带 Dashboard 能看到每个资源的实时调用量、拒绝量、RT 分布，规则还能在界面上直接下发。对于大多数微服务团队来说，少造一个轮子就是最大的加分。

不过它也不是零门槛。想用好 Sentinel，必须先理解它的资源概念和规则模型，不然很容易配出"形同虚设"的规则。接下来这部分是全文的重点。

2. 核心机制拆解：资源、规则与Slot链是怎么咬合的

2.1 一切皆资源：给要保护的东西起个不重名的名字

Sentinel 里，任何你想保护的东西都是一个资源，用字符串命名。可以是一个 Web 接口、一个 RPC 方法、一个方法上标了注解的业务逻辑，只要是能被打点的地方，都能当资源处理。

资源名必须在全局唯一，因为它是统计和规则的 key。我见过有人把同一个接口在不同 Controller 里定义了不同资源名，导致限流规则只对一半接口生效，排查了大半天。建议从第一天就定规范：资源名用"模块:接口语义"的格式，比如order:create、product:queryDetail，同时维护一份资源清单放到项目文档里。后面配规则的时候直接从清单里挑，不会重名，也不会漏配。

2.2 三种规则各自的判定逻辑

限流规则（FlowRule）有三个决策维度要看清楚。

第一个维度是按什么限：QPS 还是线程数。QPS 看的是每秒请求数，适合接口入口；线程数看的是并发占用的线程数，防的是"单个慢请求把线程池占满"。我自己的习惯是：对外入口按 QPS 限，内部 RPC 调用按线程数限。

第二个维度是作用模式：直接、关联还是链路。直接模式最常用，就限自己。关联模式很实用，比如导出接口会大量占用 IO，我担心导出流量一大把查询接口也拖垮，就给查询接口配一条关联规则，触发条件是导出接口的 QPS 超过阈值。链路模式更精细，是从指定调用链进入时才限，适合业务入口多、想单独保护某个上游来源的场景。

第三个维度是超限后的处理方式：快速失败、预热、匀速排队。看下面这个对照表：

熔断规则（DegradeRule）有三种策略：慢调用比例、异常比例、异常数。慢调用比例最常用，判定的核心参数有这么几个：count 表示"超过多少毫秒算慢调用"，slowRatioThreshold 表示慢调用占比超过多少触发熔断，minRequestAmount 表示统计窗口内最少请求数，timeWindow 表示熔断多少秒。

比如会员接口 P99 是 150ms，我设 count=200、slowRatioThreshold=0.5、minRequestAmount=5、timeWindow=10，意思就是：10 秒窗口内至少 5 个请求，其中一半以上耗时超过 200ms，就熔断 10 秒。熔断期间入口快速失败，窗口一过进入半开状态，放少量探测流量过去，探测通过就恢复，探测还是失败就继续熔断。

系统保护规则（SystemRule）盯着 load1、CPU、平均 RT、线程数、入口 QPS 这些整机指标。它不是简单设一个固定并发数，而是参考了类似 TCP BBR 的思路，根据当前负载和 RT 动态估算最大可放行入口流量。对网关入口、对整机资源敏感的服务来说，这层保护往往是最后一道保险。

2.3 一个请求进来后，Slot链里发生了什么

Sentinel 在资源入口处会走一条 Slot 链，跟过机场安检差不多。NodeSelectorSlot 负责建节点统计树，StatisticSlot 负责记录实时指标，AuthoritySlot 做黑白名单校验，SystemSlot 看系统保护，FlowSlot 查限流规则，DegradeSlot 查熔断状态。任何一个 Slot 判定拒绝，请求就在这里被拦下，抛出对应的异常，由 @SentinelResource 配的 blockHandler 或者 fallback 接住。

有一次线上收到大量"被熔断"告警，我下意识以为是限流阈值太紧，翻日志才发现是 DegradeSlot 在拒绝，根本原因是下游服务响应变慢导致熔断打开了，跟限流阈值没有半点关系。所以排查的时候先搞清楚是哪个 Slot 拒掉的，别一看到异常就盲目去调规则参数。

3. 从零到跑通：本地搭一个可复现的Sentinel用例

3.1 启动Dashboard，让客户端连上来

去 release 页面下载对应版本的 sentinel-dashboard jar，直接启动：

java -Dserver.port=8080 -jar sentinel-dashboard-1.8.6.jar

浏览器打开 http://localhost:8080，初始账号密码都是 sentinel。要注意，Dashboard 默认的数据是放内存里的，重启后机器列表会清空，所以它只适合本地体验和测试环境，生产环境要单独考虑存储方案，这个后面细说。

再准备一个普通的 Spring Boot 工程，JDK 8 以上。pom 加三个依赖：

<dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-core</artifactId> <version>1.8.6</version> </dependency> <dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-annotation-aspectj</artifactId> <version>1.8.6</version> </dependency> <dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-transport-netty-http</artifactId> <version>1.8.6</version> </dependency>

启动应用时加上客户端连 Dashboard 的系统参数：

java -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=sentinel-demo -jar your-app.jar

csp.sentinel.dashboard.server 是控制台地址，project.name 是应用在控制台里的显示名。客户端还会开一个本地 API 端口，默认 8719，用来接收控制台推下来的规则；如果 8719 被别的进程占了，就加一个 -Dcsp.sentinel.api.port=8720 指定可用端口。

有一个小坑：如果应用一直没出现在控制台的机器列表里，先检查是不是漏了 transport 依赖。没有 transport，客户端就是纯本地统计，跟控制台完全不通信，规则自然没法从界面下发。

3.2 用@SentinelResource定义一个受保护的接口

使用注解之前要先注册切面，让它生效：

@Configuration public class SentinelConfig { @Bean public SentinelResourceAspect sentinelResourceAspect() { return new SentinelResourceAspect(); } }

然后写一个带注解的接口：

@RestController public class UserController { private static final String RESOURCE_USER_QUERY = "user:query"; @GetMapping("/user/{id}") @SentinelResource(value = RESOURCE_USER_QUERY, blockHandler = "queryUserBlock", fallback = "queryUserFallback") public User queryUser(@PathVariable Long id) { // 模拟下游耗时 try { Thread.sleep(30); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } if (id == 999L) { throw new IllegalStateException("mock error"); } return new User(id, "user-" + id); } public User queryUserBlock(Long id, BlockException ex) { return new User(id, "blocked"); } public User queryUserFallback(Long id, Throwable t) { return new User(id, "fallback"); } }

这里有个很关键的分工：blockHandler 只处理被限流、被熔断时抛出的 BlockException；fallback 处理业务里跑出来的普通异常。上面这个例子，传 id=999 走 fallback，QPS 超限走 blockHandler。把这个分工记清楚，后面调试会省很多时间。

3.3 下发限流规则，压测看效果

控制台左侧找到 sentinel-demo，点"簇点链路"，能看到所有被拦截的资源。找到 user:query，点"流控"，设置 QPS 阈值为 5，保存。

然后用压测工具打一轮流量：

ab -n 2000 -c 20 http://localhost:8080/user/1

预期结果是：正常通过的请求每秒大约 5 个，剩下的全部命中 blockHandler，返回 body 是 blocked，HTTP 状态码依然是 200。Dashboard 的实时监控里能看到 QPS 曲线被削平，拒绝数跟着往上涨。

如果不想依赖控制台，也可以直接在代码里加载规则：

FlowRule rule = new FlowRule(); rule.setResource("user:query"); rule.setGrade(RuleConstant.FLOW_GRADE_QPS); rule.setCount(5); FlowRuleManager.loadRules(Collections.singletonList(rule));

代码方式更适合作单元测试和自动化验证。我建议先走控制台点一遍，感受"规则从下发到生效"的完整链路，再回来看代码实现，理解会顺很多。

4. 实战里最容易踩的坑：持久化、热点参数与降级细节

4.1 规则默认留在内存里：重启即丢

用控制台手动下发的规则，默认只存在应用内存里，应用一重启，规则全没了。测试环境无所谓，生产环境这就是事故级别的隐患：凌晨发完版，服务没有任何限流保护，大促流量一来直接裸奔。

要持久化，就得用 Sentinel 的数据源扩展。最常规的方案是放到配置中心（比如 Nacos），客户端启动时自动拉取，配置中心一变，客户端实时更新。用 Spring Cloud Alibaba 时配置差不多是这样：

spring: cloud: sentinel: transport: dashboard: localhost:8080 datasource: ds-flow: nacos: server-addr: 127.0.0.1:8848 dataId: sentinel-demo-flow rule-type: flow

不用 Spring Cloud Alibaba 的话，可以程序化注册数据源：

ReadableDataSource<String, List<FlowRule>> flowDs = new NacosDataSource<>("127.0.0.1:8848", "DEFAULT_GROUP", "sentinel-demo-flow", source -> JSON.parseArray(source, FlowRule.class)); FlowRuleManager.register2Property(flowDs.getProperty());

核心思想就是：控制台只负责可视化下发，真正"长效生效"的规则源要落在配置中心，否则规则从哪来都是临时的。我后来的做法是：兜底型规则放配置中心，临时调整从控制台下发，每次活动结束后把控制台上的临时规则清掉，再核对一遍配置中心的内容，避免留下没人知道的隐形规则。

4.2 热点参数限流：不是简单限一下资源就行

普通限流是对整个资源做总量控制，热点参数限流则可以对"某个参数值"单独做控制。典型场景是商品详情接口：爆款商品可能占了 80% 的流量，如果统一限流到很低的阈值，爆款被限、普通商品也陪跑；阈值设高了，爆款又能把下游打穿。

热点参数限流按参数下标定位要控制的参数，代码里这样配：

ParamFlowRule rule = new ParamFlowRule("product:detail") .setParamIdx(0) // 第 0 个参数，比如商品 ID .setCount(10); ParamFlowRuleManager.loadRules(Collections.singletonList(rule));

还可以给特定参数值单独设配额，比如给某个秒杀商品 ID 单独拉高阈值，其他商品保持低阈值。用的时候有两个警告：一是被统计的参数不能是无限基数的高随机值，比如每次请求都不同的 traceId，这种参数会直接把热点统计的内存打爆；二是热点参数限流依赖适配层能取到真实的参数值，不同接入方式对 Body 里参数的解析能力不一样，先确认你的 Web 适配器能取到参数，再配热点规则，不然规则怎么都命中不了。

4.3 blockHandler与fallback的签名陷阱

@SentinelResource 提供了 blockHandler、blockHandlerClass、fallback、fallbackClass、defaultFallback 这些字段。很多人配完控制台一热，接口直接 500，一看日志：处理方法找不到。

签名规则归纳成四条：

• blockHandler 方法必须在当前类，或通过 blockHandlerClass 指定外部类；指定外部类时方法必须是 public static。
• 方法返回值必须和原方法一致。
• 参数必须和原方法参数保持一致，可以追加一个 BlockException 作为最后一个参数。
• fallback 同理，可以追加一个 Throwable 参数。

还有一个容易忽略的逻辑：如果只配了 fallback 没配 blockHandler，被限流抛出的 BlockException 也会被 fallback 接住；两个都配了，分工才是"限流走 blockHandler，业务异常走 fallback"。

我之前遇到过同组同事的 case：方法有三个参数，blockHandler 只写了两个，应用启动时切面校验直接抛异常。所以写这些处理方法前先数好原方法参数，一个都不能少。

4.4 多规则叠加时，判定顺序会误导你的排查

一张表把常见规则在 Slot 链上的判定顺序列出来，排查时对照着看：

比如熔断和限流同时配置时，请求先过限流再查熔断。看到 DegradeException，说明是下游响应出问题导致的熔断，别去动限流阈值；看到 FlowException，才说明是入口流量超限。判定顺序搞反，很容易把线上问题引到错误的方向，查了半天查不到根因。

5. 上线之前必须想清楚的事：监控、阈值和性能开销

5.1 生产监控别只靠Dashboard

Dashboard 方便归方便，但它默认不落库，重启就什么都没了，而且它展示的是分钟级粒度，等人工刷到异常，基本已经晚了。我见过团队把 Dashboard 当生产监控面板用，结果控制台半夜宕机，规则虽然还在跑，指标却没地方看，出了事连个曲线都拿不出来。

建议至少在三个地方做监控：

第一，每个核心资源的 QPS、拒绝量、RT 指标，定期采集进统一监控系统，配上告警。第二，客户端 8719 端口暴露了一批命令接口，可以尝试用 /catalog 看看当前支持哪些命令，再按需拉取指标，适合做采集脚本或者对接已有监控框架，不同版本命令名略有差异，以实际返回为准。第三，限流事件本身要留日志。被 BlockException 拒掉的请求量是重要的业务决策依据，大促前看一眼"昨天被限流拒绝了多少请求"，才知道现在的规则合不合理、要不要临时松绑。

5.2 阈值怎么定：从历史数据往回缩

很多人第一次配规则是拍脑袋：觉得接口能扛 200 QPS，就配个 200，结果高峰期真实流量 150，规则形同虚设；或者反过来配了个 20，正常业务全被误伤，用户集体投诉。

我的建议是三步走。

第一步，从监控里拉最近 30 天该接口的流量分布，找一个"下游能稳定承受、又略高于日常峰值"的数值作为初始阈值。更靠谱的做法是先压测，测出系统真实的承载能力，再取承载能力的 80% 做阈值，给突发留一点余量。

第二步，上传新服务或者缓存刚重建的场景，把规则设成预热模式，避免冷启动阶段因为指标没上来就被误杀。

第三步，上线后观察一周误杀率，有误伤就微调，一次只调一个小步长，调整完在规则备注里写清楚原因和预期效果。不然过两个月，谁也说不清这条规则当初为什么存在。

熔断阈值有个更实用的参考：用下游接口的 P99 耗时作为慢调用判定的 RT 阈值，慢调用比例先设 0.5 左右，时间窗口先给 10 秒，确认能自动恢复再放宽。

5.3 性能开销与规则设计的边界

Sentinel 的统计基于内存和时间窗结构，常规 QPS 统计的开销很低，我本机压测基本观察不到额外 RT 影响。但有两个地方容易埋雷。

一是热点参数统计。高基数参数会把底层缓存冲爆，内存和 CPU 都会涨。尽量避免对每个请求都变化的参数做热点限流。二是资源名设计。资源粒度太细，比如把每个用户 ID 拼进资源名，会造成大量资源节点，统计内存膨胀；粒度太粗，规则又控制不精确。一般建议：URL 层面控制在路径模式级别，方法层面用接口语义级别，不要把动态 ID 拼进去。

最后说一个经常被忽略的点：规则上线前一定要做一遍压测，但压的不是业务能力，而是"规则触发后的表现"。把 QPS 压到阈值以上，看 blockHandler 返回是否正常，fallback 里有没有隐藏的网络调用，降级后链路能不能快速恢复。这些细节在真实流量下才会暴露，提前在测试环境过一遍，上线才睡得着。

我在几个项目里反复踩过同一类问题：规则在测试环境跑得好好的，一上生产就发现 fallback 里连了缓存，缓存抖动的时候 fallback 自己也不可用。所以最后就一条经验——降级路径一定要比主路径更简单、更稳，最好只是返回一个降级结果，别再引入新的依赖。