先摆一下我遇到的问题。订单详情页有一个聚合接口：请求进来后要串行调库存、定价、物流三个下游，每次调用 200ms，接口总耗时 600ms。大促峰值要撑 3000 QPS，按排队论算容量，需要的并发处理线程数是 3000 × 0.6s = 1800 个。Tomcat 的请求线程池默认上限 200，吞吐天花板是 200 / 0.6s ≈ 333 req/s，距离目标差 5 倍。把线程池调到 2000 也能算出差不多的容量，但每个平台线程预分配 1MB 栈内存，2000 个线程就是 2GB 的固定开销，加上上下文切换和调度成本，这条路我在评审里见过太多回，基本都走到头了。

前段时间盯着大促扩容看了一个问题：流量上来，Kubernetes 给订单服务一口气扩 10 个副本，结果新 Pod 得等 JVM 把 8000 多个类加载完、几十个自动配置类解析完才能接流量，就绪探针配 60 秒都不保险。缩容再扩容这么来回几次，冷启动时间就是实打实的容量成本，要是放在 Serverless 场景按毫秒计费，这笔开销甚至能决定方案能不能用。

前段时间我给支付服务对接下游通道，通道偶尔抖一下：前两秒请求全超时，第三秒自己恢复。老处理办法是引 spring-retry 或 Resilience4j，加依赖、加 @EnableRetry、按各自词表写注解，一套下来 POM 多两组坐标，依赖树多两层传递。这次我把 Spring Framework 7 收进框架本体的方案完整跑了一遍：@Retryable 和 @ConcurrencyLimit 两个注解加一个 @EnableResilientMethods 开关，重试与并发限制开箱即用，spring-retry 进入维护模式，Resilience4j 的注解体系在纯重试场景也省了。

上个月支付网关出了一次故障，客服那边的投诉先进来，我这边才反应过去翻日志。日志有，但散在四个服务实例里，想回答「昨晚十点支付接口慢在哪」，我得先找到慢的判断依据，再去四个实例里捞请求日志，最后把两次跨服务调用的日志按请求对上号。这三件事分别对应指标、链路、日志，工程上叫可观测性三件套。复盘的时候我意识到，排障有个更早的阶段：问题还没发生时，系统就该把三类信号持续吐出去，指标给告警提供阈值，链路给定位提供调用路径，日志给复盘提供细节。

前段时间我帮订单服务做过一次对账排查：财务那边的解析脚本按「字段有值才算有效记录」的口径读订单 JSON。游客单没留电话、没用优惠券、没填备注，响应体里这些字段带着 null 原样输出，对账脚本把整批订单判成无效数据，夜里重跑了三次，我第二天早上才看到告警。另一件事更隐蔽：金额字段 discountCents 在下单链路里偶尔是 null，对账方拿到 null 按数值 0 参与汇总，月初的折扣报表少算了两万块，排查的时候我才搞明白，null 与 0 在他们的口径里是两个东西，这么混着用迟早闹笑话。

先讲一段我自己的亲身经历。订单服务跑到第二年，产品要在新版 App 里把金额拆开摆：商品金额、折扣、运费各自一行。我把 /api/orders/{id} 的响应体重构了一遍，customerName 与 customerPhone 聚成 customer 对象，金额拆成 items 数组加 amount 子结构，自测没问题就发了版。上线十分钟，财务的对账系统报警：它按字段平铺解析订单 JSON，customer 对象它不认识，整批对账任务全挂。回滚、发版、写死一套字段映射兼容代码，前前后后折腾了我一周。