一、为什么要从单体拆分
创业初期，一个 war 包打天下是最优解：开发快、部署简单、调试方便。但当团队从 5 人涨到 50 人，单体架构的代价开始显现：
- 代码耦合：改一个登录逻辑，订单模块跟着编译。
- 发布互相牵连：营销活动要上线，得等支付模块一起发。
- 技术栈锁定：想用 Go 写风控，但整体是 Java，动不了。
- 扩缩容浪费：流量全在商品页，却得把整个应用横向扩容。
单体本身不是错误，它只是「在特定阶段的正确答案」。拆分的信号，是「组织协作成本 > 拆分带来的运维成本」。
二、演进路线（不要一步登天）
阶段 1：模块化的单体
在单体内用 package / module 做物理隔离，明确分层（controller / service / dao），禁止跨层调用。这一步零成本，却能让后续拆分顺滑很多。
阶段 2：抽出公共能力
把用户、权限、消息等明显独立的能力，先抽成独立的 jar / 内部 SDK，降低耦合面。
阶段 3：垂直拆分（按业务域）
按域把单体切成几个大服务：用户服务、订单服务、商品服务。数据库也随之分库。这是性价比最高的一步。
阶段 4：水平细化（按能力）
对变化频繁的子域（如营销、推荐）再细拆，引入消息队列解耦。
经验法则：先垂直、后水平；先业务、后技术；先数据库、后服务。
三、微服务带来的新坑
坑 1：分布式事务
单体里一个 @Transactional 搞定，微服务里要搞 Saga、TCC、本地消息表。建议：能避免分布式事务就避免，用「最终一致性 + 补偿」替代强一致。
坑 2：链路追踪缺失
一个请求穿过 8 个服务，出问题没人知道卡在哪。必须上 TraceId 全链路透传 + SkyWalking / Jaeger。
坑 3：运维复杂度爆炸
以前发一个包，现在发 20 个服务。没有 K8s + CI/CD + 监控告警 就别上微服务，否则 SRE 会崩溃。
坑 4：网络不可靠
服务间调用会因超时、重试、雪崩连环挂。要上熔断（Sentinel / Hystrix）、限流、降级。
四、落地清单
- 先有服务注册发现（Nacos / Consul）。
- 统一网关（鉴权、限流、路由）。
- 配置中心外置，别再改代码发版。
- 日志、监控、追踪三件套齐活。
- 数据库先垂直分，再考虑分表分库。
五、结语
微服务不是银弹，它用「运维复杂度」换「组织扩展性」。很多公司拆完发现：人没多，事没少，半夜告警倒是多了。架构没有好坏，只有「匹不匹配当下的团队与业务」。
康威定律：系统架构会复刻组织架构。先想清楚团队怎么组织，再决定服务怎么切。