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