网关从 3.2 升到 3.3，我把虚拟线程打开了 国庆前最后一周，我把内部 API 网关从 Spring Boot 3.2.5 升到了 3.3.4。这次升级的动机不是安全补丁，而是 3.3 里那几个终于能用的东西：虚拟线程的正式支持、CDS 启动优化，还有服务连接抽象。 网关是个典型的 IO 密集型
有天凌晨告警：订单服务报错率突增。我登录 Kibana 翻日志，几千行文本里找那一条异常，正则写到手抖，花了 20 分钟才定位。痛定思痛，把日志从"人看"改成"机器看"——结构化输出，这套改造后来的排障时间从 20 分钟降到 40 秒。 为什么要从文本日志切到结构化 文本日志是给人扫的，机器分析要正
订单系统里，一个下单成功事件要同时触发：发短信、更新统计、同步搜索索引、通知风控。一开始我用 @TransactionalEventListener 在一个方法里全干了，结果短信接口抖一下，整个下单事务被拖慢。这种"一个事件多个消费者"的场景，正是 Spring Integration 的主场。 消
为了启动快，走上 GraalVM 原生镜像 FaaS 场景下单实例冷启动 4 秒太慢，用户第一次请求要等很久。我们想用 GraalVM 把订单服务编译成原生镜像，目标启动 50ms 内。Spring Boot 3 的 AOT 引擎能提前做大部分 Bean 的初始化分析，理论上开箱即用。可一上来就卡在
等到了 Spring Boot 3.2 的虚拟线程开关 Spring Boot 3.2 把虚拟线程集成做进了自动配置，一个属性就能让 Tomcat 用虚拟线程处理请求。我在 3.2 RC 阶段就拉下来试了，把订单查询接口从平台线程池切过去，吞吐数据很说明问题。不过 RC 阶段 API 还有微调，正式
背景：RestTemplate 越用越别扭 七月我们在预发环境试了 Spring 6.1 的里程碑版本（6.1 当时还没 GA，计划十一月随 Boot 3.2 一起），最让我眼前一亮的是 RestClient 和 HTTP Interface。以前用 RestTemplate，拼 URL、处理异常、
提前迁移 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 把应用直接编译成机器码，启动该
每天 300 万条的对账 财务对账原来用 crontab + 一个 main 方法跑，失败了从头来，半夜崩了没人管。最惨的一次，任务跑到一半数据库连接断了，已处理的 150 万条没记录，重跑又重复处理了一遍，对账差了几十万。换成 Spring Batch 后，断点续跑和重试才真正可控，凌晨的 job
