放弃了微服务，我们为什么要重回到单体架构？

谷歌当年用微服务的起因 当年谷歌上微服务，核心原因并不是“微服务更先进”，而是——人太多了。 工程师规模大到什么程度？如果还用单体，一个仓库里几千人同时改代码，每天光是 merge 冲突就能把人拖死，交付效率反而直线下降。所以他们当时微服务，是为了解决超大规模研发协作问题的工程手段。 真心想说一句： 微服务它不是银弹，更不是中小团队的默认选项。 我自己是为微服务的“交过学费的”。 我之前在一家连锁企业做后端负责人。公司有几百家线下门店，听起来挺大，但现实是： IT 团队人数不多 业务并发并不高 系统复杂度也远没到互联网大厂那个级别 结果呢？ 我们搞了 70 个微服务。 微服务如此之多，最先死的不是系统，是效率 阿里云账单每年几百万。但说实话，这些钱，换来的不是稳定性，而是混乱。 有一次，产品提了个需求。我扫了一眼，心里评估：三天，最多。 开发跟我说： “要两周。” 我以为他夸张，结果一细聊，直接沉默。 这个需求，要改十几个微服务。 微服务拆太多，团队快被拖垮 服务拆得很碎，但改动完全不独立 这是很多团队第一次上微服务时，最常见、也最致命的问题。 好几个服务在干相似的业务 职责边界模糊 没有稳定的领域划分 于是就变成了现在这样： 一个业务需求 = 这个服务改一点 那个服务补一下 另外几个还得一起联调 这已经不是“微服务”，而是分布式单体。 正确的拆法其实很朴素，比如： 订单：1～2 个核心服务 支付：1～2 个核心服务 再配合聚合层，对外提供接口 服务可以少，但边界一定要清晰。 一个需求改十几个服务，会发生什么？ 交付周期拉长，导致需求堆积 改动面太大，代码质量下降 故障频发 最要命的是： 无法按时、按质交付需求。 对 IT 团队来说，这是灾难性的。 运维体验？奔溃模式 每次发版： N 个服务 N 套配置 N 次发布 哪怕全自动，一次完整发版也要一个多小时。 更隐蔽的问题：组织结构 很多人只盯着“系统怎么拆”， 却忽略了“人是怎么协作的”。 正常的状态应该是： A 业务 → 固定一小撮人 他们长期维护固定的几个服务 代码越来越熟，修改越来越稳 微服务一旦和组织结构错位， 复杂度会被指数级放大。 那什么时候该果断回到单体？ 只有几个人的时候，毫不犹豫选单体。 但前提是，你得把这几件事做好： 单体内做好模块化 固定模块负责人 监控、代码审核、回滚机制一个都不能少 人少、服务少，这些事容易落地。 微服务不是不用，而是用得克制 当团队规模到了 10～20 人，我才会开始认真考虑微服务。 而且目标很清晰： 保护核心服务 降低协作冲突 比如订单系统。 订单一旦出事，直接影响现金流。这种服务，就不该因为别人改个其他模块的逻辑被波及。 把它独立出来，是风险控制。 微服务如果用的好，应该是下面这个样子的。