前言

"微服务"这三个字在技术圈已经热了十多年，但"怎么拆"始终是最困扰架构师的问题。拆得太粗——换了个壳的单体；拆得太细——运维成本爆炸，调试像噩梦。

本文不讲微服务的基础概念（假设你已经知道什么是微服务），聚焦于一个核心问题：面对一个单体系统，你该用什么原则来划边界？

---

第一部分：单体架构的痛点与拆分的时机

1.1 单体不是原罪

在谈拆分之前，必须明确一个观点：单体架构不是原罪。很多成功的系统——包括 GitHub 早期、Stack Overflow——都是单体架构。单体的问题不在于"它是单体"，而在于"它何时变得不可维护"。