一月的架构评审上，有人提议全量升 Spring Boot 4 开年第一次架构评审，议题是把公司 47 个 Java 服务统一升到 Spring Boot 4。提这个的人理由很充分：Boot 3.5 的 OSS 支持快到期，Spring AI 2.0 的里程碑版本已经明确要求 Boot 4 基线，晚动
从 3.3.5 升到 3.5.3，踩了四个坑 八月底我们把手上 11 个服务从 Spring Boot 3.3.5 升到了 3.5.3。原本计划两天搞定，实际花了九天，中间回滚了一次。这篇记录升级过程和四个值得说的坑。 先说结论：值得升，但别在业务高峰期前升。ServiceConnection 和结
HPA 扩容跟不上流量，问题出在启动要 8 秒 10 月初做了一轮容量压测，暴露了个之前没重视的问题。我们的 AI 网关在 K8s 上配了 HPA，CPU 超过 60% 就扩容。压测时流量从 500 QPS 拉到 3000 QPS，HPA 在 15 秒内触发扩容，但新 Pod 从调度到 Ready
网关从 3.2 升到 3.3，我把虚拟线程打开了 国庆前最后一周，我把内部 API 网关从 Spring Boot 3.2.5 升到了 3.3.4。这次升级的动机不是安全补丁，而是 3.3 里那几个终于能用的东西：虚拟线程的正式支持、CDS 启动优化，还有服务连接抽象。 网关是个典型的 IO 密集型
有天凌晨告警：订单服务报错率突增。我登录 Kibana 翻日志，几千行文本里找那一条异常，正则写到手抖，花了 20 分钟才定位。痛定思痛，把日志从"人看"改成"机器看"——结构化输出，这套改造后来的排障时间从 20 分钟降到 40 秒。 为什么要从文本日志切到结构化 文本日志是给人扫的，机器分析要正
等到了 Spring Boot 3.2 的虚拟线程开关 Spring Boot 3.2 把虚拟线程集成做进了自动配置，一个属性就能让 Tomcat 用虚拟线程处理请求。我在 3.2 RC 阶段就拉下来试了，把订单查询接口从平台线程池切过去，吞吐数据很说明问题。不过 RC 阶段 API 还有微调，正式
提前迁移 Spring Boot 3.0：踩在 GA 前的准备 Spring Boot 3.0 要在 2022 年 11 月正式 GA，但我司有几个新服务打算直接基于 3.0 起项目，不想上线半年就面临大版本升级。于是我在 9 月就基于3.0 的里程碑/RC 候选版本做了一次迁移验证，把要改的点摸了
背景：3.1 刚发布，3.2 在路上 五月十八号 Spring Boot 3.1 正式发布，我们组件库当天就升了。3.2 按计划十一月才来，但里程碑里已经能看出方向。趁热把两版新特性盘一遍，顺手在预发环境验证了几个最实用的。 Docker Compose 支持（3.1） 以前本地起依赖靠 testc
背景：一次冷启动慢到被运维吐槽 五月初我把一个内部配置中心客户端容器化，K8s 里副本从 0 扩容到 10 时，启动要 8 秒多，滚动发布期间总有几秒请求打不到。运维说你这 Java 应用太重了。我琢磨着试一把 Spring Boot 3 的原生镜像——GraalVM 把应用直接编译成机器码，启动该
升级到 2.4，服务起不来了 6 月初，把一个服务从 Spring Boot 2.3.7 升到 2.4.6。改完 pom 里的版本号，启动，直接炸： *************************** APPLICATION FAILED TO START *******************
