从单体到微服务：那些年我们在"过度设计"上交过的学费

背景：那次失败的重构

2023 年初，我们的电商系统已经稳定运行了两年。随着业务增长，单体应用开始显露疲态——部署变慢、耦合加深、一个小改动需要回归测试整个系统。团队里充斥着”拆微服务”的呼声。

过度设计的代价

我们一次性拆出了 12 个微服务。问题接踵而至：分布式事务、数据一致性、服务间调用的网络开销……原本一个简单的订单创建流程，现在需要跨越 4 个服务。

什么才是”够用”的架构

回头看，核心经验只有一条：按业务边界拆分，而不是按技术分层拆分。 先拆出最痛的模块（订单），验证收益后再逐步演进。一个写得好的单体，胜过十个拆分不当的微服务。