亚马逊“干掉”了微服务，成本直降 90％！

作者 | DAVID HEINEMEIER HANSSON

译者 | 弯月        责编 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

最近，亚马逊的 Prime Video 团队发布了一则案例研究，说他们决定放弃无服务器、微服务架构，并用单体取而代之——此举为他们节省了 90%（震惊！）的运营成本，并简化了系统。

除了为他们的明智之举点赞外，我认为整个行业都能从这个故事中学到一个重要的经验教训：

“我们最初的解决方案采用了无服务器组件的分布式系统……理论上，我们能够独立扩展每个服务组件。但是，我们使用某些组件的方式，导致服务在负荷仅为预期值的 5% 时就达到了瓶颈。”

他们的这番话总结了长期以来席卷科技行业的微服务热潮：理论上。

如今我们看到了所有这些理论的真实结果：很明显，在实践中，微服务是一种致命的诱惑，会为系统带来不必要的复杂性。而无服务器只会令情况进一步恶化。

这个故事的独特之处还在于，亚马逊是最早的一批采用面向服务架构的典型代表。面向服务架构远比微服务更合理，这是一种组织架构模式，用于处理公司内部的海量通信，远远优于定期的协调会议。

对于亚马逊的规模来说，采用 SOA 更合适，因为没有任何一个团队能掌握驾驶这样一支“超级油轮舰队”所需的一切。相比之下，团队之间的协调依赖于 API 是一种天才之举。

然而，与许多优秀的想法一样，这种模式一旦在原有的环境之外采用就会“变质”，甚至一旦被推入单一应用程序架构的内部，就会造成严重破坏——而这恰好就是我们使用微服务的方式。

从许多方面来看，微服务是一种早已入土的架构、一种拒绝死亡的知识传播“病菌”。从 J2EE 的黑暗时代开始，这种“病菌”就消耗了大量的人力物力，如今又蔓延到了微服务和无服务器。

但如今这第三波浪潮似乎达到了巅峰，Kube.NETes 背后的主要推动力量之一 Kelsey Hightower 在 2020 年曾表示：

“我们要打破单体服务，并以某种方式找到我们从未有过的工程原则……如今我们从编写糟糕的代码转变成了构建糟糕的基础设施。

因为基础设施带来了很多新的支出，因此我们需要更多人手……很多人沉迷于资本和营销带来的繁荣，而实际上这只是一种营销手段，无法解决根本问题。”

无论在何种情况下，将某个团队和应用程序中的方法调用和模块分离换成网络调用和服务分区，都是一种疯狂的举动。

我很高兴，我们能够在第三次热潮中击败这种可怕的僵尸袭击，但我们仍需保持警惕，不要重蹈覆辙，有些坏点子是无论杀多少次都死不了的。你所能做的是，看清楚它们何时死灰复燃，然后拿到武器，装好弹药，准备射击。