来自 DHH（@dhh）的推文线程

微服务是软件行业最成功的骗局。它让小型团队误以为自己在“大展宏图”，却暗中削弱了他们的行动能力。它利用人们的不安全感来迎合他们的雄心壮志：如果你没有运行一系列服务，你还能算是一家真正的公司吗？先不说这种架构最初是为了应对全球规模的组织功能障碍而发明的。现在，它却被强加给那些仍然共用一个Slack频道和一张午餐桌的团队。 小型团队依靠共享上下文协同运作，这是他们的制胜法宝。每个人都能进行端到端的推理，每个人都可以修改任何内容。微服务一出现就彻底摧毁了这种优势。它们用分布式的无知取代了共享的理解。没有人再拥有整体，每个人都只拥有一个分片。系统不再是团队主动理解的，而是团队被动接受的。这并非技术上的进步，而是能力的丧失。 接下来就是运维闹剧。每个服务都需要自己的流水线、密钥、警报、指标、仪表盘、权限、备份，以及一系列繁琐的维护流程。你不再是“部署”，而是同步整个集群。一个 bug 现在需要对多个服务进行全面剖析。功能发布变成了一场跨越你毫无理由地人为划定的边界的协调行动。你没有简化你的系统，而是把它彻底摧毁，然后把残骸美其名曰“架构”。 微服务架构也把无能锁在了琥珀里。你被迫在还没完全理解自身业务之前就定义 API。猜测变成了契约。糟糕的想法变成了永久依赖。每一个早期的错误都会像癌细胞一样扩散开来。在单体架构中，错误的想法可以通过重构来纠正。但在微服务架构中，错误的想法会变成基础设施。你不仅会后悔——你还得托管它、管理版本、监控它。 认为单体架构无法扩展的说法是现代工程领域最愚蠢的谎言之一。真正无法扩展的是混乱，是流程的拙劣模仿，是假装自己是 Netflix 却交付一个华而不实的 CRUD 应用。只要团队拥有纪律、测试和克制，单体架构就能很好地扩展。但克制并不时髦，而枯燥乏味的内容也无法在会议上发表。 对于小型团队来说，微服务并非技术上的错误，而是理念上的失败。它大声宣告着团队不相信自己能够理解自身的系统。它用协议取代了责任，用中间件取代了发展动力。你得到的不是“面向未来”，而是永久的拖累。等到你最终达到足以支撑这种“闹剧”的规模时，你的速度、清晰度和产品直觉早已荡然无存。