周会上被问住了 6 月底的架构周会，组里一个同学问："Spring 官方和 DeepSeek 合作之后，我们要不要把模型调用层切到官方 starter？" 我当时答不上来。这两年"XX 与 XX 达成合作"的新闻太多了，大部分最后落在 PPT 上。我没有花时间验证过，就不能在会上拍板，于是给自己派了
「Spring 是不是被 AI 时代落下了」 上个月团队里一个工作两年的同学问我：现在大家都在聊 LangChain、LlamaIndex、各种 Agent 框架，Spring 在这些话题里几乎不出现，是不是已经过时了？ 这个问题我这两年听过很多次。我当时没直接回答，让他去看看 spring-ai
GA 在下个月，我们这个月就已经在迁了 Spring AI 2.0 的 GA 定在 2026 年 6 月。我们在 5 月初就拉了 2.0.0-RC1 做迁移演练，到今天两周，9 个服务里有 6 个跑通了。 为什么不等 GA？因为 1.x 到 2.0 的破坏性变更比想象中多，我们评估过，等 GA 再动
一月的架构评审上，有人提议全量升 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 和结
三十多个工具方法散在各处 去年底我们把内部运维助手接上了大模型，能查订单、查库存、重启任务。当时图快，工具方法用 Spring AI 的 @Tool 直接写在各个业务服务里，谁需要谁加。到 2025 年 2 月一数，散在 6 个服务里总共 37 个工具方法，问题就来了：网关那边的对话服务要用库存工具
四个服务里塞了四份大模型调用代码 年初我们把 AI 能力往业务里铺的时候，图快，哪个服务需要就直接引一份 spring-ai-openai，配个 key 开干。到六月底盘点，订单服务、客服服务、商品服务、报表服务里各有一套调用代码，四份 application.yml 里躺着四个 API Key。
用 WebFlux 四年，年底我把它重写了 2021 年我们做实时风控服务，选了 Spring WebFlux。当时的理由很充分：QPS 目标 2 万、需要背压、团队想试试响应式。四年过去了，这个服务一直在线上跑，但我对它的评价从"技术先进"变成了"维护负担"。 今年 10 月我用 JDK 21 虚
Java 生态终于有了统一的 AI 门面 之前接 OpenAI 要手搓 HTTP，接 Azure 又是一套，模型一换代码重写。团队里三个人各自封装了一遍，接口还不一样。Spring AI 在 2024 年初推出 1.0 里程碑版本，把各家模型、向量库抽象成统一接口。我拿它重构了工单助手，迁移成本比预
HPA 扩容跟不上流量，问题出在启动要 8 秒 10 月初做了一轮容量压测，暴露了个之前没重视的问题。我们的 AI 网关在 K8s 上配了 HPA，CPU 超过 60% 就扩容。压测时流量从 500 QPS 拉到 3000 QPS，HPA 在 15 秒内触发扩容，但新 Pod 从调度到 Ready
