先交代一个我亲身踩过的坑：订单服务每次调用物流服务，双方都在赌对方没改接口。HTTP 面上跑的是 JSON：请求字段靠字符串拼，响应字段靠手抄文档。物流团队把响应里的 waybillNo 改名成 shipmentId，旧字段悄悄删掉，订单服务的解析代码拿到 null 照常往下走，三天后客服才发现运单号全空。改字段这种事在强类型世界有编译器拦着，在 JSON 世界只有运行时的 null 和日志里一条没人看的 WARN。那次之后我就认准了一件事：跨服务的字段契约不能靠人肉维护。

订单服务刚上线那阵子，我对它发出去的两个上游调用心里一直没底：风控服务在下单前校验这笔单子有没有问题，物流服务在支付后生成运单。第一版实现里，这两个调用散落在 Service 的各个角落：URL 字符串硬编码在方法体里，参数拼接靠手写格式化，响应解析各写一套，超时一个都没配。后来风控服务某次发布期 503 了半小时，订单服务整段跟着不可用，我排查时发现三处调用点了三套错误处理，其中一处直接把异常吞了，单子就这么无声无息地放过去了。

运营后台的「新订单监控」页面是我先用轮询撑起来的：前端每 3 秒发一次 GET /api/orders?since=…，几百个页面同时开着，一秒钟就是上百个请求，其中九成以上查回来的是空数组。高峰期轮询请求和正常下单请求挤在同一条队列里，接口响应从 40 毫秒涨到 1 秒开外，运营跑来找我反馈「页面刷新慢」，我打开数据库慢查询日志，里面躺着一排一模一样的查询，那一刻我就知道该换方案了。

前阵子我盯着一个下单接口，落库本身很快，麻烦都在落库之后：给客户发短信通知要 600 毫秒，积分入账要 700 毫秒，报表聚合要 800 毫秒。原来的写法是三件事按顺序排在一个方法里，我拿 curl 压了一把，接口响应 2155 毫秒，高峰期每个请求都把 HTTP 线程占住两秒多，吞吐量被这几件慢活按在地上。

上一章的 Spring Batch 解决的是「算得完」，这一篇解决「准时跑」。场景还是订单业务：每天凌晨扫对账文件，每隔几秒把超时未支付的订单取消掉，固定节拍刷新一次报表快照。这类活的共同点是间隔固定、单次很轻、一个都不能长期缺席。

上一章的 RabbitMQ 解决的是「通知得可靠」，这一章解决「算得完」。场景还是订单：每天凌晨把当天的对账文件倒进数据库，月底把全量用户跑一遍账单，每个季度把失效数据归档。这类活的共同点是数据量大、允许延迟、绝不允许算一半。你可以接受结果晚几个小时出来，但不能接受一个算了一半的结果被当成完整结果用。