Netflix用2000人搞微服务，你4个人凑什么热闹

一个4人团队，60%时间在修Kubernetes而不是写功能。这不是段子，是Gerus-lab见过太多次的真实剧本。

微服务的诱惑太熟悉了：独立部署、故障隔离、无限扩展。Netflix这么干，Amazon这么干，技术大V写了40条推文吹这个。于是你把应用拆成12个服务，加上服务网格、消息队列、Redis——然后发现产品还没上线，18个月跑道已经烧掉一半。

问题不是你不懂技术，是你抄错了作业。

Gerus-lab早期也栽过。一个GameFi平台项目，团队上来就搞8个微服务"为了可扩展性"。结果前3个sprint全花在让服务互相说话上，真正的游戏逻辑第6个sprint才进场。换句话说，用户拿到手的是一套精致的基建，而不是能玩的东西。

分布式系统的残酷数学

微服务布道者不会告诉你这些：

第一，故障模式呈指数级爆炸。单体应用在一个地方崩溃。分布式系统在一千个微妙的地方崩溃：网络分区、部分写入、消息队列积压、跨服务死锁。

你以为的流程：订单服务创建→支付服务扣款→库存服务扣减。

凌晨3点的现实：订单成功，支付成功，库存超时。恭喜，你超卖了。现在去写个saga模式来修这个烂摊子。

第二，延迟会叠加。每次服务间HTTP调用增加2-10毫秒。串6个服务，还没写业务逻辑就先丢12-60毫秒。用户不会为你的架构优雅鼓掌，他们只会觉得"这APP有点卡"。

第三，本地开发变成地狱。跑12个服务需要Docker Compose文件长得像基础设施代码。新人第一周全花在配环境上，不是写代码。

第四，可观测性成本翻倍。日志、追踪、监控需要另一整套栈：Jaeger、Zipkin、ELK、Prometheus、Grafana。6个新东西会坏、需要维护、会在凌晨把你叫起来。

他们怎么爬出来的

Gerus-lab后来的Web3 DeFi项目换了打法：从结构良好的单体开始，有明确证据需要拆分时才拆。

代码组织长这样——按模块划分，边界清晰，未来真要拆服务时，模块直接打包就行：

src/
├── modules/
│ ├── auth/
│ │ ├── domain/
│ │ ├── application/
│ │ └── infrastructure/

结果立竿见影。团队专注写功能，不是修管道。

单体不是妥协，是那个阶段的正确工程决策。

什么时候该拆，什么时候该忍

微服务不是原罪，错的是时机。Gerus-lab现在的判断标准很具体：

团队超过50人，且不同组的功能发布节奏确实冲突——拆。某个模块需要独立扩容10倍以上，且优化单体架构成本更高——拆。合规要求强制数据隔离——拆。

以上都不是？那你的"微服务"只是昂贵的cosplay。

Netflix有2000+工程师，处理全球15%互联网流量。你有的是产品想法、18个月跑道、和等着用功能的用户。他们不需要你的基础设施诗歌。