Spring Boot 3 + Spring Cloud 实战：从单体到微服务的平滑演进

微服务不是银弹。很多团队在业务还没复杂到一定程度时就急于拆分，结果换来分布式事务、链路追踪、运维复杂度的一地鸡毛。这篇文章记录我们在一个真实企业项目里，把单体 Spring Boot 应用平滑演进到 Spring Cloud 微服务的过程。

一、什么时候才该拆

我们倾向于在出现下面这些信号时再考虑拆分：不同模块的发布节奏严重冲突；某个热点模块需要独立扩容；团队增长到 8 人以上、代码所有权开始打架。在那之前，一个结构清晰的单体远比一组微服务好维护。

二、渐进式迁移：绞杀者模式

我们没有一次性推翻重来，而是采用绞杀者模式（Strangler Fig）：先在单体前面加一层 Spring Cloud Gateway 统一入口，再把最需要独立扩容的「订单服务」一点点搬出去。新旧系统并行运行，逐步把流量切到新服务，全程业务零中断。

三、关键组件选型

• 注册与配置中心：Nacos，注册与配置一体，运维成本最低
• 服务网关：Spring Cloud Gateway，统一鉴权、限流、路由
• 服务间调用：OpenFeign + Sentinel，声明式调用 + 熔断降级
• 分布式事务：优先用本地消息表做最终一致，强一致场景才上 Seata

小结

微服务化是一次架构演进，而不是一次重写。先有清晰的模块边界，再谈拆分；先上 Gateway 收口入口，再逐模块迁移。控制好节奏，业务零中断是可以做到的。

关键要点

• 先有模块边界，再谈拆分
• 用绞杀者模式逐步迁移，新旧并行
• Gateway 收口入口是第一步
• 分布式事务优先最终一致