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

[Ketteiron]

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

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

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

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

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

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

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

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

[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 为什么在微服务盛行的年代一直是单体架构，团队只要选择适合自己的技术就行。

[iyaozhen]

分久必合合久必分

我说一个我们的场景，比如 a -> b -> c | b -> d. 实际流量 b -> c 占了 80%（这很常见），这样耗时优化大头都在这里了，即使是内网，b 到 c 涉及 rpc 的协议编码（耗 cpu ）、服务发现、网络传输等

如果能把 b 和 c 部署在一起，在延迟和资源利用率上都有不少的收益。但不是简单的 sidecar 部署方式

[Ketteiron]

@kdd0063 #47 牛头不对马嘴，我已经提前排除掉了 1%，还是堵不上你们这些 5 个 9 的嘴

[Yukineko]

不懂，只是看了一下线上 600 多个部署，想象不出来做成单体的样子

[lonenol]

我的暴论：微服务是云厂商为了多卖机器搞火的，现在降本是主流，可以关注下 Koupleless 或者类似的加购

[cloudzhou]

你这个言论，和上次某个 RoR 鼓吹者说开发可以回归单体服务一样，以为语言或者 AI 带来的加持能解决复杂度问题

然而并不是：
微服务带来的是，*物理*解耦依赖关系，按照现实组织拓扑进行划分服务
换句话说，每个服务有各自的资源，每个资源都有各自的 owner
把所有服务放到一起，最终各种飞线依赖，资源相互引用

@monkeyWie 正解！梳理好依赖关系的同时，按照单体服务开发，同时发布单独服务

[raydied]

微服务下也挺适合 ai 的，单个服务若抽象后的隔离性够好。

[LowBi]

哈哈哈 我目前小作坊 op 说的这些情况基本都有 而且开发人员少 一个人还得开发多个服务 并且还是敏捷式开发那一套 说实话 没感觉到微服务的便捷 反而开发上很累 基本就是被压榨 一个 RPC 崩了的话 跟这个 RPC 关联的接口确实会全崩

[misaka19000]

@Ketteiron #50 单体服务理解别人的业务也需要时间

而且 so 这种写少读多且业务相对简单的系统没有什么可参考性

[JoeDH]

@aheadlead #30 几百个微服务，你们的人员归属怎么划分的

[Ketteiron]

@HolmLoh #45
>小而自治的团队
有多小，少于 20 人我认为是在搞笑，20-50 人勉强能上。
微服务解耦的同时，也引入了对内对外的概念增加复杂度，如果一个人/团队长期在负责的业务上堆砌业务实现，这是合理的。对于小团队来说，这是不合理的，开发者可能要跨越多个自己打造的业务壁垒，属于内耗。
单体也能解耦，只是没法解得像微服务那么彻底。