知识卡片
单体系统的真正短板是自治隔离能力而非可拆分能力
内容
把单体等同于”铁板一块、不可拆分”是常见误解：单体系统纵向可以做分层架构，横向 也可以按技术/功能/职责拆成多个JAR/WAR/DLL模块，甚至能在负载均衡器后部署多个 副本实现水平扩展——这些”可拆分”维度上单体并不逊色。单体真正的缺陷在拆分之后 的自治与隔离能力：所有代码共享同一进程，一处内存泄漏或死循环会拖垮整个程序， 无法像”停掉半个进程、重启四分之一”那样单独更新某一部分，也难以让不同模块使用 不同技术栈。这个缺陷在系统规模小时无关紧要（就像三口之家没必要划分部门），但 规模变大后代价急剧上升。作者认为，压垮单体的真正原因不是这些工程细节，而是 单体架构很难兼容”允许出错、快速重生”的Phoenix特性——它的底层假设是”每个部件 都应该尽量不出错”，而不是”承认出错必然、靠架构层面的隔离和重建来兜底”，后者 才是微服务能够挑战并取代单体的根本底气。
参考来源
- 位置：《凤凰架构：构建可靠的大型分布式系统》第1章"服务架构演进史"1.2节
"单体系统时代"（源文件：_epub-src对应OEBPS/Text/chapter6.xhtml）
- 结论依据：原文先逐条反驳"单体不可拆分"的误解（纵向分层、横向模块化、水平
扩展均可行），再指出单体真正的缺陷在拆分之后的自治与隔离能力缺失（故障
全局传播、无法单独更新、难技术异构），最后点明"很难兼容Phoenix特性"才是
微服务取代单体的根本原因，直接支撑本卡片结论。
- 原始内容：单体系统的真正缺陷不在如何拆分，而在拆分之后的自治与隔离能力上……
笔者认为最重要的原因是：单体系统很难兼容"Phoenix"的特性……正是随着软件架构
演进，构建可靠系统的观念从"追求尽量不出错"到正视"出错是必然"的转变，才是
微服务架构得以挑战并逐步取代单体架构的底气所在。