微服务是不是个蠢主意？

微信公众号原文

亚马逊的Prime Video团队发表了一篇非常引人注目的案例研究[2] ，讲述了他们为什么放弃了微服务与Serverless架构而改用单体架构。这一举措让他们在运营成本上节省了惊人的 90%，还简化了系统复杂度，堪称一个巨大的胜利。

但除了赞扬他们的明智之举之外，我认为这里还有一个重要洞察适用于我们整个行业：

“我们最初设计的解决方案是：使用Serverless组件的分布式系统架构… 理论上这个架构可以让我们独立伸缩扩展每个服务组件。然而，我们使用某些组件的方式导致我们在大约5%的预期负载时，就遇到了硬性的伸缩限制。”

“理论上的” —— 这是对近年来在科技行业肆虐的微服务狂热做的精辟概括。现在纸上谈兵的理论终于有了真实世界的结论：在实践中，微服务的理念就像塞壬歌声一样诱惑着你，为系统添加毫无必要的复杂度，而 Serverless 只会让事情更糟糕。

这个故事最搞笑的地方是：亚马逊自己就是面向服务架构 / SOA 的最初典范与原始代言人。在微服务流行之前，这种组织模式还是很合理的：在一个疯狂的规模下，公司内部通信使用 API 调用的模式，是能吊打协调跨团队会议的模式的。

SOA 在亚马逊的规模下很有意义，没有任何一个团队能够知道或理解驾驶这么一艘巨无霸邮轮所需的方方面面，而让团队之间通过公开发布的 API 进行协作简直是神来之笔。

但正如很多“好主意”一样，这种模式在脱离了原本的场景用在其他地方后，就开始变得极为有害了：特别是塞进单一应用架构内部时 —— 而人们就是这么搞微服务的。

从很多层面上来说，微服务是一种僵尸架构，是一种顽强的思想病毒：从 J2EE 的黑暗时代（Remote Server Beans，有人听说过吗），一直到 WS-Deathstar[3] 死星式的胡言乱语，再到现在微服务与 Serverless 的形式，它一直在吞噬大脑，消磨人们的智力。

不过这第三波浪潮总算是到顶了，我在 2016 年就写过一首关于 “宏伟的单体应用[4]” 的赞歌。Kubernetes 背后的意见领袖高塔先生也在 2020年单体才是未来[5] 一文中表达过这一点：

“我们要打破单体应用，找到先前从未有过的工程纪律… 现在人们从编写垃圾代码变成打造垃圾平台与基础设施。

人们沉迷于这些与时髦术语绑定的热钱与炒作，因为微服务带来了大量的新开销，招聘机会与工作岗位，唯独对于解决他们的问题来说实际上并没有必要。“

没错，当你拥有一个连贯的单一团队与单体应用程序时，用网络调用和服务拆分取代方法调用与模块切分，在几乎所有情况下都是一个无比疯狂的想法。

我很高兴在记忆中已经是第三次击退这种僵尸狂潮一样的蠢主意了。但我们必须保持警惕，因为我们早晚还得继续这么干：有些山炮想法无论弄死多少次都会卷土重来。你能做的就是当它们借尸还魂的时候及时认出来，用文章霰弹枪给他喷个稀巴烂。

有效的复杂系统总是从简单的系统演化而来。反之亦然：从零设计的复杂系统没一个能有效工作的。

—— 约翰・加尔，Systemantics（1975）

本文作者 DHH， Ruby on Rails 作者，37signals CTO，译者冯若航。

原题为 Even Amazon can’t make sense of serverless or microservices[1] 。即《亚马逊自个都觉得微服务和Serverless扯淡了》