最后一个服务切完是上周五晚上 我们 47 个 Java 服务，从 JDK 21 升到 25，前后六周。最后一个切完是 8 月 7 号晚上十一点半，切完我在群里发了句"收工"，然后第二天睡到中午。 JDK 25 从 GA 到现在十个月，这个时间点写"发布"有点晚。但好处是能用生产数据说话，而不是照着
一月的架构评审上，有人提议全量升 Spring Boot 4 开年第一次架构评审，议题是把公司 47 个 Java 服务统一升到 Spring Boot 4。提这个的人理由很充分：Boot 3.5 的 OSS 支持快到期，Spring AI 2.0 的里程碑版本已经明确要求 Boot 4 基线，晚动
我们一个网关服务，平时 P99 延迟 40ms 很稳，但每天凌晨批量任务后总有几次 200ms+ 的卡顿尖刺。G1 的 Mixed GC 停顿在堆大时是元凶。JDK 21 上 ZGC 已经成熟，我决定赌一把把它换上。 切换决策：先看停顿从哪来 先用 JFR 抓了一周 GC 数据。G1 在 16G 堆
背景：4.x 到 5.x 的跨代升级 八月底我们把分库分表中间件从 ShardingSphere 4.1 升到 5.3。4.x 用的还是旧的 sharding-jdbc 单库形态，配置散在 Spring 的 xxx.yaml 里；5.x 统一成了 shardingsphere-jdbc，配置模型完全
背景：一封邮件引发的升级 五月底基础架构组发了封邮件，说 Oracle JDK 8 从 8u211 起商业使用要收费，公司统一切 OpenJDK 11（下一个 LTS），老服务年底前迁完。我们组四个服务，清一色 Spring Boot 2.3.12 + JDK 8u282。我手上这个订单服务先动，Q
把 MySQL 5.7 升到 8.0，五个报错排了三天 4 月初，我们把订单库的 MySQL 从 5.7.26 升到了 8.0.19。起因很实际：运营要做"每个用户的消费排名"，5.7 里只能用会话变量写那种很难维护的 SQL，8.0 有窗口函数 ROW_NUMBER()，一行搞定。 升级过程本身（
我把没测完的 dev 合进了 master 这是上周四的事。手上同时开着三个分支，敲 git merge 的时候 tab 补全选错了分支，把还没测完的 dev 合到了 master，还 push 了。等我看到 CI 群里飘红，master 上已经多了 17 个提交。 那一刻脑子里闪过的念头是"要不要
