大家好,我是 展菲,目前在上市企业从事人工智能项目研发管理工作,平时热衷于分享各种编程领域的软硬技能知识以及前沿技术,包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。
图书作者:《ESP32-C3 物联网工程开发实战》
图书作者:《SwiftUI 入门,进阶与实战》
超级个体:COC上海社区主理人
特约讲师:大学讲师,谷歌亚马逊分享嘉宾
科技博主:华为HDE/HDG
我的博客内容涵盖广泛,主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告,同时也会提供产品优缺点分析、横向对比,并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。
展菲:您的前沿技术领航员
👋 大家好,我是展菲!
📱 全网搜索“展菲”,即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”,每周定时推送干货满满的技术长文,从新兴框架的剖析到运维实战的复盘,助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”,与我直接交流,不管是项目瓶颈的求助,还是行业趋势的探讨,随时畅所欲言。
📅 最新动态:2025 年 3 月 17 日
快来加入技术社区,一起挖掘技术的无限潜能,携手迈向数字化新征程!
文章目录
摘要
当我们重构遗留系统、上线新模块时,最大的风险往往不是“写错了”,而是“写对了但抗不住”。新功能刚上线,流量一涌入,直接把服务拖垮——这在技术上叫做雪崩效应,在业务上叫做背锅现场。
这篇文章将通过 Spring Cloud Gateway + Sentinel
的实战组合,讲清楚怎么用限流和熔断手段,有节奏地接入新流量、保护核心系统,同时还带你写一份可运行的 Demo。
引言
在实际项目中,我们常常面临这样的情境:
“老系统写得一团乱,但又不能停,要边运行边重构,咋办?”
于是我们可能拆了一些模块、写了新服务、准备上线……结果用户一访问,“500” 出现在控制台,全站告警。
问题不在代码,而在于新旧系统交接没有流量保护机制。本篇内容我们将解决:
-
新模块上线时如何“限量开放”?
-
如何避免一个新服务崩掉把网关或全链路都带挂?
-
怎么做到一旦异常立即“熔断隔离”,避免级联故障?
限流熔断:这事为什么不能靠 try-catch?
很多团队遇到“服务挂了”第一反应是加 try-catch。
但问题不在代码逻辑,而在系统承载能力超出限度时:你连 catch 的机会都没有。
限流的目的不是“阻止访问”,而是控制节奏。
熔断的目标也不是“关闭服务”,而是避免雪崩。
在网关侧提前识别压力,并进行“限流”和“熔断”保护,是一种前置式的风险管控策略。
核心技术选型:Spring Cloud Gateway + Sentinel
为什么选 Sentinel?
-
支持 QPS/线程数限流,提供熔断、降级、热点参数控制等能力
-
原生集成 Dubbo、Spring Cloud 等微服务生态
-
控制台+规则持久化+动态下发,可实时配置
为什么配合 Gateway?
-
网关作为所有请求的入口,是最理想的“限流点”和“熔断入口”
-
不改变业务逻辑,不干扰后端服务
Demo 环境搭建
我们基于以下技术栈:
-
JDK 17
-
Spring Boot 3.x
-
Spring Cloud Gateway
-
Sentinel 1.8.x(通过
spring-cloud-starter-alibaba-sentinel
引入)
项目依赖
<!-- pom.xml -->
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
</dependencies>
示例代码:Gateway + Sentinel 联合限流
Gateway 路由配置
# application.yml
spring:
cloud:
gateway:
routes:
- id: new-feature-service
uri: http://localhost:8081
predicates:
- Path=/api/v1/new/**
filters:
- name: RequestRateLimiter
args:
key-resolver: "#{@ipKeyResolver}"
redis-rate-limiter.replenishRate: 5
redis-rate-limiter.burstCapacity: 10
上面这一段做了基础的网关限流配置,每秒允许 5 个请求,突发最多 10 个。
Sentinel 限流规则注册(Java 代码方式)
@PostConstruct
public void initSentinelRules() {
List<FlowRule> rules = new ArrayList<>();
FlowRule rule = new FlowRule();
rule.setResource("/api/v1/new/test");
rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
rule.setCount(1); // 每秒最多1次
rule.setLimitApp("default");
rules.add(rule);
FlowRuleManager.loadRules(rules);
}
这里是最简单的 Sentinel 流控规则:对 /api/v1/new/test 每秒限1次。
加入熔断策略保护后端服务
@PostConstruct
public void initDegradeRules() {
DegradeRule rule = new DegradeRule();
rule.setResource("/api/v1/new/test");
rule.setGrade(RuleConstant.DEGRADE_GRADE_RT); // RT 熔断
rule.setCount(500); // 超过500ms就触发熔断
rule.setTimeWindow(10); // 熔断持续时间10秒
DegradeRuleManager.loadRules(List.of(rule));
}
配合 fallback:
@RestController
@RequestMapping("/fallback")
public class FallbackController {
@GetMapping("/default")
public ResponseEntity<String> fallback() {
return ResponseEntity.status(HttpStatus.SERVICE_UNAVAILABLE)
.body("系统正在熔断降级中,请稍后重试");
}
}
QA 环节
Q: 限流策略应该放在 Gateway 还是微服务内部?
**答:**建议优先放在 Gateway 层,成本低、灵活度高,微服务内部可以加热点参数控制、用户维度限流。
Q: 如果 Sentinel 控制台配了规则,Java 代码里的还生效吗?
**答:**控制台规则优先,如果使用 Nacos/Persistent Rule 管理,建议统一配置路径。
总结
上线新模块时别只考虑逻辑跑没跑通,更要关注:
-
系统能不能抗得住流量
-
异常是否能快速熔断,避免系统被拖垮
-
是否有灵活的开关能做灰度流量控制
使用 Spring Cloud Gateway + Sentinel 组合,可以帮你:
-
网关侧快速限流
-
服务侧智能熔断
-
控制台配置规则
-
实现平滑灰度上线
未来展望
-
接入 Nacos 持久化规则配置
-
搭配 Spring Boot Actuator 监控熔断统计指标
-
对接灰度平台,实现按用户/请求头/Region 做智能流控