告警：Pod CPU 987% 10 月 8 号下午，告警： [P1] order-service CPU 使用率 987% (limit 800%) 持续 20 分钟 CPU 是 8 核 limit，987% 意味着快跑满了。接口 P99 从 120 ms 涨到 3.4 秒，部分请求超时。 这类
目标：大促前把商品详情接口压到 8000 QPS 9 月 20 号拿到大促的容量需求：商品详情接口要扛 8000 QPS，P99 控制在 300 ms 以内。第一次压测跑下来只有 2000 QPS，P99 1.2 秒，差了 4 倍。 前后两周五轮优化，最后压到 8200 QPS、P99 178 ms
背景：一个新服务要不要上 WebFlux 9 月中旬要起一个新服务，作用是"详情页聚合"：前端调一次接口，我们并行调商品、库存、价格、营销、评价五个下游，聚合后返回。组里有人提议用 WebFlux，理由是"调用多、IO 密集，响应式最合适"。 我当时持保留态度，就花了一周做了个 POC，两边都实现一
为什么又搞了一套 Prometheus 我们本来有 SkyWalking 8.6，链路追踪和拓扑都挺好用。但它有两个地方不满足需求：一是数据默认只存 7 天（ES 成本摆在那），二是加自定义业务指标比较麻烦，我更习惯"自己埋点 + 自己配告警"这套。 于是给核心的几个服务加了 Prometheus
起因：压测时前 3 分钟的数据全不能看 9 月初给一个轨迹计算服务做压测，用 JMeter 压 10 分钟，发现吞吐曲线很怪：第 1 分钟 3200 QPS，第 3 分钟 7100 QPS，之后稳定在 8900 QPS 左右。同样的机器、同样的并发，吞吐差了 2.8 倍。 这其实就是 JIT 预热的
告警：0 点 15 分，堆积 1200 万 8 月 31 号晚上大促，我们值守到凌晨。0 点 15 分，告警响了： [P1] RocketMQ consumer lag: group=order-sync-consumer, topic=ORDER_SYNC_TOPIC diff=1,20
起因：财务对账时发现的几十笔差异 8 月初，财务同事甩过来一张表：7 月份有 63 笔订单，用户积分扣了但优惠券没发。我们日均 12 万单，63 笔占比万分之五，但财务按笔核对，一笔都不能有。 查下来问题出在下单流程。下单成功后要发一条消息给营销服务，让它发优惠券： @Transactional p
需求：30 分钟未支付自动关单 产品提了个很常见的需求：用户下单后 30 分钟没支付，自动关闭订单并释放库存。我们日均订单 12 万，粗略统计落在 30 分钟窗口内未支付的约 3.4 万单。 这个需求本质是"延迟任务"，实现方式有好几种，我基本都试过，把各自的坑记一下。 方案一：定时扫表 最朴素的写
现象：优惠券服务挂了，我们的订单服务跟着挂了 7 月 28 号晚上 8 点多，告警炸了。不是优惠券服务告警，是订单服务告警：Tomcat 线程池打满、健康探针失败、K8s 开始杀 Pod。 [P1] order-service / http_server_requests_seconds P99 >
起因：架构评审会上的一个提议 七月底的架构评审，有人提议"我们新服务要不要上 JPMS 模块化"。理由是能强封装、能裁剪 JRE 让镜像变小。当时我们正在做 JDK 11 迁移（见上一篇），正好顺手调研了一下。 我花了三天做了个 POC，结论是：服务端业务系统别上，工具类库可以考虑。过程和理由记一下
