解释雪崩问题雪崩不是某个服务挂了而是整个调用链被 “超时 重试 排队” 拖到集体不可用雪崩到底是怎么一步步发生的第一步某个下游服务卡住了比如DB 慢查询外部接口超时锁竞争、死锁结果Tomcat 工作线程被占满→ 新请求进队列排队→ 队列很快也满→ 新请求开始超时、报错此时服务本身还活着但处理能力为 0。2. 第二步上游调用方开始超时你的服务超时 → 调用方网关、其他微服务收到Read timed outConnection refused504 Gateway Timeout重点调用方不会乖乖等死它们默认会做一件事重试而且很多框架默认是重试 3 次。3. 第三步流量被放大 310 倍重试会让「无效请求」叠加到原本的「有效请求」上本来 100 QPS重试 3 次 →瞬间变成 3001000 QPS这些流量全部打向已经线程打满的服务。结果队列瞬间爆炸连接数打爆端口占满文件句柄耗尽CPU 飙升内存飙升4. 第四步这个服务开始 “传染” 其他服务因为远程调用也属于tomcat请求这个服务不可用 → 依赖它的上游也开始线程池耗尽、超时、排队然后上游也重试 → 再放大流量 → 再传染给更上游最后整个链路从下到上全部不可用看上去就是系统突然全挂了全部接口超时全部服务假死这就是雪崩。最关键的区别Tomcat 线程满服务还活着只是不处理新请求雪崩整个链路被重试、排队、超时拖垮所有服务都 “活着”但全都不能用用一句话总结雪崩雪崩不是某个服务挂了而是整个调用链被 “超时 重试 排队” 拖到集体不可用。Tomcat 只是不主动崩溃但它扛不住指数级放大的流量和无限堆积的请求。那Tomcat 应该如何配置合适的线程数给你一个最实用的公式QPS ≈ 线程数 / 平均响应时间秒举个例子Tomcat 线程200接口平均耗时200ms 0.2s每个线程每秒可以处理的请求个数为1/0.25200个线程每秒可以处理的请求个数为200*1/0.21000总结 QPS ≈ 200 / 0.2 1000一旦 QPS 超过这个值请求就开始排队再高就雪崩。如何解决以及预防雪崩问题1.超时处理解决设定超时时间请求超过一定时间没有响应就返回错误信息不会无休止等待缓解方案不会根治当你释放请求的速度小于新加入请求的速度时仍会拖垮服务2.舱壁模式线程隔离解决限定每个业务能使用的线程数避免耗尽整个tomcat的资源因此也叫线程隔离一、先理解线程隔离要解决什么问题没有线程隔离时服务 A 调用服务 B、C、D共用一个线程池服务 B 超时导致线程池被占满 → 调用 C、D 的请求也没线程可用 → 服务 A 彻底不可用。线程隔离后给调用 B、C、D 分别建独立的线程池服务 B 超时只会占满 “调用 B 的线程池”调用 C、D 的请求不受影响 → 避免全链路雪崩。二、线程隔离的核心实现思路核心是「资源池化 边界隔离」把线程按 “业务维度 / 调用维度” 分成多个独立池子每个池子有自己的上限核心线程、最大线程、队列互不干扰。实现方式 1按「下游服务」隔离最常用给每个被调用的下游服务分配独立的线程池调用服务 B → 用「B 线程池」调用服务 C → 用「C 线程池」彼此的线程不共享一个池子满了不影响其他。实现方式 2按「业务模块」隔离给核心业务比如支付和非核心业务比如日志、统计分配独立线程池支付业务 → 用「支付线程池」配置更大、优先级更高日志收集 → 用「日志线程池」配置更小非核心业务崩了核心业务不受影响。3.熔断降级解决由断路器统计业务执行的异常比例如果超出阈值则会熔断该业务拦截访问该业务的一切请求。降级后直接切断对故障依赖的调用执行兜底逻辑如返回默认值、空数据、提示 “服务暂不可用”释放被阻塞的资源保证核心功能如下单、支付不受影响。示例用户头像上传依赖的对象存储服务故障降级为 “暂无法上传头像默认使用灰色头像”仅影响头像功能不影响用户登录、发帖等核心操作。熔断和降级区别很多人会混淆熔断和降级其实二者是 “互补协作” 的关系熔断被动触发如异常率超标暂时切断对故障服务的调用“断连”防止持续失败降级主动兜底无论是否熔断提供替代逻辑保证服务 “有回应”二者结合熔断负责 “切断异常调用”降级负责 “给出兜底结果”共同保障系统稳定性。熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例如果超出阈值则熔断该服务。即拦截访问该服务的一切请求当服务恢复时断路器会放行访问该服务的请求。断路器有三个状态closed、open、half-open工作原理如下熔断策略三种慢调用、异常比例、异常数1.慢调用业务的响应时长RT大于指定时长的请求被认定为慢调用请求。在指定时间内如果请求数量超过设定的最小数量慢调用比例大于设定的阈值则触发熔断。2.异常比例或异常数统计指定时间内的调用如果调用次数超过指定请求数并且出现异常的比例达到设定的比例阈值或超过指定异常数则触发熔断。4.流量控制预防限制业务访问的QPS避免服务因流量的突增而故障授权规则一般情况下请求通过网关进行授权即可但是想象一下一种情况公司出现了内鬼将你们公司的某一个微服务的地址直接暴露给了其他人那么这个人就会绕过网关直接去访问该微服务这是非常危险的。授权规则可以对调用方的来源做控制有白名单和黑名单两种方式。白名单来源origin在白名单内的调用者允许访问黑名单来源origin在黑名单内的调用不允许访问
微服务保护-sentinel
发布时间：2026/5/21 11:08:32
解释雪崩问题雪崩不是某个服务挂了而是整个调用链被 “超时 重试 排队” 拖到集体不可用雪崩到底是怎么一步步发生的第一步某个下游服务卡住了比如DB 慢查询外部接口超时锁竞争、死锁结果Tomcat 工作线程被占满→ 新请求进队列排队→ 队列很快也满→ 新请求开始超时、报错此时服务本身还活着但处理能力为 0。2. 第二步上游调用方开始超时你的服务超时 → 调用方网关、其他微服务收到Read timed outConnection refused504 Gateway Timeout重点调用方不会乖乖等死它们默认会做一件事重试而且很多框架默认是重试 3 次。3. 第三步流量被放大 310 倍重试会让「无效请求」叠加到原本的「有效请求」上本来 100 QPS重试 3 次 →瞬间变成 3001000 QPS这些流量全部打向已经线程打满的服务。结果队列瞬间爆炸连接数打爆端口占满文件句柄耗尽CPU 飙升内存飙升4. 第四步这个服务开始 “传染” 其他服务因为远程调用也属于tomcat请求这个服务不可用 → 依赖它的上游也开始线程池耗尽、超时、排队然后上游也重试 → 再放大流量 → 再传染给更上游最后整个链路从下到上全部不可用看上去就是系统突然全挂了全部接口超时全部服务假死这就是雪崩。最关键的区别Tomcat 线程满服务还活着只是不处理新请求雪崩整个链路被重试、排队、超时拖垮所有服务都 “活着”但全都不能用用一句话总结雪崩雪崩不是某个服务挂了而是整个调用链被 “超时 重试 排队” 拖到集体不可用。Tomcat 只是不主动崩溃但它扛不住指数级放大的流量和无限堆积的请求。那Tomcat 应该如何配置合适的线程数给你一个最实用的公式QPS ≈ 线程数 / 平均响应时间秒举个例子Tomcat 线程200接口平均耗时200ms 0.2s每个线程每秒可以处理的请求个数为1/0.25200个线程每秒可以处理的请求个数为200*1/0.21000总结 QPS ≈ 200 / 0.2 1000一旦 QPS 超过这个值请求就开始排队再高就雪崩。如何解决以及预防雪崩问题1.超时处理解决设定超时时间请求超过一定时间没有响应就返回错误信息不会无休止等待缓解方案不会根治当你释放请求的速度小于新加入请求的速度时仍会拖垮服务2.舱壁模式线程隔离解决限定每个业务能使用的线程数避免耗尽整个tomcat的资源因此也叫线程隔离一、先理解线程隔离要解决什么问题没有线程隔离时服务 A 调用服务 B、C、D共用一个线程池服务 B 超时导致线程池被占满 → 调用 C、D 的请求也没线程可用 → 服务 A 彻底不可用。线程隔离后给调用 B、C、D 分别建独立的线程池服务 B 超时只会占满 “调用 B 的线程池”调用 C、D 的请求不受影响 → 避免全链路雪崩。二、线程隔离的核心实现思路核心是「资源池化 边界隔离」把线程按 “业务维度 / 调用维度” 分成多个独立池子每个池子有自己的上限核心线程、最大线程、队列互不干扰。实现方式 1按「下游服务」隔离最常用给每个被调用的下游服务分配独立的线程池调用服务 B → 用「B 线程池」调用服务 C → 用「C 线程池」彼此的线程不共享一个池子满了不影响其他。实现方式 2按「业务模块」隔离给核心业务比如支付和非核心业务比如日志、统计分配独立线程池支付业务 → 用「支付线程池」配置更大、优先级更高日志收集 → 用「日志线程池」配置更小非核心业务崩了核心业务不受影响。3.熔断降级解决由断路器统计业务执行的异常比例如果超出阈值则会熔断该业务拦截访问该业务的一切请求。降级后直接切断对故障依赖的调用执行兜底逻辑如返回默认值、空数据、提示 “服务暂不可用”释放被阻塞的资源保证核心功能如下单、支付不受影响。示例用户头像上传依赖的对象存储服务故障降级为 “暂无法上传头像默认使用灰色头像”仅影响头像功能不影响用户登录、发帖等核心操作。熔断和降级区别很多人会混淆熔断和降级其实二者是 “互补协作” 的关系熔断被动触发如异常率超标暂时切断对故障服务的调用“断连”防止持续失败降级主动兜底无论是否熔断提供替代逻辑保证服务 “有回应”二者结合熔断负责 “切断异常调用”降级负责 “给出兜底结果”共同保障系统稳定性。熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例如果超出阈值则熔断该服务。即拦截访问该服务的一切请求当服务恢复时断路器会放行访问该服务的请求。断路器有三个状态closed、open、half-open工作原理如下熔断策略三种慢调用、异常比例、异常数1.慢调用业务的响应时长RT大于指定时长的请求被认定为慢调用请求。在指定时间内如果请求数量超过设定的最小数量慢调用比例大于设定的阈值则触发熔断。2.异常比例或异常数统计指定时间内的调用如果调用次数超过指定请求数并且出现异常的比例达到设定的比例阈值或超过指定异常数则触发熔断。4.流量控制预防限制业务访问的QPS避免服务因流量的突增而故障授权规则一般情况下请求通过网关进行授权即可但是想象一下一种情况公司出现了内鬼将你们公司的某一个微服务的地址直接暴露给了其他人那么这个人就会绕过网关直接去访问该微服务这是非常危险的。授权规则可以对调用方的来源做控制有白名单和黑名单两种方式。白名单来源origin在白名单内的调用者允许访问黑名单来源origin在黑名单内的调用不允许访问
