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

[Ketteiron]

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

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

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

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

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

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

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

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

[lbbdefy]

我们组，3 个后端。一个项目需要一次需要部署 20 个微服务，其中一部分是功能，一部分是业务，一部分是基础服务。有的 java 写的，有的 python 写的，有 go 写的，我觉得挺好。做的都是本地部署的活，到一个地方使用 K8S 写好的脚本一键部署，不需要修改的服务稳定运行几年都不需要动它，只需要修改常用的几个服务。
而且不存在人员不解耦，我就没看过其他人写的工程，并不影响开发我的服务功能，多人之间对话只有"接口"。
"服务升级很难只升级一个"，那说明你们架构师水平不行，接口兼容都整不明白。
"微服务有成本，首先代码量就先翻个倍", 代码量翻倍的结论从何而来？公共组件放 maven ，没有遇到过很多重复代码的问题，而且现在跨进程的框架越来越多，多服务开发和单服务开发体验本身就相差越来越小了。多服务开发甚至还有跨语言优势。
"微服务尝试解决什么问题？
保障多个 p0 服务不会一崩全崩。然而实际上大多数微服务就是一崩全崩。" 保障业务持续运行不是高可用范畴该考虑的吗，这是微服务要解决的问题？退一万步说，确实有很多微服务一崩全崩，那不也有很多微服务崩了并不影响其他服务的时候？单服务崩了那才是百分百一崩全崩。
多服务和单服务从来不是二极管，也不是因团队大小决定。根据合适的场景选择合适的技术才是正解。

[ze00ro]

我觉得恰恰相反, 各种模块化, 各种碎片化我觉得, AI 自己调用各种纳米服务

[wuling]

需求或者说改变是永恒的，所以要想办法降低改变带来的影响，也就是做拆分。避免来一个需求，要梳理一整套代码来决定应该改哪，避免改一行代码要把整个系统测一遍，把整个系统重新部署，避免某一个接口的流量变化要把整个系统扩容。另外一个点就是关注分离了。也对应描述中说的服务独立部署和升级，以及一大堆开发人员。

具体怎么拆呢。一个系统里面，有些部分是频繁变化的，有些是很少变化的，有些部分经常会因为同一个原因（同一类需求）而一起变，而有些则不是。因此需要将经常因同一个原因变化的放到一起，从小往大讲就是放成一个函数，一个类，一个模块，一个微服务，或者一个业务域。这样一来，经常变的模块就自己升级自己测试，不会影响到不变的部分。

依赖关系上也是一样，首先要单向依赖，其次是经常变化的模块，要依赖不怎么变的部分，来降低变化带来的影响。

微服务其实就是服务级别的拆分，开发、测试、运维、维护会分得较为彻底。当然实际上还是要遵守上面的原则，如果拆分得不合理或者依赖关系不合理，影响面并没有减少，来一个需求还是要改一大堆服务梳理一大堆东西，那就是另一回事了

[zhengfan2016]

想多了，单体服务再配合 ai ，一个代码文件几千甚至几万行你 review 的过来，肯定是拆细好维护，就算 ai 再怎么乱改影响范围也是局限那一个微服务

[lujiaxing]

@wuling 其实现在很多所谓的微服务, 如果深究都不能算微服务. 最多算分布式架构. 微服务得是拆的非常细的才叫微服务.

[Ketteiron]

@zhengfan2016 我们正在运行的单体项目，总代码量好像是 20w 行，最长的一个接口总实现不会超过 600 行，每个接口平均保持在 200 行，比较复杂的 excel/pdf/图像处理等逻辑不算在内。我不知道你是如何看待单体项目的，外观上它长得跟微服务差不多，微服务怎么拆分，单体也怎么拆分，只是无法更细致的定义对内对外与解耦。

[darkengine]

@Ketteiron 我的体会是因为选择了微服务这条路，才会出现小团队，小团队是果。

[zhengfan2016]

@Ketteiron #66 那你们公司对代码质量的把控还可以。我司代码基本上几千行是常态，python 一个 class 无所不包。还是领导用 ai 一键生成的，生成完就丢给底下安卓人在这个基础上接着拉，上面都完全不管代码质量了，同事大部分也是能用 ai 糊弄就用 ai 。我是觉得这种代码质量低的项目，还搞单体，更难维护，起码拆出去代码可读性的下限会高一些

[Ketteiron]

@iyaozhen #51 有些不用分，走错路的无法回头。
以我的观点，大概只有 1-2% 的项目有资格上微服务并确实享受益处。
这些项目要满足：
1. 能接受微服务带来的性能损耗和请求延时
2. 能以正确的方式理清业务优雅地拆分服务
3. 大量跨部门/跨公司的成员，存在较高的沟通成本+管理成本
4. 需要 5 个 9 甚至更高的可用性

[cctv6]

我相信单体应用会变得流行，但是绝对不会是因为 AI 辅助编程的功劳。

只有同时满足 高并发 高增长 和 复杂业务 三点才有上微服务的必要，但是现在大部分能同时满足这三点的行业基本已经被大公司或者独角兽垄断了。再加上现在这互联网行情，可以预见的未来，似乎也没有什么新的赛道出现了，

能做的，还在做的，基本上只剩下各种定制开发和各种管理系统了，或者其他用户量很少的独立系统，这些场景大多都没有上微服务的必要。单体应用更适合快速开发和部署维护。

[Ketteiron]

@lbbdefy #61 我觉得你说的那些东西可能不叫微服务，叫多服务。
>代码量翻倍的结论从何而来
每一个真正意义上的微服务，有单独数据库，单独配置文件，单独对外接口，单独对内业务实现，微服务为了解耦必定存在大量相似代码且无法消除，再加上微服务生态带来的大量组件与配置，与单体相比平均代码量提升一倍，可能还说少了。
>接口兼容都整不明白
微服务无法实现自给自足，对一个需要功能变更的微服务自身来说，仅修改自身就能完成升级的概率是很低的，它很可能需要一个或多个上游根据它的需求进行升级，而下游可能也需要这个功能，一升一大串是比较常见的场景。

[lologame]

巨型单体服务根本不适合高速迭代的项目，首先你根本不可能做到想发布就发布，基本只能搞固定窗口上车发布的模式。另外每次部署都需要做全量回归，一次发布可能涉及大量变更点且都在同一个仓库风险很高。其次启动时间巨慢开发效率低下。

[cubecube]

微服务的最大优势在于架构上物理上的功能解耦和边界划分，被动收敛到功能域的抽象和独立演进
单体很难持续保障上面的要求，在需要大规模合作的项目里面，持续集成都可能成为问题

[soulflysimple123]

我就说一句，某些小公司用微服务根本处理不好分布式事务

[Ketteiron]

@cctv6 #70 对我个人来说，决定换成单体时 AI 因素确实占了挺大的比重。
微服务在人够用的时候还是有好处，屏蔽了很多耦合逻辑的心智负担，它强迫每个人一点一点组织出需要的数据，整体上是线性逻辑。
而单体需要像蜘蛛织网那样，考虑其他业务因素，考虑复用可能性，考虑如何组织代码，如何对相邻业务不清晰边缘进行重构，当业务复杂起来后可读性会越来越低，重构难度也会越来越大，难以划分开发人员职责边界。
如果在几年前，引导这样的项目确实很难，但我在深度使用 AI 辅助编写个人项目后改变了这个观点。
Agent 是世上最强大的静态代码分析器，是会思考的 linter ，是能胜任这个场合的助手，我们要做的是如何帮助它更好地理解我们的项目，反过来它就会了如指掌地为程序员提供错误率较低的解决方案和代码实现，我通过编写 MCP 服务实现了这一点，应该很多公司也在这么做。
我自己的实现是让 AI 顺着代码文件的依赖引用总结思考，最终生成一个包含依赖的摘要，自动在流水线上完成，每次合并都会更新相关改动的文件，而 Agent 就可以通过 MCP 服务获得所需全部摘要，在不依赖大量上下文消耗下能了解整条链路，对当前需求进行实现、检查、优化、提供建议，我个人认为是不错的。
其实 gpt-5-high 等模型配好 rules 和公开 MCP 也能实现类似功能，只是没法更快更智能。

[Ketteiron]

@lologame #72 对，这些问题都是单体换微服务的驱动力，但老一套说实话又不是不能用，至少一堆破烂 ERP/MES/CRM 等等玩意的用户根本不会在意，属于没有需求创造需求。

[muyiluop]

微服务小厂慎用，因为你会发现到最后很可能就剩下你一个开发人员了。我已经将公司项目开始转向单体了，采用 monorepo 的形式，多模块开发，既可以微服务形式部署也可以单体部署。我们这种小公司，服务器都不超过 2 位数的，用微服务光部署就是一个难题了

[gl3081]

微服务和单体并不是对立的存在，灵活的架构设计可以兼容两者

[Ketteiron]

@gl3081 #78 微服务有传染性，单体有排他性。兼容时期一般存在于单体架构慢慢演变为微服务架构，八股文称之为渐进式重构，最后会彻底变成微服务。

[Kirkcong]

“如果在几年前，引导这样的项目确实很难，但我在深度使用 AI 辅助编写个人项目后改变了这个观点。”

个人项目和公司项目没有可比性，完全不是一个量级的。自己的东西自己全都清楚，公司的东西可能由四五个或者十来个人经手过，各种类型的坑等着你去踩。

如果你用 ai 去辅助这些项目你会死的很惨，要么改动了别人的代码，要么引入了新的 bug,又或者老 bug 复现了，到最后没有人知道你写的是什么东西。

就好像 op 开一个小卖部，你所知道的经验是没办法让沃尔玛去用的。