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]

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

[ebony0319]

你说有没有可能，既可以是单体，又可以按照模块立马变成微服务。

[Ketteiron]

@cccssss #19 没经历过。但是公司目前已经定下来了，已有的微服务不管，后续全部单体。如果业务扩张快，今年年底可能就是接近百人开发同一个项目。

[ala2008]

最近看了一个项目，全部代码都放一起，启动都要很久。。

[junkk]

之前待过用微服务的，确实感觉不好用，代码复杂程度翻番，本地开发调用来调用去很麻烦，要改配置，本地多起几个服务调试内存就给我打满了

说是解耦，谁谁谁负责哪几个服务，需求真来了还不是自己去别人负责的服务上开发，还有说减少依赖，其实没啥用，一个服务挂了，基本等于全挂，实际开发管你这啊那的，调用链路乱七八糟的很

我们是小厂，一个 app 拆分了十几个服务，开发就 2~4 个，你自己想吧搞这有啥用

[cccssss]

@Ketteiron 现在记录一下项目启动时间，等年底时候再统计一下项目启动时间。到时候辛苦踢我一脚，感恩

[joshuacavell]

最后绕到 AI 编程我是万万没想到的.

[jydeng]

AI 都能写，让 AI 写

[wx497657341]

@hangszhang 无比认同

[lujiaxing]

这东西就是个投入产出比的问题.
招一个会微服务架构的开发需要多少钱? 我们这儿成都, 招聘一个熟悉微服务架构而且真正有经验的 java 开发工程师, 基本上两万起步. 一般要 2.5W 左右. 其他语言的也差不多. 而没有微服务技能要求的只要 1.5W 左右. 更何况有时候很多自称熟悉微服务架构的都是纸面上的熟悉. 一问啥都知道, 一开始上手做事啥啥都不知道. 上线之后出问题的概率很大的.

另一方面, 大多数项目, 除了天猫商城 京东商城 这种体量规模的产品之外, 大部分项目都不需要考虑什么高并发高可用的问题. 国内大部分互联网公司做的那些玩意都是一套系统平均一天只有几万个 UV 的东西, 弄个好一点儿的服务器啥都解决了.

但是如果用上微服务架构, 那么意味着整个开发团队的人数将会急剧膨胀, 要知道微服务起码要小一百号人才玩儿的转的. 这么庞大的开发团队, 每个人的工资都还不低, 那这个人力成本有没有考虑过? 如果公司本身业务规模就在膨胀的状态, 客户越来越多, 那公司姑且还能愿意花这份冤大头钱去给一帮开发拿自己的业务练手.

但是从新冠疫情开始到现在是个什么情况? 经济持续恶化. 很多公司的业务都已经面临无以为继的状态. 公司为什么还要维持这种庞大的编制? 做慈善么? 而且既然业务的规模都已经没有这么大了, 微服务架构所带来的那些优势自然也就没意义了. 既然用户数量已经变少了, 高并发也就无从谈起. 那为什么不改用成本相对更低, 但是也能达到同样效果的单体架构呢?

而且微服务除了人力成本, 还有各种其他成本. 消息队列(Rabbit, Kafka), MES, 可观测 (Prometheus, Grafana ) 等各种中间件成本都不低.

所以可见的未来, 经济持续下行的情况下, 微服务一定是只集中在少数头部互联网企业的东西, 中小型企业用的一定会越来越少. 前几年有机会入职大厂上车微服务的开发大概是赚到了. 后面一方面大厂门槛越来越高, 另一方面即便是大厂, 用微服务的可能性也在越来越小. 小厂更不会用. 后面的人想学微服务, 恐怕已经没机会了.

[aheadlead]

我感觉我们这里实践的微服务是几十个巨无霸几千上万核的大单体，加上几百个微服务

[lujiaxing]

@junkk 说明你们的业务不正交.

意思就是每一块业务都是有明确清晰的业务边界的. 不互相影响.
但是这在一些品类的系统中显然是天方夜谭. 业务之间的互相影响如蜘蛛网一般复杂.

[Ketteiron]

@joshuacavell #26 因为 AI 编程确实影响了架构选型。这点还是让时间来验证吧。

[monkeyWie]

应该是单仓库 monorepo + 多服务部署才是最优解

[midsolo]

@root71370 有的，我上家做跨境电商的，整个项目共用了 Java 、Python 、Go 3 种编程语言，用 GRPC 和 Kafka 进行服务间的通信，一共 80 多个微服务模块，包括订单、商品、支付、会员、营销、短链、推送、对账、风控、规则引擎、网关、认证授权、实时流计算、BI 可视化..... 开发人员就超过了 100 人。

[nunterr]

OP 为啥不让公司花点小钱买个大厂的服务呢，这样既能使用微服务，也不用操心维护，而且微服务的优点也能最大化

[lvlongxiang199]

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

这为啥会是缺点 ? 一个函数你不调用它, 会额外消耗 cpu, 内存, IO ? 像是 db 连接, 可以设置 `maxIdleTime`

[co2fe]

搞软件工程不是做二极管，即使被微服务伤害过，也不该投鼠忌器。平衡一下嘛，为什么要在纯单体和纯微服务之间做选择题呢？

[Ketteiron]

@nunterr 微服务是买不了的。大厂卖的不是微服务，而是成熟的各种云产品，他们能组成、补充微服务架构。这些产品用在单体上也一样。

[HolmLoh]

@junkk #24
经典一蹴而就的微服务单体架构，小厂 maven 分几个模块撸出来就行了，我以前也进去一家小厂差不多一个鸟样，面对的难题是基础设施不完善，没有时间和精力去梳理业务边界，而带来的好处对小厂来讲根本没有任何意义。
在活下来才是最大的难题之下，不如多花心思把产品快速稳定上线

[Ketteiron]

@lvlongxiang199 不同时间，服务间的开销与负载会随时变化，例如商场打折，此时订单服务负载突然升高，微服务可以单独给订单模块加码，防止崩掉。单体只能多开几个机子，与订单无关的代码会浪费内存，部署时间会长很多。

[xx6412223]

微服务技术上不存在特别大的优越性，还会引来技术复杂性
能看到的摸得到的就是带来的**管理**成本优势，


那选择的时候，就看这个项目的阻碍是技术还是管理。
一个项目就 10 个人，上微服务就拿锤子找钉子
一个项目几十人甚至上百人，那就必须上

[junkk]

@HolmLoh #39 我也不知道领导咋想的，用的 k8s 集群部署，新起一个项目，先上十几二十来台服务器再说。 老项目好像一百多台服务器，我们是 PHP ，fpm 和队列服务器还要单独区分，有的队列需要更多消费者的，比一般的 web 服务器还多

我们活跃用户我估算下来才 10w 左右啊，不懂怎么搞的这么大阵仗

[junkk]

写过微服务以后再去写单体，就发现舒服太多了，起码可以方便地知道这个方法要啥参数，具体实现，复杂度骤降

[lvlongxiang199]

@Ketteiron 会额外占多少内存, 有实际 benchmark 吗 ? 内存占用的绝对大头是在堆（ Heap ）上，而不是代码段（ Code Segment ）。

[HolmLoh]

此事在《微服务架构设计模式》已有记载，我不否认你说的一些缺点，但你说的没有解耦只能说是你们团队有问题，微服务的关键作用就是为了解耦，维持小而自治的团队能降低每个人员的包袱，从而提高持续交付的能力，解耦都做不到还是别搞微服务了。

[mightybruce]

这都 2025 年， 谈这些我还以为活在 10 年前， 不少云是提供微服务治理的基础设施， 要单体要微服务这东西也能讨论， 实在是技术眼光太窄了。

[kdd0063]

槽点一大堆，懒得吐槽。估计你没见过玩多云，单云多 AZ ，跨双活专线跨云 K8 和有状态组构成蓝绿的玩法。你没见过的 Availability 严肃高要求，不代表真的不存在，你没见过而已。

[misaka19000]

楼主技术视野过于狭窄

微服务为什么会诞生，是因为它解决了一些之前难以解决的问题。当服务复杂到一定程度，代码的复杂程度会将维护成本无限提高，这时候需要微服务来进行解耦了。不是亲身经历项目几乎无法维护的场景，会很难理解。

[Ketteiron]

@lujiaxing 以前一个微服务可能 100 人负责，现在剩 50 人，明年可能 25 人，要维护这么一个不可预测的巨大黑盒过于困难，微服务的解耦是用人数堆出来的，人不够用就相当酸爽了。
单体在后期维护上会稍微友好些，单体项目开发者将解耦的时间用于理解其他业务，即使只剩 10 人甚至 1 人，也能勉强保证项目不会出 bug ，能够有足够的人力进行其他业务尝试，不至于被微服务拖着等死。

[Ketteiron]

@misaka19000 #48 一个技术为何会诞生当然有必要的理由。
微服务可以让一个模块的相关开发者只需专注自己的业务，无需关心上下游的业务逻辑，这就叫解耦。
而现实是大量使用微服务的公司开始缩减人员，无法维持相关的人负责相关业务，必须相关的人负责不相关的业务，原本解耦的逻辑又得花费两倍的努力重新理解。
微服务是一项技术，但不是必须的技术，否则无法解释 StackOverflo 为什么在微服务盛行的年代一直是单体架构，团队只要选择适合自己的技术就行。