你有没有参与过那种被“微服务”过度设计的项目？
设计得夸张到需要一个额外的服务来判断另一个服务是不是还活着？

对，我也遇到过。

我已经数不清给多少创业公司做过咨询或建议了。每一家都兴奋地向我展示他们崭新的、解耦的、“无限可扩展”的微服务架构。每次我心里都默默想：
这玩意六个月内就会塌。

不是因为微服务的概念不好。它有用武之地。
但那个场景绝对不是“三个程序员在 WeWork 里，搞着半坏的 MVP，连一个付费用户都没有”的时候。

讽刺的是，我见过那些真正活下来、能持续发版、不把种子轮烧在没人需要的基础设施上的公司，几乎都在用单体。

没错，单体。那个被说成“恐龙”的架构方式。

单体不是敌人

某个时间点开始，“单体”这个词就成了贬义词，就像叫人“Legacy 系统”一样，立刻让人翻白眼。
但问题是，很多黑单体的人，根本没做过 CRUD 以外的东西。

反过来，那些真正拉到用户、做出营收、跑起来的创业公司，往往就是一个单体仓库 + Postgres 后端 + 一个大 Service 文件夹。

而且，它们跑得好好的。

所以，单体不是敌人。过早的复杂化才是。

“可扩展性”的幻觉

创业公司最爱自我安慰的一句话是：
“我们要为百万用户做准备。”

但现实呢？注册表单还坏着呢，压根没人能登录。

大多数创业公司压根不需要扩展性。
他们需要的是先活下来。
需要能快速转向，能每天甚至每小时发版，不需要花时间解服务网格，或者 debug 为什么同一台机器上的两个容器之间 gRPC 调不通。

在早期，灵活性 > 可扩展性。
简单 > 优雅。
能跑的代码，比让人流泪的分布式代码更值钱。

单体的魔力：快、专注、能交付

你知道单体最大的好处是什么吗？

你能把事情做完。

• • 不用浪费三天争论 “auth 要不要单独拆成服务”。
• • 不用每天和 YAML 格斗。
• • 不用搞五个仓库来假装自己有“架构”。

你就是…把功能写完。

这也是为什么最好的团队——尤其是有经验的团队——会默认选单体。
因为他们已经跳过微服务那套舞蹈，知道代价，不值得。

事实胜于雄辩：

• • Facebook 早期？单体。
• • GitHub 早期？单体。
• • 就连 Amazon，当初也是单体，后来才拆。

微服务的代价不仅是技术上的

大家总在聊服务边界和扩展性，却很少有人谈团队士气。

试着让一个新人接手 40 个微服务的森林：
一半没文档，命名随缘。
看着他们眼神慢慢涣散。

再对比一下：丢给他们一个干净的单体。

• • 搜函数能搜到。
• • go run app 就能跑起来。
• • 不需要三个 shell 脚本加一场驱魔仪式。

别低估架构对开发速度的影响。微服务？除非必要，否则它只会让你变慢。文化上、管理上、心理上。

单体是可逆的，微服务不是

单体长得太大？没事。
把某块抽出来，等你真的需要时再拆。

优秀的软件都是自然演化的，而不是在你还没有一个用户的时候就画在架构图上的。

未来不是靠“预先设计”保住的。
未来是靠先活下来、跑得快、保持清醒保住的。

最后的想法

所以，不，单体不是过时的。它是被低估的。
选择单体不是因为懒，而是因为聪明。

因为你在做的是创业公司，不是分布式系统论文。
因为技术的意义不是“酷炫”，而是“有用”。
因为有一天，当你真的到达那个神话般的规模时，你会有钱、有团队、有背景，来正确地拆解系统。

在那之前？

快点发版，保持精简。单体万岁。

💡 结合实战

• • 创业公司早期的最大风险不是性能，而是没人要。
• • 单体不仅节省基础设施成本，更能缩短开发-反馈回路。
• • “单体可逆”很关键：未来拆分的最佳时机，往往是团队已经被真实痛点打到，而不是架构师脑补出来的。
• • 真正能撑住千万用户的公司，无一不是先靠单体活下来，然后再谈微服务。