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

[Ketteiron]

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

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

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

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

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

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

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

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

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