总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 分布式实验室 levelup.gitconnected.com/martin-fowler-was-right-microservices-suck-573bbf09a0fd 「李鹏」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

Andrew Hunt 和 David Thomas 的《程序员修炼之道：从小工到专家》无疑是软件开发者们最喜爱的书籍之一。但是，我有时会想，到底有多少软件工程师真正阅读过这本书呢？

尽管这本书并没有详细阐述微服务和单体架构的方方面面，但它也提供了足够多的信息 —— 甚至可以说是全部信息 —— 帮助我们做出最好的，或者说是最务实的决定，来构建软件。仅仅是目录本身就值得称赞！但是，即使过去了 25 年，这个行业似乎仍未领会到其最基本的教诲 —— 那就是，根据实际情况选择合适的工具。

另一个大名鼎鼎的人物，就是 Martin Fowler，他因遵循 “根据实际情况选择合适的工具” 这一理念而崭露头角的。任何熟悉持续重构这一概念的人，也很可能听过 Martin Fowler 的名字。他甚至写了一本专门讲述这个主题的书。

但如果你不想读或者买不起，这里有一个极简的版本：“始终保持重构。如果你接触到代码，并且有能力改进它，那就去改进，但绝不提前优化。” 这本书的精髓被浓缩为这句话。在这本书里，他不仅分享了他对重构的见解，还讨论了许多其他现代软件开发的主题，比如架构，更具体地说，单体架构和微服务。

相反，从单体开始，使它保持模块化，一旦单体成为问题时把它分解成微服务。

——martinfowler.com

在 2023 年初，React 的开发人员和维护人员的行为让开发者们大吃一惊，现在又出现在了亚马逊 Prime Video 的开发者身上，最近他们发表了一篇文章，讨论了从微服务转向单体架构的过程（❗如果你还没读过，为了理解背景，请阅读❗）。这引发了很大的讨论，因为考虑到亚马逊还拥有 AWS，在其上建立的无服务器和微服务架构远比我们都应该接受的多 —— 但那是另一个故事了。

那么，到底发生什么事情了呢？好吧，想象一下。悬崖边上的第一只羊跳了下去，然后其他羊都跟着跳了下去。但是后面的羊都没注意到，第一只羊 —— 亚马逊 —— 是穿着降落伞跳的。后面的羊都没有注意到。不幸的是，这种情况并不少见，而这也是我多年来一直在反对的。

仅仅因为大型科技公司正在采用一些新的架构、工具或库，并不意味着它对每个人，包括推出它的那个公司，都是可行的。还记得谷歌的 Angular.js 吗？就是这个道理……

亚马逊 Prime Video 的故事与此非常非常相似。推动了云服务发展的这家公司的部分部门，已经意识到了 Martin Fowler 在 2014 年非常恰当地指出的一个事实 —— 这种模式可能并不适用，而且还没有足够的证据来证明它会有效。当然，这并不意味着亚马逊就不应该尝试这种架构，或者不应该构建支持这种架构的 AWS 产品。Martin 本人也同意，这种尝试是有价值的。但是，尝试与采纳是有很大差异的，在产生实际效果之前的盲目尝试和盲目采纳差异更大。

尽管对许多人来说，亚马逊开发者决定放弃部分微服务，转而选择单体架构的决定可能令人震惊，但这其实一点都不出人意料。微服务是否能成功的可能性一直是五五开。

与那些永远看好未来、天真乐观的人不一样，软件开发并非非黑即白，无论它最终如何编译成 0 和 1。这就是为什么我们需要回归到由 Andrew Hunt 和 David Thomas 在《程序员修炼之道：从小工到专家》中阐述的基本原则，这是每一个紧随亚马逊步伐，一头扎向同样深渊的人都应该做的。

亚马逊 Prime Video 团队的决定并不应被视为一种普遍的方案，尽管我确信会有许多人走进办公室，或者登录 Slack，准备召开紧急的工程全员会议，提出一个计划，要么恢复原状，要么将他们的微服务 “单体化”。我相信我不必须这么说，但请你不要这样做。如果你最终运行的微服务是从解决实际问题的单体架构中剥离出来的，那么你显然已经做出了正确的选择，推翻这个决定至少不会解决任何问题。

另一方面，如果你从一开始就由于像 “其他人都在这么做” 这样的轻率理由而采用微服务，那么你可能需要坐下来对你的架构进行一次真正的成本效益分析，甚至可能需要与亚马逊 Prime Video 的案例进行对比。他们勇敢地承认微服务是错误的选择，这至少表明这个决定并非出于市场炒作。你的分析结果可能会证明，采用单体架构所解决的问题少于其带来的问题和投入，在这种情况下，你应当坚持你现有的选择。

Martin Fowler 和我都赞同一个简单的事实，那就是

我们在讨论这个话题，对前端开发也同样适用。微前端是一种可能的解决复杂前端问题的方案，但这并不一定意味着它是每个复杂前端的正确解决方案。

这篇文章就是要说明，不要盲目追随大型科技公司。务实的编程依然占主导地位，根据实际情况选择合适的工具永远是最佳建议。

文章目录