周会上被问住了 6 月底的架构周会，组里一个同学问："Spring 官方和 DeepSeek 合作之后，我们要不要把模型调用层切到官方 starter？" 我当时答不上来。这两年"XX 与 XX 达成合作"的新闻太多了，大部分最后落在 PPT 上。我没有花时间验证过，就不能在会上拍板，于是给自己派了
「Spring 是不是被 AI 时代落下了」 上个月团队里一个工作两年的同学问我：现在大家都在聊 LangChain、LlamaIndex、各种 Agent 框架，Spring 在这些话题里几乎不出现，是不是已经过时了？ 这个问题我这两年听过很多次。我当时没直接回答，让他去看看 spring-ai
用 WebFlux 四年，年底我把它重写了 2021 年我们做实时风控服务，选了 Spring WebFlux。当时的理由很充分：QPS 目标 2 万、需要背压、团队想试试响应式。四年过去了，这个服务一直在线上跑，但我对它的评价从"技术先进"变成了"维护负担"。 今年 10 月我用 JDK 21 虚
Java 生态终于有了统一的 AI 门面 之前接 OpenAI 要手搓 HTTP，接 Azure 又是一套，模型一换代码重写。团队里三个人各自封装了一遍，接口还不一样。Spring AI 在 2024 年初推出 1.0 里程碑版本，把各家模型、向量库抽象成统一接口。我拿它重构了工单助手，迁移成本比预
订单系统里，一个下单成功事件要同时触发：发短信、更新统计、同步搜索索引、通知风控。一开始我用 @TransactionalEventListener 在一个方法里全干了，结果短信接口抖一下，整个下单事务被拖慢。这种"一个事件多个消费者"的场景，正是 Spring Integration 的主场。 消
Java 也要有自己的 AI 抽象层 2023 年初，Python 侧 LangChain 已经热闹非凡，Java 这边还在各自调 OpenAI 的 HTTP。我们团队想给内部系统接个问答能力，结果每个项目都自己封装一套 OkHttp 调用，模型一换全部重写。Spring 社区开始孵化一个叫 Spr
为了启动快，走上 GraalVM 原生镜像 FaaS 场景下单实例冷启动 4 秒太慢，用户第一次请求要等很久。我们想用 GraalVM 把订单服务编译成原生镜像，目标启动 50ms 内。Spring Boot 3 的 AOT 引擎能提前做大部分 Bean 的初始化分析，理论上开箱即用。可一上来就卡在
为什么要看 Java 的 LLM 框架 团队要做个工单自动分类的小工具，调用 OpenAI。一开始我手搓 HttpClient 拼 JSON，发现每加一个能力就要重写一遍请求体、解析流、管上下文。更烦的是流式输出要自己处理 SSE，错误码要自己映射，超时和重试也要自己写。做了两个功能之后，代码里一半
背景：RestTemplate 越用越别扭 七月我们在预发环境试了 Spring 6.1 的里程碑版本（6.1 当时还没 GA，计划十一月随 Boot 3.2 一起），最让我眼前一亮的是 RestClient 和 HTTP Interface。以前用 RestTemplate，拼 URL、处理异常、
每天 300 万条的对账 财务对账原来用 crontab + 一个 main 方法跑，失败了从头来，半夜崩了没人管。最惨的一次，任务跑到一半数据库连接断了，已处理的 150 万条没记录，重跑又重复处理了一遍，对账差了几十万。换成 Spring Batch 后，断点续跑和重试才真正可控，凌晨的 job
