公司新上线的电商后台拆成了十几个微服务，一到大促就崩——订单服务CPU飙到95%，用户下单失败，支付服务超时，客服电话被打爆。这不是玄学，是典型的流量没管住。
流量控制不是“加个开关”就完事
很多人以为在网关上配个QPS阈值就算做了流量控制，结果发现：限流规则只拦住了部分请求，下游服务照样雪崩；突发流量一来，限流器还没反应过来，线程池就满了；更别说不同接口重要性不同，登录和查商品详情硬要一刀切，用户体验直接掉坑里。
真正有用的限流，得看三个地方
第一是入口层，比如Spring Cloud Gateway或Nginx，适合做粗粒度全局限流，防住恶意刷量或爬虫；第二是服务内部，像订单服务自己得知道“创建订单”不能超过300 QPS，而“查询历史订单”可以宽松些；第三是依赖调用链路，比如调用库存服务失败时，订单服务要快速熔断，别傻等超时。
Sentinel实战：5分钟接入驻点
以Spring Boot 2.7项目为例，先加依赖：
<dependency>
<groupId>com.alibaba.csp</groupId>
<artifactId>sentinel-spring-cloud-gateway-adapter</artifactId>
<version>2.2.10</version>
</dependency>然后在application.yml里开自动配置：
spring:
cloud:
sentinel:
transport:
dashboard: localhost:8080
eager: true启动Sentinel控制台（下载jar包直接java -jar运行），再访问你的服务一次，控制台就能看到服务名了。点进去，在“簇点链路”里找到对应接口，比如 /api/order/create，点击“流控”，填上QPS=200、流控模式选“关联”，关联资源填 /api/inventory/check——意思是库存检查太慢时，主动限制订单创建，保核心链路不卡死。
别光盯着QPS，线程数和响应时间也得盯
有些接口逻辑重，单次耗时长，QPS不高但线程占满。这时候该用“线程数”模式限流，比如设置最多10个线程处理 /api/report/export，避免导出报表吃光所有线程，把登录、下单全堵住。再配上“平均响应时间＞1000ms触发降级”，服务一变慢就自动切到兜底逻辑，返回缓存数据或友好提示，而不是让用户干等转圈。
真实场景：秒杀活动怎么扛住洪峰
某次秒杀，预热流量正常，一开抢瞬间涌入2万请求/秒。我们提前在网关层按IP限流（每IP 5次/秒），过滤掉脚本刷单；在商品服务里对 /api/item/seckill 接口设QPS=5000，并开启“排队等待”模式，让多余请求排队3秒，超时就丢弃；同时把库存扣减逻辑从同步调用改成消息队列异步处理，削峰填谷。结果服务器负载平稳，下单成功率92%，没出现大面积报错。
流量控制不是压测完写个文档就完事，它得跟着业务走：大促前调规则，新接口上线加保护，老接口下线删冗余策略。每天打开Sentinel看一眼实时QPS曲线，比啥监控都实在。