第1章 术前评估：单体为什么撑不住

第1章 术前评估：单体为什么撑不住

本章跟着一台病人走——某电商订单系统，一个运行了五年、几千个类、二十多个人改同一份代码的巨型单体。我们用外科医生的办法先做检查：它哪里疼、什么指标超标、到底该切还是该养。把"要不要上微服务"这个常被拍脑袋的问题，变成一个可拍板的成本账。

很多团队做微服务的开头不是"我们想清楚了"，而是"线上又出事了"：一个订单模块改了一行，把用户模块一起带崩；双十一流量一冲，整台机器都打摆子；新人进来改代码要猜三个月。这些症状指向同一个病灶——耦合。本章不做任何架构决策，只做一件事：把病灶摊开看清楚。

一条主线

我们的病人是一台订单单体，它有三个足以致命的"慢性病"：代码库肿到没人敢合并、个别模块发热却只能整机扩容、任一模块炸雷全应用陪葬。这条主线将贯穿本章——每个症状对应一个"要不要动刀"的判断题。

为什么把这一章放在最前

很多人学微服务是从"装一个 Demo、一切为二"开始的，结果装完发现架子上多了几个服务、问题一个没少。原因很简单：拆之前没做诊断。微服务不是目的，把"耦合"这个真正的病灶拆散才是。所以本教程把"术前评估"放在第一站——先回答要不要拆、拆哪、拆的价值够不够抵掉代价，再谈任何工具和框架。这一步做对了,后面每台手术都踏实。

评估里还有一层很容易被低估：它同时是一面照妖镜。很多公司其实不需要微服务，需要的是把单体内部边界理清楚——不拆也能救。本章的结论会帮你把这两条路分开，避免"为了微服务而微服务"。

本章一条主线

把我们这章反复出现的"症状一/二/三"再收拢成一张可复述的推导图：订单单体热（变更频率）、紧（耦合度）、脆（故障半径）——三个词分别对应三个指标，"该切还是该养"的答案就藏在它们的组合里。后面每一章都会引用这"三个病人症状"，它是贯穿全册的骨架。

沿途站点

1.1 单体病灶与诊断——教你怎么"号脉"：从耦合度、变更频率、故障半径三个维度量化判断单体是否病变，并给出一张可勾选的体检清单。

1.2 收益与代价全景对照——微服务不是白捡的好处。这一站把"独立伸缩、故障隔离、技术自由"的收益，和"分布式事务、网络延迟、运维爆炸"的代价做成同一张对照表，谁要为谁买单说清楚。

1.3 术式的演化史：从大爆炸到微服务——这一站回放微服务是怎么"发明"的：从大爆炸重写、绞杀者模式（Strangler Fig）一路演进到今天的渐进式拆分，论证一个结论——手术是分片的，不是一锤子的。

拐点与结论

本章最大的认知转折早就该发生：单体的锅不全是单体架构的错，是"边界没守住"的错。很多单体其实还能再扛几年，缺的只是纪律；而很多一路小跑的微服务，反而因为边界乱画变成了分布式的巨型单体。所以本章的落点是：先诊断，再决定拆不拆，绝不为了技术潮流而动刀。

读完你应该

• 能从耦合度、变更频率、故障半径三个角度给单体做一次量化"体检"
• 能说出微服务每一条收益背后对应的具体代价，并能判断代价是否可承受
• 能讲清"大爆炸重写"为什么是高危手术、"绞杀者模式"为什么更稳妥
• 手绘出单体与微服务的两种部署单元差异图
• 判断自己团队现在是"该拆""不该拆"还是"拆了但拆错"

下一章的接力

什么时候该拆，这一章给了判断；从哪一刀开始切，交给第 2 章。那里我们会拿到手术刀——限界上下文会把这块巨石切成一个个能独立供血的器官，而康威定律会告诉我们刀线其实早就画在组织架构图上。动刀之前，别忘了先看懂病人。