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

[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 人勉强能上。
微服务解耦的同时，也引入了对内对外的概念增加复杂度，如果一个人/团队长期在负责的业务上堆砌业务实现，这是合理的。对于小团队来说，这是不合理的，开发者可能要跨越多个自己打造的业务壁垒，属于内耗。
单体也能解耦，只是没法解得像微服务那么彻底。

[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 开一个小卖部，你所知道的经验是没办法让沃尔玛去用的。

[gl3081]

@Ketteiron 现在主流的微服务框架基本都支持：通过依赖注入把各个服务组合成一个大的单体应用。
服务发展的前中后期，可以根据不同的需求把大的单体应用拆分为不同粒度大小的服务

[gl3081]

不需要更改任何业务代码

[MelodYi]

工作内容是微服务开源组件相关。
个人经验看，至少要有产商品、用账户那个复杂度的业务，使用微服务才能见到些正向收益。其他主要是为了个“情绪价值”。
使用微服务框架，不等于用好微服务。运维方式、部署架构、人员结构都要调整的。

[Ketteiron]

@Kirkcong #80 人不够用是很现实的问题，要么放弃，要么解决这个问题，这是绝大部分大中小厂在今天都会遇到的问题。公司内部探讨了很久，最终决定是将目前主要业务以单体形式编写，预估代码量超过 50 万行，随着业务扩张不知道最终会膨胀到多少，这个决定在我入职前就已定下来。面试时与面试官探讨了单体架构细节实现、预演各种场景，最终我选择加入并成为主要负责人之一。
我是个吹毛求疵的人，而目前运行中并且不断迭代的项目我很满意其整体质量。

还是那句话，复杂度不会消失，只会转移，最终还是要整个团队完美地处理好一切细节。
如果一个团队能处理好微服务产生的各种问题，那么同样不会在单体中出现上述任何问题。反之在单体中出现上述问题，那么在微服务也好不到哪去，最终只会转移变成另一个问题。
微服务有好处，也有坏处，而现实是我们无法承受其坏处。

[mbeoliero123]

@muyiluop 微服务怎么单体部署？

[Kirkcong]

@Ketteiron #84 你说的各种观点都太绝对了，就像我们都知道的，凡事如果都说的特别绝对，那么 99%的可能性是错的。

上面也有人和你说过各种微服务的好处，以及各种现实的例子，op 完全没听进去。

如果真的像 op 所说，无法承受其坏处，那么从这个观点提出来到现在已经很多年了，早就应该被淘汰掉，我们也就不会在这里讨论这问题了。存在即合理，你可以说你们体系不适用微服务，但你全盘否认微服务就很离谱。


还有，op 你前后矛盾，这里说你是个吹毛求疵的人，但上面又说 ai 辅助可以完成很大的项目。大家都知道当前 ai 代码的质量有多差，请问你是怎么一边吹毛求疵一边用 ai 辅助的。

哦对了，我曾经的老板也是个吹毛求疵的人，甚至规定了技术文档中所有的有序列表需要是分号分号句号的形式，分号只能出现在有序列表中间，最后必须用句号结尾。那位也一再强调，我们注重的是质量，不可以牺牲产品质量，你俩的话如出一辙。恕我直言，你自己的代码怎么吹毛求疵都无所谓，一旦涉及团队合作，吹毛求疵意义不大。能力出众的 leader 知道如何让下面的人放手去做，而不是制定各种自己的条条框框，让下属束手束脚。有这吹毛求疵的时间不如去招点和你一样吹毛求疵的人，而不是让那些有能力且不拘小节的人浪费时间。


大厂中厂不会出现人不够用的情况的，甚至经常会有人员冗余，尤其是大厂，他们在一些普通岗位不会坑位正好的，比如我前司，会有一批 standby 人员，大家平时工作量也不多，会有些额外时间的。如果出现什么变动，不会立刻缺人。如果真的缺人，那就找 hr 提申请招人完事。


复杂度不会消失这句话也有问题，好的算法确实会让时间复杂度下降，甚至可以从指数级下降到 O(n)，这是计算机和数学理论决定的。

[testcgd]

你是不是在找合并部署啊，我的观点是搞业务架构还是划好层，做好业务建模，业务实现不依赖底层基建，单体部署能跑，分布式也能跑。
传统单体很考验团队的素质，不认真做好 cr ，写好测试，很快就会腐化没法维护了。
目前的 ai 我还是保留意见，就算是 gpt5 ，opus4.1 也不一定靠谱，codex 和 cc 都是用来写测试和 review ，代码还是自己写，你都看不明白的代码，你又怎么知道 ai 是不是在胡说八道，把测试删了或直接写死返回的事情 cc 可没少干，造成资损搞个 p0 可不好玩。

[Ketteiron]

@Kirkcong #86
>上面也有人和你说过各种微服务的好处，以及各种现实的例子
我写了 5 年微服务，我确实明白微服务的好处
>从这个观点提出来到现在已经很多年了
时代在变，人也在变
>大家都知道当前 ai 代码的质量有多差
我不知道，可能是那些人没办法定制 MCP ，没制定良好的 rules
>有这吹毛求疵的时间不如去招点和你一样吹毛求疵的人
实际上公司就是这么做的
>大厂中厂不会出现人不够用的情况的
你的公司太好了，我们正在经历的裁员、砍 HC 肯定是假新闻
>好的算法确实会让时间复杂度下降
时间复杂度是用空间复杂度换来的，计算机理论决定了复杂度不会凭空消失

[Ketteiron]

@testcgd #87 单体确实相对更考验素质，更考验 review 。我们几乎不会直接使用 ai 生成的代码，它只是个提效工具，开发人员提交 pr 之间必须完全理解逻辑。借助 ai 可以生成一大堆废话直接提交，也可以严肃且优雅地组织代码，这取决于人，不取决于 ai ，它仅仅是个工具。
说到测试，我们的单元测试很少，更偏向基于 playwright 的 e2e 测试。当然如果写 java 大量单元测试还是必不可少的。

[Kirkcong]

@Ketteiron #88 敢问你司名称是什么？避坑

[CodeCaster]

@ebony0319 我们团队写了一个开源框架，fit ，就是做的这个，在我们框架中，可以按照微服务的方式写一个一个的插件，插件与插件之间没有任何耦合关系，通信全部是接口，每一个插件都可以单独部署，就像微服务一样，也可以聚合在一起部署，形成一个单独的进程，就是单体架构，关键的一点是，这个从微服务到单体，或者从单体到微服务的转换过程，每一个插件是不用修改任何代码的。这个在我们框架中，叫聚散部署，欢迎来我们的开源项目参观点星，链接： https://github.com/ModelEngine-Group/fit-framework

[CodeCaster]

看到上面大家对微服务和单体讨论了很多，有非常多优秀的见解。如果把微服务和单体服务看做两个极端，那么微服务的出现就是为了解决之前单体服务的一些问题的，只不过，微服务架构本身也有自身的问题，因此，我们团队此前也有思考过是否有一种模式，可以让微服务和单体服务兼而有之，于是，我们开源了一款基础框架，fit 。

fit ，其思想正如其名字一样，我们希望每一个插件，作为单体服务的时候可以运行，组合（ fit ）起来之后依旧可以运行。假如有 N 个插件，那么每一个插件都可以像微服务一样作为一个一个单独的进程启动，对外提供服务，也可以把这 N 个插件，聚合在一起，形成一个单独的进程，启动，就像一个单体服务一样。这个过程中，插件的代码不需要做任何改变。当然，N 个插件可以自由组合形成 M 个进程。

当他们作为微服务互相调用的时候，他们之间的通信是 RPC 调用，存在网络消耗，但是一旦转换成微服务之后，调用可以自动识别变成进程内的内存调用，没有网络开销。这个特性在我们框架中称之为聚散部署。

也就是说，通过我们的框架写出来的代码，不需要经过重构，就可以在微服务和单体之间切换，完全由开发人员在部署阶段自由选择。

我们的框架是今年初开源的，希望大家能够支持一下，如果觉得我们的框架的这个设计思路有帮助，最好帮我们点的 star ，链接： https://github.com/ModelEngine-Group/fit-framework

[Aresxue]

@CodeCaster 瞄了一眼貌似你们的框架主要还是面向 AI 的，你们这个方案在传统工程领域可能没那么适用，因为你们解决的只是运行时问题，微服务还有很多其它的问题，比如代码仓库，除了 google 喜欢且有能力玩好 monorepo ，其它的主流公司还是 Multirepo 模式。如果只是为了解决运行时问题，SofaBoot 的模块化开发和 SOFAArk 等方案也都相对成熟了，甚至更极端些直接用 Faas 好了。

[Aresxue]

2025 年了还有这种讨论，当真是印证了历史发展总是螺旋式上升的这句话。

微服务在大公司是必需品，至于中小公司用不用微服务的标准是能否玩的明白，然后实际中大部分人和公司确实玩不明白，确实难绷。

[MIUIOS]

问下贵公司人数多少人？

[CodeCaster]

@Aresxue #93 我们的代码仓库准备拆分啦，因为现在 AI 太火了，所以介绍中是提到 AI 的，AI 相关的是另外一个模块，基于 fit 框架长出来的，最近正准备写一篇文章呢。拆库就是为了把底层框架和 AI 相关的模块分离开。

最底层的框架的确是为了传统软件工程的，fit 框架的第一行代码是 19 年底诞生的，此时 AI 并没有火。

你提到了成熟的 SofaBoot 的模块化，这个的确阿里巴巴出品的非常优秀的框架呢，只不过 fit 背后的思想指导者，正是此前在阿里巴巴中的软件大拿，Sofa 最初设计的时候也是请教了我们框架的设计者的。fit 的前身已经摸索过了相关模块化的路线，最终重新出发，走了插件化的道路，插件化和模块化还是有一些区别的。打个比较简单的比方，模块化，各个模块需要组合在一起，在编译打包一次，有点像不少预制半成品，还是需要有一次简单的烧的过程的，但是插件化，各个插件已经完全烧好了，打包就像一起装盘的过程。

感谢看了一眼我们的项目~

[micean]

好的微服务应该就是多个单体