从 3.3.5 升到 3.5.3,踩了四个坑 八月底我们把手上 11 个服务从 Spring Boot 3.3.5 升到了 3.5.3。原本计划两天搞定,实际花了九天,中间回滚了一次。这篇记录升级过程和四个值得说的坑。 先说结论:值得升,但别在业务高峰期前升。ServiceConnection 和结
为什么我们决定在非 LTS 版本上跑生产 JDK 24 今年三月发布,是非 LTS 版本。我们公司原来的规矩是只用 LTS,所以 JDK 24 刚出来时没人提议升级。 改变想法是因为三个具体需求:AI 服务里的虚拟线程 pinning 问题、推理结果回写服务的大堆小对象内存压力、以及函数计算场景的冷
语义缓存一直跑在 Redis Stack 上,Redis 8 说要合并进来 我们的语义缓存从 2024 年 9 月开始就跑在 Redis Stack 上(就是那个带 RediSearch 模块的发行版)。这套方案最大的别扭之处是:它跟官方主线版本是两套东西,运维要单独装,升级要跟 Stack 的节奏
网关从 3.2 升到 3.3,我把虚拟线程打开了 国庆前最后一周,我把内部 API 网关从 Spring Boot 3.2.5 升到了 3.3.4。这次升级的动机不是安全补丁,而是 3.3 里那几个终于能用的东西:虚拟线程的正式支持、CDS 启动优化,还有服务连接抽象。 网关是个典型的 IO 密集型
季度技术评审上被问:JDK 23 要不要跟 8 月底的季度技术评审,架构师抛了个问题:JDK 22 已经用了小半年,JDK 23 再过半个月就 GA,咱们是继续滚动跟版本,还是钉在 JDK 21 LTS 上不动。 当时线上三个集群:订单跑 JDK 17,网关和用户中心跑 JDK 21,还有个新做的
背景:3.1 刚发布,3.2 在路上 五月十八号 Spring Boot 3.1 正式发布,我们组件库当天就升了。3.2 按计划十一月才来,但里程碑里已经能看出方向。趁热把两版新特性盘一遍,顺手在预发环境验证了几个最实用的。 Docker Compose 支持(3.1) 以前本地起依赖靠 testc
为什么我们卡在 JDK 8,却决定直接跳 17 团队基础组件升级评审会上,有人提议"升到 JDK 11 过渡一下"。我投了反对票:既然要动,不如直接到 JDK 17——它是继 8 之后第二个长期支持版本(LTS),2021 年 9 月发布,生态已经足够成熟,而 11 到 17 之间没有第二个 LTS
消费组重平衡,队列堆积了 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
升级背景:单核 CPU 打满了 11 月初我们把缓存集群从 Redis 5.0.9 升到了 6.2.5。起因很直接:大促前压测,某个分片的 CPU 到了 92%,但机器是 8 核的——也就是说 Redis 把一个核跑满了,剩下 7 个核在旁边看着。 $ redis-cli -h 10.0.4.11