-
我把几个服务实例缩容下线了、本以为流量自然就不会再来,可接下来好几十秒里调用方还在大量报连接被拒绝、请求纷纷失败,我盯着监控纳闷那些实例明明已经停了,最后才想明白实例没了是一回事调用方什么时候知道它没了是另一回事这中间隔着一段谁也绕不开的传播延迟的深度复盘
我的服务部署了多个实例、注册在服务注册中心、调用方通过服务发现拿到实例列表再负载均衡分发请求。某次缩容我把其中几个实例直接停掉,想当然以为实例一停就从可用列表没了、流量自然只去剩下的健康实例。可现实是停掉后好几十秒里调用方持续报错——大量 connection refused、超时、成功率掉一截才慢慢恢复。我确认那些实例真停了却百思不得其解,查调用方日志发现它请求的目标 IP 正是已下线实例。直到…- 0
- 0
-
我的核心下单服务好端端的突然大面积超时崩了,排查半天发现罪魁祸首竟是一个无关紧要的猜你喜欢推荐功能——它依赖的服务挂了,而我没做熔断降级,卡住的调用把整个服务的线程池占满、连下单都瘫了的深度复盘
我维护一个电商核心服务,有下单、查订单这些命脉功能,也顺带集成了一个猜你喜欢推荐——调一个独立推荐服务展示几个推荐商品,我一直觉得它挂了顶多少几个推荐位、无关痛痒。可那天监控突然炸了:整个核心服务大面积超时几乎瘫痪、下单成功率断崖下跌。我以为是数据库或下单逻辑出问题,翻遍下单链路都正常,直到打出线程堆栈才目瞪口呆:服务里几乎所有工作线程都卡在调那个推荐服务上干等着!原来推荐服务故障响应极慢,而我调…- 0
- 0
-
我给下游调用加了失败自动重试本想让系统更可靠,结果某次下游只是变慢,重试却把流量放大了好几倍直接把它压垮:一次重试风暴拖垮整个链路的深度复盘
我有个服务要调下游接口,之前偶尔因下游抖动失败,我想加个重试吧、失败自动重试3次、成功率能高不少。平时确实好用。可那天下游因 GC 卡顿只是变慢了(响应 50ms 涨到 2 秒、没挂),我却眼睁睁看着它在几十秒内被打成彻底挂掉、整条链路雪崩。复盘才倒吸凉气:下游一变慢,大量请求超时失败,每个失败的请求立刻重试3次,本来1倍的流量瞬间变成3~4倍,把本来还撑得住的下游直接压垮;压垮后失败更多、重试更…- 0
- 0
-
下游服务只是抖了一下,我们配的失败就重试三次反而把它彻底打死了,而且越打越死、再也起不来:一次重试风暴压垮下游、正反馈雪崩的深度复盘
我们调用下游服务,我很负责任地配了失败就重试最多三次,觉得能扛住下游临时抖动、更健壮。可线上某次下游只是因为一次 GC 短暂抖动了一下,结果它不但没缓过来反而被彻底打死、越打越死、迟迟起不来。复盘才看明白:那个失败就重试三次在下游抖动时变成了一场重试风暴——下游抖动→部分请求失败→上游对每个失败重试 3 次→请求量瞬间放大几倍→本就脆弱的下游被打成大面积失败→失败更多→重试更多→流量更大,形成越重…- 0
- 0
-
下游一个接口只是变慢了一点,我的整个服务却跟着全部瘫痪、所有请求都卡死,我对着调用下游时没设超时导致请求堆积线程耗尽的级联雪崩这个坑排查大半天的复盘
一个让我对分布式系统脆弱性彻底敬畏的网络坑,可怕在真正出问题的只是一个下游依赖(还只是变慢没完全挂),却像多米诺骨牌层层传染放大,最终把我自己本来好好的服务也拖垮——级联雪崩。服务 A 调下游 B 的 HTTP 接口,我图省事没设任何超时(HttpClient.newHttpClient 默认无超时无限等待)。B 正常时没问题,但那天 B 负载高响应从几十毫秒变成几秒几十秒(慢但没挂),灾难发生:…- 2
- 0
-
下游只是发布时抖了一下,我的服务却因为疯狂重试把它彻底打死、还让它久久无法恢复,我对着重试风暴和指数退避加抖动排查了大半天的复盘
一次本该轻描淡写的小故障:依赖的下游因发布短暂抖动几秒,本来加了重试就该平稳扛过。我也确实加了重试——失败就重试最多 3 次,以为很稳健。结果这"几秒小抖动"被重试放大成持续十几分钟的大故障:下游不但没恢复反而被打得更死,抖动结束后还久久缓不过来。百思不得其解:重试不是为了提高成功率吗怎么把下游搞死了?排查大半天才理解"重试风暴"这个反直觉陷阱:我的立即重试…- 0
- 0
-
下游只是抖了一下,我那个"失败就立即重试三次"的客户端却把它彻底打垮了、还陷入越重试越崩的恶性循环,我对着这场重试风暴排查了大半天的复盘
我给调下游的客户端加了"失败就立即重试 3 次",自觉更健壮了。结果某次下游只是短暂抖动变慢几秒(本该自己很快恢复),却演变成下游被彻底打垮、长时间不可用,而且监控显示抖动那刻请求量不降反升暴涨好几倍。深挖才懂是"重试风暴":下游整体抖动时所有请求几乎同时失败、又几乎同时立即重试,流量瞬间放大 3~4 倍涌向本已脆弱的下游,它更慢→更多超时→更多重试→流量更…- 2
- 0
-
重试把下游打死了:重试风暴避坑复盘
这是一次好心办坏事的典型事故,也是我对重试这个看似无害的机制彻底改观的一次。起因很小:我们依赖的一个下游服务某天出现了短暂抖动,有那么几秒钟变慢了少量请求超时了,这本来是件小事下游抖一下缓一缓通常几秒就自己恢复了。可那天它不仅没恢复反而被彻底打挂了一垮就是好久,连带把我们整个服务也拖垮了。事后复盘真凶让我大跌眼镜——把下游打死的不是别人,正是我们自己为了提高成功率而精心设计的失败自动重试机制。这就…- 2
- 0
-
慢下游拖垮核心下单:服务雪崩与熔断避坑复盘
一次让我刻骨铭心的雪崩。我们的核心下单服务会调用一个非核心下游——推荐服务,在下单页给用户推荐几个商品,这功能挂了也不影响下单顶多少几个推荐位无足轻重。可某天推荐服务因自身问题变得极慢,响应从几十毫秒涨到十几秒,然后匪夷所思的事发生了:我那本该坚如磐石的核心下单服务竟跟着一起瘫痪——下单大面积超时失败整条业务线告急。一个无足轻重的推荐变慢怎么会把核心下单拖死?顺调用链复盘才看清传导路径:下单服务用…- 0
- 0
-
偶发 502 故障复盘:keep-alive 超时不匹配、缺超时、重试风暴与连接池治理
一套日常 QPS 三四千的微服务系统,网关到订单服务这一跳每隔一阵就冒出大约千分之三的 502,监控曲线上是几个对不上流量高峰也对不上发布的孤立尖刺,客户投诉「点一次失败再点一次就好」,而后端订单服务的业务日志却干干净净——请求根本没进到业务逻辑,就在网络层被掐断了。这篇把这次「查无此错」的偶发故障从头复盘:一开始误判为上游 OOM 重启、白白扩容浪费了四十分钟,直到用 ss 看连接状态、tcpd…- 0
- 0
-
从粗放跨网络调用天真当成调一下拿到结果不设超时无脑重试没熔断不限流不隔离 + 不设超时或设几十秒慢下游把调用线程一个个挂死耗尽线程池调用方自己也垮再沿调用链层层传导冲垮整个核心链路雪崩 + 失败就立即原地无脑固定次数猛重试给过载下游火上浇油 N 客户端乘 M 重试瞬间放大数倍把下游彻底打死死亡螺旋还对扣款下单非幂等操作重试导致重复扣款下单 + 下游已经挂了还一根筋拼命猛打无效请求堆积线程全卡在死路上白耗资源还堵死下游恢复 + 对入口流量来者不拒突发洪峰直接把服务自身资源榨干压垮容量内请求也一起玉石俱焚 + 所有下游调用共用一个线程池连接池一个无关紧要的边缘慢下游就把公共池占满连核心订单支付调用也申请不到线程全线瘫痪 + 下游一挂调用方直接把故障原样上抛一个推荐挂掉整个详情页打不开用户连看商品下单都做不了被次要功能绑架核心 + 客户端无脑轮询所有后端不感知健康把请求往挂掉卡死的实例上送间歇性报错忙的更忙 + 网络调用是黑盒出事只能逐个翻日志加 tcpdump 抓包连蒙带猜耗时数小时抓不到是哪一跳慢 → 2026 现代服务间通信韧性工程 每个调用设合理超时加全链路 deadline 剩余预算传播 + 指数退避加抖动加只重试幂等加重试预算绝不放大故障 + 熔断器失败率超阈值快速失败给下游喘息给自己止血加半开试探 + 令牌桶漏桶限流超容量快速拒绝保住核心容量 + 舱壁隔离每个下游独立线程池连接池故障关在单个舱室 + 降级 fallback 下游不可用返回兜底数据保住主流程 + 健康检查加 P2C 最少连接加异常实例自动摘除 + 每跳成功率延迟熔断状态指标加分布式链路追踪 TraceID 串起整条链路 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
9 人的服务治理与中间件团队 87 天把一套由上百个微服务彼此通过网络调用编织而成、五年里服务从十几个长到上百个调用关系织成一张谁也理不清的大网、却一直停留在调用一下拿到结果天真阶段不设超时无脑重试没熔断不限流不隔离的庞大系统——绝大多数地方调用下游压根不设超时或随手填个几十秒形同虚设慢下游一卡调用线程就永久阻塞傻等高并发下线程池被一个个挂死耗尽调用方自己也垮再沿调用链反向层层传导像多米诺骨牌把整…- 0
- 0
-
微服务架构在第三方接口故障时 35 分钟全平台雪崩的复盘:熔断 + 限流 + 降级三件套落地全过程
一次第三方银行接口 100% 超时,通过 pay-gw 把雪崩传染到全部 50+ 微服务,业务全平台不可用 35 分钟。事故后用 7 天引入 Resilience4j + Polly + bulkhead 三件套,3 个月内类似事故 3 次全部局部隔离。复盘三件套的具体参数 + 协同决策树 + 容错反模式 + 可观测性配置 + 8 条容错纪律,适合所有微服务团队抄作业。- 0
- 0
-
gRPC 微服务超时与重试工程化完全指南:从一次"下游慢 800ms 上游 5 个服务全部雪崩"看懂为什么加 timeout 远远不够
2023 年我们公司有一套基于 gRPC 的微服务架构十几个服务互相调用拓扑大概有三四层深接手时表面看挺平静 QPS 不算高响应时间也还行可三个月里我们陆陆续续出了几次让我刻骨铭心的故障第一次是周五晚上一个下游的搜索服务因为索引重建延迟变高从 50ms 涨到 800ms 结果上游所有依赖它的服务的线程池被打满整个调用链上的 5 个服务全部超时雪崩业务被打挂 30 分钟第二次最莫名其妙某个接口压测时…- 2
- 0
-
熔断降级完全指南:从一次"一个边角服务变慢、整个系统被拖垮雪崩"看懂服务容错
2022 年我在做一个电商的商品详情页服务。一个详情页要展示很多东西库存价格用户评论还有猜你喜欢的推荐位。这些数据来自不同的下游微服务我的服务要把它们一个个调过来拼成一个完整的页面返回。第一版我做得很直接在一个函数里同步地一个接一个地调下游全调完了再拼页面。本地一测很顺每个下游都秒回。可上线几个月后的一天整个商品详情页突然大面积超时报错监控告警炸了。我冲上去查最后定位到是那个猜你喜欢的推荐服务因为…- 2
- 0
-
熔断降级完全指南:从一次"一个下游服务慢了、整个系统跟着雪崩"看懂熔断器
2020 年我维护一个电商的商品详情服务。它要做的事很简单:用户打开一个商品页,这个服务把商品基本信息、价格、库存,还有一项商品评价聚合起来返回。评价这块数据不在我这个服务里,它在另一个独立的评价服务上,我得调用它把评价数据取回来拼进商品详情。第一版我做得很直接:处理每个请求时同步地去调用评价服务,等它返回了再把数据拼好返回给用户。本地测试上线初期一切正常。直到有一天评价服务出了问题——不是挂掉而…- 2
- 0
-
限流熔断降级完全指南:Sentinel 与 Resilience4j 的高可用三件套
"流量突然涨 10 倍,系统怎么活下去?" —— 这是每个互联网工程师都会碰到的问题。限流、熔断、降级是高可用三件套,它们不是"可选优化",而是任何对外服务的必备保险。这篇文章把令牌桶、漏桶、滑动窗口讲透,然后讲熔断器模式、降级策略,以及 Sentinel / Resilience4j 等主流框架的工程实践。 问题:没有保护的系统怎么死 真实事故场景: 某接…- 0
- 0
熔断
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×