第一篇　拆分前夜：单体的痛与拆分的代价

开篇我们说过这本书要解决什么问题：一个 Go 单体电商跑到日活三万后，如何一步步拆成微服务，并稳稳跑在腾讯云上。从这一篇开始进入正题——拆分之前，先把账算清楚。

很多团队对微服务的第一印象是“技术升级”，觉得用了就高级。我们的亲身经历恰恰相反：拆分本身不产生任何业务价值，它只是用一种确定的复杂度，去换掉另一种不确定的痛苦。所以这一篇的核心不是教你怎么拆，而是帮你判断“现在到底该不该拆”以及“拆的代价付不付得起”。

本章四节是这样安排的：

  • 1.1 从我们团队的真实数据出发，给出单体该拆的三个可量化征兆——发布互相阻塞、大促集中抖动、改动跨模块扩散，三中得二即可启动评估。
  • 1.2 讲拆分边界的划法：按业务域切，而不是按技术层切，顺带说我们踩过的循环依赖坑。
  • 1.3 算一笔团队的账：微服务带来的多环境、联调、on-call 与发布节奏变化，这些隐性成本往往比服务器贵得多。
  • 1.4 给出最终落地的技术选型对照表：Go 生态框架与腾讯云组件如何对齐，为什么选 CVM 而不是直接上容器。

如果你正处在“每逢大促就抖”的阶段，建议按顺序读完再动刀；如果只想看选型，可以先跳到 技术选型表，再回头看前三节。

延伸阅读