很多团队都经历过这样的阶段一个SpringBoot单体应用几万行代码几十个接口部署简单开发也快。可随着业务增长代码耦合越来越重改一个模块要回归全量发一次版战战兢兢。于是决定拆微服务。但拆完才发现分布式不是银弹而是另一场硬仗。一、单体之痛什么时候该拆单体不是原罪。日活几千、团队不到十人单体加模块化完全够用。真正的拆分信号是不同模块的迭代频率差异巨大比如订单天天改用户半年不动或者某个模块需要独立扩容比如秒杀又或者团队规模扩大代码冲突频繁。如果只是“觉得微服务先进”就拆大概率会后悔。二、拆分策略先垂直后水平不要一上来就按技术分层拆。正确做法是按业务能力垂直拆分用户服务、商品服务、订单服务、支付服务。每个服务独立数据库独立部署。初期服务粒度可以粗一点比如订单服务里先包含购物车等业务稳定再拆。拆的过程中先做防腐层把单体里的模块边界画清楚用接口隔离再逐步迁出。三、技术选型Spring Cloud Alibaba是务实之选国内团队建议直接上Spring Cloud Alibaba。Nacos做注册中心和配置中心一个组件解决两个问题OpenFeign做声明式调用Gateway做统一入口Sentinel做限流熔断Seata做分布式事务。这套组合文档全、社区活跃、踩坑少。不要贪多先把这五个用熟比堆一堆组件强。四、实战要点这五个坑必须避开第一服务粒度太细。一个请求经过五六个服务RT翻倍排查困难。建议初期控制在三到五个服务每个服务至少一个开发负责。第二分布式事务滥用。能不用就不用。订单和库存可以用本地消息表加RocketMQ事务消息实现最终一致支付和订单用TCC或Saga。Seata的AT模式虽然方便但锁竞争和性能损耗要评估。第三链路追踪缺失。没有SkyWalking或Zipkin线上问题就是黑洞。每个服务必须透传TraceId日志格式统一否则跨服务排查等于大海捞针。第四配置管理混乱。Nacos配置要按环境、按服务隔离敏感信息走加密。改配置不重启但要灰度发布避免全量推错。第五数据库拆分过早。先做读写分离和索引优化实在扛不住再分库分表。ShardingSphere可以帮你透明分片但分布式主键、跨库Join、事务问题要提前想清楚。五、分布式之后运维和协作方式全变了微服务不是技术升级是组织升级。每个服务独立发版意味着CI/CD流水线要按服务粒度建设日志分散意味着ELK或Loki要统一采集监控要按服务、按接口、按P99告警。更重要的是团队要建立“服务Owner”意识谁的服务谁负责接口变更要通知上下游故障要能独立止损。六、总结演进而不是革命从单体到分布式最好的方式是绞杀者模式新功能用新服务写老功能逐步迁移。不要推翻重来。微服务的核心价值是独立部署和独立扩容不是“看起来高级”。如果单体还能扛就先别拆如果决定拆就先把Nacos、Feign、Gateway、Sentinel、SkyWalking这五件套用扎实。记住架构是演进来的不是设计出来的。每一次拆分都要解决一个具体的痛点而不是为了拆而拆。