Spring Cloud 团队正式发布了 2025.1.0 (Oakwood) 版本。不要被版本号迷惑——这是一个真正的大版本升级。它基于 Spring Boot 4.0 和 Spring Framework 7.0 构建，只是因为 Spring Cloud 从 2020 年开始采用年份命名方式，所以用了 2025.1.0 这个看似"小版本"的数字。实际上，这次升级的破坏性和重要性，完全等同于以往的 major 版本发布。
然而，浏览官方发布日志时，很多开发者却五味杂陈。这个曾经的微服务之王，如今的版本发布更像是一次"大瘦身"——移除的功能比新增的还多。
让我们回到2014-2015年。那时，微服务架构刚刚兴起，Netflix 开源了一整套微服务组件：Eureka、Ribbon、Hystrix、Feign、Zuul。Spring Cloud 横空出世，将这些组件整合成一套完整的解决方案，迅速成为 Java 微服务领域的事实标准。全球数百万 Java 开发者选择了 Spring Cloud，因为它解决了微服务架构中最棘手的问题：服务发现、负载均衡、熔断降级、配置管理。
十年后的今天。曾经的王者，在 2025.1.0 版本中却呈现出截然不同的姿态。
减法清单：被"抛弃"的功能
Spring Cloud 2025.1.0 最显眼的特征不是新增了什么，而是移除和边缘化了什么。
Gateway 的被迫拆分。旧的 spring-cloud-starter-gateway 被废弃，强制拆分成 WebFlux 和 MVC 两个版本。开发者必须明确选择技术栈 (Reactive 或 Servlet)。
OpenFeign 落伍。这个曾经最受欢迎的 HTTP 客户端组件，在官方文档中被标注为"兼容性适配器"。新项目不再推荐使用 OpenFeign，而是改用 Spring Framework 6 引入的 @HttpExchange 注解。
Spring Cloud CircuitBreaker 5.0.0 的核心实现不再依赖第三方库（Resilience4j、Sentinel），而是直接基于 Spring Framework 7 的原生熔断抽象构建。
Reactive Kafka 消失。在虚拟线程时代，曾经引以为傲的 Reactive Kafka Binder 被彻底移除。Spring 团队认为，标准的 Kafka Binder 配合虚拟线程已经足够高效。
强化虚拟线程支持
要理解 Spring Cloud 2025.1.0 的变化，必须先理解 Java 21 虚拟线程(Virtual Threads)带来的范式转移。
Java 21 虚拟线程的到来，从根本上打破了这个二元对立。虚拟线程将 Java Thread 与操作系统内核线程解耦，让阻塞操作不再消耗宝贵的内核线程资源。开发者可以用最简单的同步代码，获得接近 Reactive 的并发性能，所以 Reactive 编程的必要性大大降低，回归到传统 Servlet/MVC 模型变得可行且开发体验更加高效。
// 之前：需要 WebFlux 才能高并发
@RestController
public class OrderController {
public Mono<Order> getOrder(String id) {
return orderService.findById(id)
.flatMap(order -> userService.findById(order.getUserId())
.map(user -> enrichOrderWithUser(order, user)));
}
}
// 现在：MVC + 虚拟线程就够了
@RestController
public class OrderController {
public Order getOrder(String id) {
Order order = orderService.findById(id); // 阻塞调用，但不消耗内核线程
User user = userService.findById(order.getUserId());
return enrichOrderWithUser(order, user);
}
}虚拟线程的到来，让 Spring Cloud 的许多"优势"变成了"包袱"。
最直接的影响是 Spring Cloud Gateway 5.0.0 的拆分。面对虚拟线程的冲击，Gateway 团队做出了一个艰难的决定：将组件拆分成两个版本。
虚拟线程还让 Reactive Kafka Binder 失去了存在的意义。Reactive Kafka 曾经因其非阻塞的背压机制被视为高性能 Kafka 消费的终极方案。但实战中的复杂性极高，而虚拟线程让阻塞式 Kafka 客户端同样能提供优秀的并发性能。
Spring Cloud Stream 5.0.0 果断移除了 Reactive Kafka Binder。这一决策体现了 Spring 团队的实用主义：当新技术解决了旧问题，复杂的旧方案就该淘汰。
但这也意味着，Spring Cloud 又失去了一个"核心能力"。
Spring Framework 7 功能内置
虚拟线程只是冰山一角。Spring Cloud 2025.1.0 面临的更大挑战是：核心功能被 Spring Framework 7 原生化。
容错性功能的原生化
在微服务架构中，容错性(Resilience)是核心能力：重试、超时、断路器、限流、舱壁隔离。
过去，这些能力由第三方库提供：
• Netflix Hystrix（已停更）
• Resilience4j
• Alibaba Sentinel
Spring Cloud CircuitBreaker 作为统一抽象层，整合了这些第三方库。这是 Spring Cloud 的核心价值之一。
但 Spring Framework 7 改变了一切。容错性被提升为框架的一等公民，直接内置在 Spring Core 中。
Spring Cloud CircuitBreaker 5.0.0 引入了一个全新的模块，直接基于 Framework 7 的原生容错性抽象构建。
OpenFeign 即将淘汰
Spring Framework 6 引入了 @HttpExchange 注解，允许开发者通过定义接口来声明 HTTP 客户端，这与 OpenFeign 的理念如出一辙。但当时 @HttpExchange 还只是"玩具"，缺少微服务场景必需的负载均衡和断路器集成。
真正的转折点在 Spring Cloud Commons 5.0.0。在这个版本中，@HttpExchange 终于补齐了最后一块拼图：自动集成负载均衡与断路器。
// 过去：使用 OpenFeign
@FeignClient(name = "order-service")
public interface OrderClient {
@GetMapping("/orders/{id}")
Order getOrder(@PathVariable("id") String id);
}
// 现在：使用 @HttpExchange（Framework 原生）
@HttpExchange("/orders")
public interface OrderClient {
@GetExchange("/{id}")
Order getOrder(@PathVariable("id") String id);
}在 2025.1.0 环境下，只要类路径中存在服务发现组件（如 Eureka Client），上述代码就会自动具备：
• 服务名解析
• 负载均衡
• 断路器保护
这带来巨大的好处：
• 无需额外依赖：不再需要引入 spring-cloud-starter-openfeign。
• 性能更好：去除了 Feign 的反射代理层。
• 启动更快：对 GraalVM Native Image 更友好。
但对 OpenFeign 来说，这是判了死刑。
尽管 Spring Cloud OpenFeign 更新到了 5.0.0，但在官方发布博客中，@HttpExchange 被大篇幅介绍，而 OpenFeign 只有一句话："更新以兼容 Jackson 3"。新特性的开发重心已完全转移至 Spring Interface Clients。
OpenFeign 的角色从"首选方案"变成了"兼容性适配器"，只为兼容遗留代码而存在。
笔者感悟
在 AI 编程时代，这种转变显得尤为必要。AI 辅助编程工具（Claude Code、Cursor 等)将传统编程效率提升了数倍，开发者能够以前所未有的速度构建和迭代应用。但这也意味着:
• 冷启动速度至关重要：AI 加速的开发节奏下，等待应用启动变得格外煎熬。
• 依赖越少越好：轻量级项目更容易被 AI 理解和重构。
臃肿的框架正在成为 AI 编程时代的累赘。轻量化的 SpringBoot 配合虚拟线程和 GraalVM Native Image，让开发者能够快速启动/快速验证/快速迭代。当 AI 生成代码的速度超越人类，基础设施的响应速度就成为新的瓶颈。减法，反而赋予了 Spring Cloud 更强的生命力。
来源：https://mp.weixin.qq.com/s/f2Zo0hq7DicOu5YqXRzyUQ