为什么现在各路大厂纷纷放弃 微服务 而回归 单体架构？

分久必合，合久必分。

微服务主要是解决用户巨多（100w以上），流量巨大的情况的，它更复杂。

而且因为微服务也有很棘手的缺点。

最开始都是 monolith application ，我们国内常翻译其为 单体架构。

单体架构 是指 整个代码库 都包含在一个应用程序里。小项目一般都这样，本身也没多少代码嘛.....

都放到一个程序里，那必然开发、测试、部署都容易。

但程序一直开发迭代，架构会出现很多问题。即便采用了模块、结构，将其拆分的很细..... 依然止不住代码变得混乱。尤其是 bug，出现一点 bug ，就可能牵一发动全身！

于是就引入了 微服务，将单一的多功能大应用，拆分成几个小应用。每个小应用，只干它自己的事！

其中最显著的优点，就是 bug 隔离，书面化语言就是 故障隔离机制 。不会一个小 bug 把整个系统弄宕机了。

第二个优点，就是你各管各的，跟电路板电子一样，使用不同的技术栈、做各种乱七八糟的优化。尤其也提现在 扩容 上，应用跑通了，发小财了，扩容就容易了，只需要根据需要扩充某部分就行。

大厂都在回归

哎呀，最近两年 Basecamp、亚马逊、谷歌等大厂，还有国内的腾讯，很多目前都又回来考虑单体架构了。因为走的太远了。

因为他们原来想的是，微服务每个功能是独立的，改一处不影响别的，就好像我们软件在 github 和本地的源码一样，一个小功能是一个文件....

以及团队可以分离开，你管这儿，我管那儿，前端、后端、数据库、消息队列、运维.... 团队相互分离，又界限清晰。

但是！！！

没有那么美好。首先和写源码不一样，源码之间是几乎瞬间加载的，但是系统跑起来是有消息队列的，还有各种乱七八糟的协议，各种 GET POST ，乱的要死。

而且，也不像源代码那样，整整齐齐的躺在文件夹里，有清晰的文件目录，而是一个大沙盘，相互又耦合，混乱不堪！新人来了，光熟悉这些零七八的小部件，都得一个星期。

运维起来，更是恶心。和印度的电线杆一样，而且 bug 很难排查。而且有种去中心化的无力感。。。

虽然降低复杂性的基本方法，就是把复杂性隔离。"如果能把复杂性隔离在一个模块，不与其他模块互动，就达到了消除复杂性的目的。" 但是，目前对 微服务 的架构探索还太早，还做不到成熟的消除复杂的成熟程度。

渐渐的，梦就破裂了。

小说里有一个数学博士伊恩·马尔科姆（Ian Malcolm），他是混沌理论专家，专门研究复杂系统。作者通过他告诉读者：侏罗纪公园必定失败。原因很简单：复杂系统不可预测，也无法维护。

比如说？

比如说你要搞一个类似于 notion 一样的在线平台。

你需要有【身份网关】、【实时编辑】、【权限解析】、【文件储存】、【日志】。

每个，你都独立运行一个小组件。

但是，你一运行会发现，协议你得自己设计一个，复杂的 gRPC 接口或 Nats 消息队列。

而且文档的分布式事务很难。

如果你要更新功能，就加一个按钮，按下去，显示头像，这个得牵扯到 4 个团队！这一点非常恶心！如果是一个单体架构的话，啪叽一次性就 OK 了。

最恶习的是部署，单体部署特别快，但是一大堆，你的 CI/CD 流程肯定不是几分钟就搞定的，动辄十几分钟起步。各种平台的部署，都要收点租金，亚历山大！

为什么？

因为复杂，没有消失，只是转移了。

还不如单体架构。

单体架构起码结构清晰，新人友好，而且改代码直接。

而且单体架构，本身并不是主要为了解决复杂性出来的，而是为了解决超级大厂的动辄几百万并发，高流量问题的抗压的。

现在的 Rust 和 GO ，已经有很强悍的抗压能力了。

99％的初创项目死于没流量，而不是死于流量太大把服务器冲垮。我建议创业公司不要搞这些东西，直接买个鸡前后端分离，最多就做一下local first,如果需要回国就上个优化线路。等到真的全球化推广了，你可以最前端的那一小部分上一下Cloudflare。

如果你用户有 100w 级别，你可以试着搞微服务。（而且员工离职入职频次低，新人少）。其他请，单体就 OK 了。