有天凌晨告警：订单服务报错率突增。我登录 Kibana 翻日志，几千行文本里找那一条异常，正则写到手抖，花了 20 分钟才定位。痛定思痛，把日志从"人看"改成"机器看"——结构化输出，这套改造后来的排障时间从 20 分钟降到 40 秒。 为什么要从文本日志切到结构化 文本日志是给人扫的，机器分析要正
订单系统里，一个下单成功事件要同时触发：发短信、更新统计、同步搜索索引、通知风控。一开始我用 @TransactionalEventListener 在一个方法里全干了，结果短信接口抖一下，整个下单事务被拖慢。这种"一个事件多个消费者"的场景，正是 Spring Integration 的主场。 消
Java 生态终于有了统一的 AI 门面 之前接 OpenAI 要手搓 HTTP，接 Azure 又是一套，模型一换代码重写。团队里三个人各自封装了一遍，接口还不一样。Spring AI 在 2024 年初推出 1.0 里程碑版本，把各家模型、向量库抽象成统一接口。我拿它重构了工单助手，迁移成本比预
为了启动快，走上 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、处理异常、
背景：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
自研鉴权撑不住了 公司原来的登录是各个系统各写一套 Session，互不相通。用户在我们三个产品里要登三次，运营吐槽了半年。我们决定用 Spring Authorization Server（基于 Spring Security 6）搭一个统一认证，做 OAuth2 授权中心，让所有子系统一处登录、
