2025 年，我对"单体 vs 微服务"的预测

[Ketteiron]

1. 单体不是单机，不是单模块
2. 负载均衡、熔断、降级在微服务出世前早存在了
3. 微服务和 MQ 、Redis 顶多只有半毛钱关系，微服务怎么用单体就怎么用

微服务尝试解决什么问题？
保障多个 p0 服务不会一崩全崩。然而实际上大多数微服务就是一崩全崩。
将服务独立，减少耦合。如果不同服务由不同部门/人员负责这是好的，实际上大多数使用情况是服务解耦人没有解耦。

微服务实际只解决了三个问题：
1. 服务独立伸缩
2. 服务独立升级
3. 管理大量开发人员

单体无法单独伸缩其中一个服务，只能全部一起水平扩容，这是确实存在的缺点，但 99%的项目并不需要该特性，基础建设很贵，机器很便宜。

单体无法单独升级一个服务，但这特性只是理论上听起来不错，微服务中的一个服务依赖其他服务，实际使用中很难单独只升级一个，需要上下游一起升级。

微服务不是管理代码的架构，而是管理开发人员的架构。解耦服务没有实际上的收益与意义，解耦复杂的社会关系才是其精华所在。然而现实中多少项目服务比人还多呢。

复杂度不会消失只会转移，微服务将复杂度转移到基础建设中，而大多数公司无法消化。微服务有成本，首先代码量就先翻个倍，除此之外还有更多隐形成本。

现在是泡沫破裂的 2025 年，AI 辅助编程让开发人员效率极大提升，往后应该是单体重登王座的时代。

[povsister]

批判性的点进来，原来是小公司用微服务啊。那没事了

[Ketteiron]

@povsister 就算是大公司，也应该只在需要用的项目上使用。如果一个项目长期维护人员低于 100 ，我个人认为没有使用微服务的必要。

[darkengine]

"AI 辅助编程让开发人员效率极大提升，往后应该是单体重登王座的时代。" 这里面有什么逻辑关系吗？

[xuanbg]

1 、微服务不是银弹，不能包治百病
2 、微服务是有门槛的，也不是什么团队都能 hold 得住的
3 、微服务就是比单体先进，任何方面都更先进。问题在于你能不能搞得定微服务，搞不定就别玩

[root71370]

一个项目要 100 个人维护？啥项目啊要这么多人

[xuanbg]

你该不该上微服务，不取决于你的业务有多复杂，也不取决于你的团队规模。它只取决于你有没有具备玩转微服务的能力，能不能搞好微服务。

你能玩得转微服务，那即使只有一个人，也能上微服务。没这个能力，哪怕是万人团队，也不要去碰微服务，硬上只能给你带来无尽的麻烦，而且规模越大麻烦就越多。

[mightybruce]

历史还能倒退？
单体和微服务之间没有任何矛盾，都是什么的业务选择什么样的架构。

再提一点，对于规模在不断扩展上升的业务，微服务极大的降低了基础设施成本，用一些垃圾普通的 x86 服务器就能干以前只有小型机，高端 EMC 存储才能干的事情。

[Ketteiron]

@darkengine 微服务会流行是因为大厂无法管理疯狂扩张的团队，而现在已经不需要管理了，一人顶两人甚至三人，单体完全能 hold 住。当然有需要的可以继续上。

[artiga033]

>实际上大多数微服务就是一崩全崩
想象不到，如果这样说明一开始设计就有问题，用什么架构都是白搭

> 微服务中的一个服务依赖其他服务，实际使用中很难单独只升级一个，需要上下游一起升级
不管是什么起码得做到三个版本内的兼容性吧？那怎么不说单体也还得前后端一起升级呢，大家都去用 php 吧

> 微服务不是管理代码的架构，而是管理开发人员的架构
我认为既是又是，用不用微服务纯粹看项目情景，和有多少开发者关系不大。借用你提 ai 的观点，那我有 100 个 agent 模拟 100 个开发者，那是不是分别维护 100 个微服务更好？

除此之外关于微服务带来大量额外的成本和负担的观点我完全同意，并且我同样认为小公司/小项目能避免微服务就尽量避免。但是我看不到当前经济形势和 LLM 的发展会对项目架构的选择有任何影响。

[Ketteiron]

@xuanbg 你说得对，就算一个请求在微服务里弹十几次，它依然是先进的，哈哈。

[xuanbg]

@Ketteiron “一个请求在微服务里弹十几次”。你这个是设计问题，你是怎么就敢把锅扣在模式的头上的？？？

[chendy]

1. 服务独立伸缩
2. 服务独立升级
3. 管理大量开发人员

三筛选条件一加，98%的软件项目就被过滤掉了

[hoopz]

我的体会和楼主一样，我是小公司。。。

[dcsuibian]

如果微服务往单体收敛，云原生的需求会减少，另外对资源的占用是不是就相对不那么突出。成熟的后台类库和框架会重新成为技术选型的主要因素。进而导致 Spring Boot 赢麻了。完美

[Ketteiron]

@artiga033 1. 我想表达的是，最核心的模块挂了，那其余模块基本也算不可用，哪怕其余模块还是能正常 curd ，开发人员挨的喷不会少。恢复核心业务，无论是微服务还是单体，难度和流程都是一样的。
2. 我想表达的是，它无法带来预想中的简单与快捷。
我承认好处确实是有的。

3. 如果 Agent 能做到模拟开发者，那确实维护 100 个微服务更好。

4. 当下形式很明显，大量裁员与失业，除了少量扩张中的业务，基本都在收缩人员。数十人维护相同体量的微服务很困难，换成单体服务却非常轻松。

我觉得有点应该是共识，单体 monorepo 的维护难度和工作量比相同体量的微服务少很多。

[kassadin]

历史到不会后退，但小团队和微服务确实没什么关系了，除了一丝丝的解耦，其他所有工作都是随项目数量成倍增加的

[hangszhang]

组织架构决定系统架构

[Ketteiron]

@xuanbg 夸张说法，虽然业务中确实发现过一个请求弹了 12 次，但不管弹几次，就是无法实现单体的一次，内网延迟是真实存在的，响应速度就是比单体慢。微服务只是在一些场景是好的，完全先进过于绝对，至少性能损耗我个人不认。

[cccssss]

一个单体项目 99 个人维护，你确定你经历过？ AI 盛行，一个 99 个人维护的单体项目代码量多大，部署一次要多久有概念么

[crysislinux]

单体服务方便事务的优势太大了