微服务架构中的韧性设计：Resilience4j 指南 在分布式系统中，网络延迟、服务不可用等问题不可避免。Resilience4j 是一个轻量级的容错库，帮助我们构建更具弹性的应用。 核心模块 Circuit Breaker（熔断器） 当下游服务出现故障时，熔断器会暂时中断调用，避免级联故障。 R
晚上八点半，所有接口一起超时 4 月 15 号晚上八点二十几分，告警群开始刷屏：订单服务全部接口超时，错误率 100%。 Pod 是活的，CPU 和内存都正常，CPU 只有 31%。但所有请求都在报同一个错： 2021-04-15 20:23:41.882 ERROR [http-nio-8080-
商家后台一个接口 2.3 秒，被投诉了半年 3 月上旬，客服转过来一条工单：某连锁商家反馈"经营概览"页面打开要转好几秒，用了半年一直这样。 我复现了一下，确实慢。这个接口返回商家今日/本月/累计的订单量、销售额、退款率、热销商品 Top5、会员增长数，一共 9 个指标。 第一步永远是耗时拆解，不是
一次资损：限领 1 张的券，用户领了 2 张 1 月初的一个上午，运营在群里 @ 我：一张"新客专享 50 元券"，配置的是每人限领 1 张，有用户领到了 2 张，已经核销了一张。 我查了数据库： mysql> SELECT user_id, coupon_id, count(*) c FROM c
十一月二十三号：一条 SQL 拖垮了五个服务 那天上午 10:07，监控大屏开始变红。从商品服务开始，10 分钟内波及五个服务，最后整个交易链路不可用，持续 23 分钟。这篇把整个过程复盘一遍，包括我们当时做错的判断。 时间线 时间 事件 10:07 商品服务接口 TP99 从 45ms 涨到 3.
压测雪崩复盘：每一层的超时都设成了 30 秒 5 月初做 618 前的压测。我们给网关发了 3000 QPS 的流量，持续 90 秒，结果整个交易链路崩了：网关大量 504，订单服务 CPU 98%，成功率从 99.9% 掉到 34%，压测停止后还花了 4 分钟才恢复。 排查时发现一个很荒谬的事：从
第一次拆分拆错了，我们重做了一版 去年 10 月到今年 2 月，我把单体拆成了 7 个服务。上线稳定运行两个月之后，我自觉地把其中两个又合并了、一个重新划了边界。 原因说出来很打脸：我们造了个 common-service。它承担了字典、地区、短信模板、附件上传、金额计算这些"大家都要用"的能力，被
32 万行单体，我们用了 5 个月切成微服务，一次没停过机 去年 10 月启动的拆分，到今年 2 月底核心链路切完。这期间系统一天没停过，用户侧没有感知到任何一次发布异常。回过头看，技术选型上没什么新鲜的，真正难的是"怎么一步步把流量搬过去，以及搬错了怎么退回来"。 先说被拆的那个东西 shop-a
一个用户被扣了两笔钱：关于幂等我踩过的坑 10 月 12 号下午，客服转来投诉：用户买了一双 899 的鞋，银行卡扣了两次款，订单表里却只有一条订单。 查下来是这样的：用户点"立即支付"时网络抖了一下，前端没收到响应，自动重试了一次。两次请求都打到了支付回调接口，回调里没有做幂等，于是扣款发生了两次
查一个用户的投诉，我翻了两小时日志 上个月客服转来一个工单：用户说 6 月 20 号下午下过一单，付了钱但订单状态还是"待支付"。我拿着用户 ID 去 ELK 查，搜出来 3800 多条日志，全是这个用户的，而且几个接口的日志混在一起，根本分不清哪几条是同一次请求的。 翻了两个多小时才拼凑出大概的调
