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 等等玩意的用户根本不会在意，属于没有需求创造需求。