微服务限流与熔断实战：从阈值配置到优雅降级

一次大促零点，订单服务在几分钟内被冲垮：上游重试、下游超时、数据库连接池打满，最后连健康检查都响应不了。事后复盘发现，问题不是某一个接口写错了，而是系统缺少一道“安全阀”——没有限流，流量可以无限涌入；没有熔断，故障会沿着调用链一级级放大。本文从工程实践出发，讲清限流与熔断的原理、配置方法和落地细节。

一、背景：为什么限流与熔断是微服务的必修课

单体时代，调用都在进程内，一个慢方法最多拖慢自己；微服务时代，一次用户请求可能经过网关、订单、库存、支付、物流等十几个服务，任何一个环节变慢都会通过同步调用把延迟传导回去。更麻烦的是客户端重试：上游超时后自动重试，下游实际收到的请求量可能是原始流量的两三倍，故障因此自我放大。限流解决的是“进来多少”的问题，在入口处把超出系统承载能力的请求挡在外面；熔断解决的是“还要不要继续打”的问题，当下游持续失败时主动断开调用，给下游恢复的时间，也给上游一个快速失败的机会。两者配合，才能让系统在流量洪峰和局部故障下“带病运行”，而不是整体崩溃。做这套机制之前，先要明确服务的容量基线：单实例在目标延迟下的最大吞吐、数据库连接数、线程池大小，以及核心接口与非核心接口的优先级，这些数字是后续一切阈值配置的依据。

二、核心原理：令牌桶、漏桶与熔断状态机

限流最常用的两种算法是令牌桶与漏桶。令牌桶以固定速率向桶中放入令牌，请求拿到令牌才能通过，桶满后多余令牌丢弃；它允许短时间的突发，因为桶里预存的令牌可以一次性被取走，适合应对秒杀开始瞬间那种“脉冲式”流量。漏桶则以固定速率放水，无论上游来得多快，流出速率恒定，起到削峰填谷的作用，但突发流量会在桶满后直接溢出丢弃。实际选型时，面向用户的入口网关常用令牌桶兼顾突发与平稳，面向数据库等脆弱资源的内部调用常用漏桶严格平滑。熔断器有三个状态：关闭、打开和半开。关闭时请求正常通过并统计失败率；当失败率或慢调用比例连续超过阈值，熔断器打开，后续请求直接快速失败，不再打到下游；经过一段冷却时间后进入半开状态，放少量探测请求通过，若成功则关闭熔断器恢复调用，若失败则重新打开。窗口统计、最小请求数、失败率阈值和冷却时间这四个参数共同决定了熔断的灵敏度，缺一不可。

三、实战配置：从阈值设定到分级降级

落地时建议按“网关、服务、资源”三层配置。网关层做全局限流，按接口维度设置每秒请求数上限，超限返回429并附带Retry-After头，让客户端有序退避；同时对不同租户、不同渠道设置配额，防止单个大客户挤占全部容量。服务层用信号量或线程池隔离做并发限流，核心接口单独分配线程池，非核心接口共用较小的池子，避免慢接口拖垮整个服务。资源层针对数据库、缓存和第三方接口设置连接数与超时，超时时间要逐级递减：网关三秒、服务两秒、数据库一秒，避免上游等下游等到天荒地老。阈值不要凭感觉拍定，要用压测标定：从基线吞吐的百分之七十起步，逐步上调，观察延迟拐点，把限流值设在拐点下方留出百分之二十余量。降级要分级：第一级返回缓存数据或默认值，第二级关闭非核心功能如推荐和评价，第三级只保留下单与支付主链路。每一级降级都要有开关和灰度能力，上线前用故障演练验证开关真的生效，而不是只存在于配置中心里。

四、常见坑：阈值拍脑袋、雪崩式重试与降级失真

第一个坑是阈值“一刀切”：所有接口同一个限流值，核心接口和边缘接口同等对待，结果大促时真正赚钱的下单接口被营销接口挤掉。正确做法是按业务价值分级，核心接口配额优先保障，低优先级接口先被限流。第二个坑是重试没有预算：客户端、服务网格和消息队列三层都在重试，乘数效应下一次失败会被放大成八次调用。重试必须设总次数上限、指数退避加随机抖动，并且只对幂等操作重试，非幂等的下单、扣款绝不能无脑重试。第三个坑是熔断阈值太灵敏：偶发抖动触发熔断，半开探测又因为流量太小长期无法恢复，服务在“熔断—半开—熔断”之间反复横跳。解决办法是设置最小请求数，样本太少时不触发熔断，并把冷却时间与业务恢复节奏对齐。第四个坑是降级数据失真：降级返回的缓存过期已久，用户看到的价格和库存都是错的，表面可用、实际损害更大。降级数据必须标注时效，关键字段降级时直接提示“稍后查看”，不要用错误数据冒充正确结果。第五个坑是只配不限、只熔不断：配置上线后从不看监控和告警，等到故障发生才发现限流规则早就不生效了。

五、总结：把保护机制做成可观测、可演练的能力

限流与熔断不是一次性的配置，而是一套持续运营的能力。第一，指标要可观测：限流拒绝数、熔断状态变化、半开探测成功率和降级触发次数全部接入监控大盘，设置阈值告警，拒绝数突增本身就是一次故障信号。第二，配置要可回滚：所有阈值与开关走配置中心，变更留痕，异常时一键回滚到上一个稳定版本。第三，能力要可演练：每月至少做一次混沌演练，主动注入延迟和错误，验证限流是否挡得住、熔断是否断得开、降级是否切得过去，演练结果记入值班交接。第四，复盘要闭环：每次真实故障后对照本文的清单检查，是阈值不合理、重试无预算，还是降级没生效，把结论沉淀为下一轮压测的输入。流量永远会超出预期，依赖永远会偶尔失败，唯一可控的是系统面对冲击时的姿态——有上限、有底线、有退路。把这三件事做好，微服务才能在高峰期站得住，在故障时倒得慢、恢复得快。