我相信单体应用会变得流行，但是绝对不会是因为 AI 辅助编程的功劳。 只有同时满足 高并发 高增长 和 复杂业务 三点才有上微服务的必要，但是现在大部分能同时满足这三点的行业基本已经被大公司或者独角兽垄断了。再加上现在这互联网行情，可以预见的未来，似乎也没有什么新的赛道出现了， 能做的，还在做的，基本上只剩下各种定制开发和各种管理系统了，或者其他用户量很少的独立系统，这些场景大多都没有上微服务的必要。单体应用更适合快速开发和部署维护。

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

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

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

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

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

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