消费组重平衡，队列堆积了 30 万条 我们一个交易通知服务用 RocketMQ 4.9 做消费，某天上午扩容，新增 2 个消费者实例。按理说扩容应该更快，结果监控上"消费积压"从 0 飙到 30 万条，持续了 20 多分钟才消化完。组员在群里贴了张图："加机器反而更慢了？" 根因在老架构上：Rock
升级 Redis 7.0 时，我把一段 Lua 脚本换成了 Functions 4 月 Redis 7.0 正式发布，我们把集群从 6.2 升到 7.0。升级本身平滑（RDB/AOF 兼容），但翻 release notes 时发现一个我一直想要的东西：Redis Functions。我们原本用 L
「为什么这个 DTO 里的字段改不动了」 1 月底，一个新同事在群里问：他给订单查询的返回 DTO 加了个 @Data，然后用 Jackson 反序列化的时候报了一堆奇怪的错，改成 record 之后就好了，问我能不能把所有 DTO 都换成 record。 我当时的回答是：DTO 可以用，但不是所有
重构一段 140 行的 if-else 链 1 月初接手支付网关的回调处理模块，打开 NotifyDispatcher 一看，是一个 140 行的 if-else 链。我们新服务用的是 JDK 17（ZGC + G1 都在测），正好可以试试新的语法。 原始代码长这样 public NotifyRes
Code review 时那行 Arrays.asList 12 月底做代码评审，看到一个新同事写的状态判断： private static final List<String> PAID_STATUS = Collections.unmodifiableList( Arrays.a
升级背景：单核 CPU 打满了 11 月初我们把缓存集群从 Redis 5.0.9 升到了 6.2.5。起因很直接：大促前压测，某个分片的 CPU 到了 92%，但机器是 8 核的——也就是说 Redis 把一个核跑满了，剩下 7 个核在旁边看着。 $ redis-cli -h 10.0.4.11
起因：升级 JDK 11 之后堆少了 500 MB 前面那篇迁移记录里提过，订单服务从 JDK 8 升到 11 之后，稳定态堆占用从 2.6 GB 降到 2.1 GB。我当时只当是 GC 改进的附带效果，直到有同事问"为什么少了这么多"，我才认真去查了一下。 答案主要来自 JEP 254：紧凑字符串
起因：架构评审会上的一个提议 七月底的架构评审，有人提议"我们新服务要不要上 JPMS 模块化"。理由是能强封装、能裁剪 JRE 让镜像变小。当时我们正在做 JDK 11 迁移（见上一篇），正好顺手调研了一下。 我花了三天做了个 POC，结论是：服务端业务系统别上，工具类库可以考虑。过程和理由记一下
背景：一封邮件引发的升级 五月底基础架构组发了封邮件，说 Oracle JDK 8 从 8u211 起商业使用要收费，公司统一切 OpenJDK 11（下一个 LTS），老服务年底前迁完。我们组四个服务，清一色 Spring Boot 2.3.12 + JDK 8u282。我手上这个订单服务先动，Q
升级 JDK 11 之后，代码里开始出现 var 2 月初我们把一个服务从 JDK 8u272 升到了 JDK 11.0.10。升级本身没什么好说的，倒是有个副作用：有同事开始用 var 了。 第一次在 review 里看到这段代码，我打了回退： var result = orderService.
