压测雪崩复盘：每一层的超时都设成了 30 秒 5 月初做 618 前的压测。我们给网关发了 3000 QPS 的流量，持续 90 秒，结果整个交易链路崩了：网关大量 504，订单服务 CPU 98%，成功率从 99.9% 掉到 34%，压测停止后还花了 4 分钟才恢复。 排查时发现一个很荒谬的事：从
第一次拆分拆错了，我们重做了一版 去年 10 月到今年 2 月，我把单体拆成了 7 个服务。上线稳定运行两个月之后，我自觉地把其中两个又合并了、一个重新划了边界。 原因说出来很打脸：我们造了个 common-service。它承担了字典、地区、短信模板、附件上传、金额计算这些"大家都要用"的能力，被
一个用户被扣了两笔钱：关于幂等我踩过的坑 10 月 12 号下午，客服转来投诉：用户买了一双 899 的鞋，银行卡扣了两次款，订单表里却只有一条订单。 查下来是这样的：用户点"立即支付"时网络抖了一下，前端没收到响应，自动重试了一次。两次请求都打到了支付回调接口，回调里没有做幂等，于是扣款发生了两次
短信服务商挂了 23 分钟，我们丢了 1247 单 那是去年 11 月的事。我们合作的短信服务商机房故障，接口全部超时。按理说短信发不出去不是什么大事，但那天下单成功率从 99.9% 掉到了 63%，23 分钟里少成交了 1247 单。 原因很简单：下单接口里同步调用了发短信，短信服务超时 30 秒
DBA 丢给我一张容量曲线图 2 月底，DBA 在周会上放了张图：订单主库 t_order 已经 4200 万行，数据文件 38G，加上索引一共 51G，按每月 380 万行的增速，年底到 8000 万行，明年年中破亿。他的结论是"该考虑分库分表了"。 主管把这个评估任务派给了我。说实话我当时有点虚
接手了一个 4000 行的 Service 类 三月底，组里那个做了两年的老项目交到我手上。第一次打开 OrderServiceImpl.java，IDEA 右下角显示 4127 lines，我愣了一会儿。往下翻，一个方法从 1032 行开始，到 1450 行结束，中间嵌套了 7 层 if。 更绝望
