面试官问：“现在都 2026 年了，你们新开的项目，架构是不是都直接上 Spring Cloud Alibaba 或者 K8s 微服务了？”
很多人会眼前一亮，觉得机会来了：“那必须的！微服务解耦、高内聚低耦合、技术栈灵活、容错性强，单体架构那种’大泥球’早该进博物馆了。”
如果你这么回答，面试官可能会微微一笑，然后在心里给你打个"架构虚浮"的标签。
这时候面试官通常会抛出一连串"死亡追问"：
“那你们团队有几个人？如果订单服务扣款成功，但库存服务扣减失败了，你的分布式事务怎么处理？Seata 还是 TCC？链路追踪用的什么？服务雪崩了怎么熔断？”
这一问，往往能把那些只看过几篇公众号文章、没踩过坑的候选人问得哑口无言。
这篇文章就来聊聊：为什么被奉为圭臬的微服务架构，在很多初创公司和新项目里，往往是"催命符"，而大佬们反而建议先写"老土"的单体？
看懂本质差异
在撕逼之前，先用一个通俗的例子对齐一下概念。
单体架构（Monolith）（类似于"夫妻店"）：
- 模式：老板娘负责点菜、收银、端盘子，老板负责买菜、切菜、炒菜。
- 沟通：老板娘喊一声：“3号桌不要葱！” 老板马上听到。沟通成本几乎为零。
- 调整：今天生意不好想改卖面条？两口子商量一下，明天就能换招牌。迭代极快。
- 风险：老板生病了，店就得关门（单点故障）。
微服务架构（Microservices）（类似于"跨国连锁餐饮集团"）：
- 模式：有专门的"收银子公司"、“采购子公司”、“烹饪子公司”、“物流子公司”。
- 沟通：收银员不能直接对厨师喊话，必须发工单（RPC调用/消息队列）。收银系统挂了，厨师还在炒菜，最后菜端不上去（分布式一致性问题）。
- 调整：想改菜单？得开十几个跨部门会议，协调所有子公司的系统接口。
- 优势：由于分工明确，可以无限开分店（水平扩展），厨师不够了就招厨师，不用招收银员。
微服务的隐形陷阱：没有微服务的命，得了微服务的病
回到开头的面试题。对于初创公司或新项目（通常 3-10 个后端开发），直接上微服务会有什么后果？
1. 分布式事务的噩梦
在单体应用里，保证数据一致性只需要一个@Transactional注解。数据库的 ACID 特性会帮你搞定一切：要么全成功，要么全回滚。
到了微服务，数据分散在不同的数据库里。
用户下单了，订单服务写库成功，调用库存服务扣减库存——网络超时了。
你是重试？还是回滚？
为了解决这个问题，你引入了 Seata、或者手写 TCC（Try-Confirm-Cancel）、或者搞可靠消息最终一致性。
结果：业务代码没写多少，全在写为了保证数据一致性的"胶水代码"。开发效率直接腰斩。
2. 运维复杂度指数级上升 (DevOps Hell)
单体应用部署很简单：打一个jar包，丢到服务器上，java -jar启动，完事。
微服务呢？
你需要部署注册中心（Nacos/Eureka）、配置中心、网关（Gateway）、熔断器（Sentinel）、链路追踪（SkyWalking）、日志聚合（ELK）、Prometheus 监控…
打脸时刻：你团队一共就 5 个后端，结果 2 个人在搞基建，1 个人在查网络不通的问题，只有 2 个人在写业务。
老板问：“为什么加个简单的功能要两周？”
你答：“因为我们要调整三个服务的接口，还要联调…”
3. 调试与排查的"侦探游戏"
单体应用报错了，打开日志文件，搜索Exception，堆栈信息一目了然。
微服务环境下，前端报错"系统异常"。
你得先去网关查日志，发现是调用 A 服务超时；
去 A 服务查，发现是 B 服务报错；
去 B 服务查，发现是数据库死锁。
如果没有完善的链路追踪系统，排查一个 Bug 能要把人逼疯。以前是看日志，现在是"分布式破案"。
那什么时候该用微服务？
Martin Fowler（微服务概念的提出者）自己都说过：“Don’t start with a monolith is usually wrong.”（一开始就不写单体通常是错的。）
微服务不是为了"尝鲜"，而是为了解决规模带来的问题：
- 团队规模太大：几十上百人维护一个代码库，光是合并代码冲突就得花半天，这时候需要拆分服务，让小团队独立维护。
- 业务复杂度过高：单体应用启动一次要 10 分钟，改一行代码影响全局，这时候必须拆。
- 扩展性需求差异大：比如秒杀模块需要抗 10 万 QPS，而后台管理模块只有 10 QPS。拆分后可以单独给秒杀模块加机器。
对于初创公司，活下去才是第一要务。快速迭代、验证商业模式，单体架构是无敌的。
面试怎么答？
简洁版（30 秒）：
微服务虽然解决了扩展性和耦合问题，但引入了巨大的分布式复杂性（如分布式事务、网络延迟、运维成本）。
对于初创团队或从 0 到 1 的项目，业务模型还没定型，需要极速迭代。单体架构开发效率最高、部署最快、调试最简单。过早优化是万恶之源，应该先用设计良好的模块化单体（Modular Monolith）快速交付，等业务量和团队规模上来了，再逐步拆分为微服务。
进阶版（1 分钟，带架构演进视角）：
架构是为业务服务的，没有最好的架构，只有最合适的架构。
单体的本质是"聚合"：利用进程内调用（函数调用）的零延迟和数据库事务的 ACID 特性，以最低成本解决业务问题。适合 0-1 阶段验证商业模式。
微服务的本质是"拆分"：通过网络调用和最终一致性（BASE），牺牲部分开发效率和实时性，换取系统的水平扩展能力和团队的独立性。适合 1-100 阶段解决增长瓶颈。
大佬建议先写单体，是因为"单体是微服务的最佳前身"。如果我们在单体里连模块化（Module）都做不好，代码耦合严重，那拆分成微服务只会变成"分布式大泥球"（Distributed Big Ball of Mud），让系统死得更快。
最后总结一句：
不要为了"简历好看"而强上微服务。能在单体里把代码写得清晰、模块解耦的人，才是真正的架构高手。
没有微服务的命（基础设施、运维能力、团队规模），却得了微服务的病（分布式复杂性），是很多项目失败的根源。
⚡️ 别把时间浪费在低效复习上
很多人复习抓不住重点。作为过来人，我分析了100+份大厂面试记录，将Go/Java/AI 的核心考察点、高频题、易错点浓缩进了一份 PDF。
不搞虚的，全是干货。
关注并私信我【面经】，免费发你，立即纠正你的复习方向，把时间用在刀刃上。
时，注意事项)
