目标：大促前把商品详情接口压到 8000 QPS 9 月 20 号拿到大促的容量需求：商品详情接口要扛 8000 QPS，P99 控制在 300 ms 以内。第一次压测跑下来只有 2000 QPS，P99 1.2 秒，差了 4 倍。 前后两周五轮优化，最后压到 8200 QPS、P99 178 ms
现象：优惠券服务挂了，我们的订单服务跟着挂了 7 月 28 号晚上 8 点多，告警炸了。不是优惠券服务告警，是订单服务告警：Tomcat 线程池打满、健康探针失败、K8s 开始杀 Pod。 [P1] order-service / http_server_requests_seconds P99 >
晚上八点半，所有接口一起超时 4 月 15 号晚上八点二十几分，告警群开始刷屏：订单服务全部接口超时，错误率 100%。 Pod 是活的，CPU 和内存都正常，CPU 只有 31%。但所有请求都在报同一个错： 2021-04-15 20:23:41.882 ERROR [http-nio-8080-
商家后台一个接口 2.3 秒，被投诉了半年 3 月上旬，客服转过来一条工单：某连锁商家反馈"经营概览"页面打开要转好几秒，用了半年一直这样。 我复现了一下，确实慢。这个接口返回商家今日/本月/累计的订单量、销售额、退款率、热销商品 Top5、会员增长数，一共 9 个指标。 第一步永远是耗时拆解，不是
十一月二十三号：一条 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 多条日志，全是这个用户的，而且几个接口的日志混在一起，根本分不清哪几条是同一次请求的。 翻了两个多小时才拼凑出大概的调
