微服务vs单体架构的争论已经进行了十年。在2026年，对话已经成熟：最初的”微服务总是对的”正统观念已经被修正，问题现在更加细致入微。以下是事情实际上的状况。
为微服务辩护的理由
在2015到2020年推动采用的微服务论点：独立部署（每个服务可以在没有协调的情况下部署）；独立扩展（只扩展需要的服务）；技术自由（每个服务可以使用不同的编程语言或数据库）；团队自主（团队可以独立拥有和运营他们的服务，减少协调开销）；故障隔离（一个服务的失败不一定会导致所有服务崩溃）。这些是真实的好处。在Netflix、亚马逊和谷歌的规模——有数百名工程师、许多团队以及扩展需求大相径庭的服务——微服务已经并且仍然有意义。
模式出了什么问题
微服务炒作导致许多组织在还没达到其优势显现的规模时就采用了该模式。被低估的成本：分布式系统复杂性（网络调用失败、延迟叠加，你现在需要分布式追踪、服务网格和断路器）；运营开销（每个服务需要自己的CI/CD管道、监控、日志、告警、值班轮换）；分布式数据问题（单体架构中微不足道的事务在微服务中需要saga模式或两阶段提交——极其复杂）；网络延迟（单体架构中的函数调用需要微秒；网络调用需要毫秒——每个请求经过10到50次服务跳转时，这会叠加）；测试复杂性（跨20个服务的集成测试比测试单体架构难得多）。Sam Newman（《构建微服务》作者）和Martin Fowler都写了大量文章，讲述组织过早采用微服务并为复杂性付出高代价。
2026年的现实观点
诚实的立场：从模块化单体架构开始。一个具有清晰内部模块边界的结构良好的单体架构与”大泥球”单体架构不同。模块化单体架构可以：作为单个单元快速部署；轻松测试；由没有分布式系统专业知识的小团队运营；并在你达到有意义的规模时在以后提取为服务。迁移路径：当你有明确理由时提取服务——需要独立扩展的特定服务、一再被跨越的团队边界，或者会从不同技术中受益的系统部分。不要先发制人地提取服务。”单体架构很糟糕”的名声：通常来自将模块化单体架构与结构不良的代码混淆。一个具有清晰架构（明确领域边界、依赖倒置、良好测试覆盖率）的单体架构是许多永远不会达到适合微服务规模的公司的合理基础。当前共识（2026年）：微服务适合拥有许多团队和高规模服务的大型组织。对于初创公司和小团队，从模块化单体架构开始，当你有证据需要时再提取。”宏伟的单体架构”（David Heinemeier Hansson的术语）已经得到了恢复名誉。
