微服务 vs 单体架构：如何选择？

每个 CTO 最终都会听到："我们需要像 Netflix 一样的微服务！"。但 Netflix 有 10,000 名工程师和数十亿美元。而你有 5 名开发人员和一个 MVP。让我们弄清楚什么时候单体架构是明智的，什么时候微服务是必要的。

视觉比较

什么时候单体架构是正确的选择

• 早期创业公司： 你需要开发速度，而不是规模。单体架构允许你快速更改代码，而无需编排 20 个服务。
• 团队 < 10 人： 你根本没有资源来维护微服务基础设施（Kubernetes、Service Mesh、分布式追踪）。
• 低负载： 如果你有 1000 RPS，单体架构可以在一台服务器上处理。为什么要复杂化？

什么时候该转向微服务

1. 不同的团队，不同的节奏： 支付团队希望每天部署 5 次，而报告团队——每周一次。单体架构迫使每个人都等待彼此。
2. 模块上的不同负载： 移动应用 API 获得 100k RPS，而管理面板——10 RPS。在单体架构中，你一起扩展所有内容（昂贵）。在微服务中——只扩展需要的部分。
3. 技术自由： 想用 Python 编写 ML 模块，用 Go 编写主后端？在单体架构中，这很痛苦。在微服务中——这很正常。

黄金中间地带：模块化单体架构

从单体架构开始，但将其编写为未来的微服务。将代码划分为具有明确边界的模块（领域驱动设计）。当时机成熟时，你只需将模块提取到单独的进程中。

NineLab 建议： 微服务不是架构。它们是组织结构。如果你没有多个团队，你就不需要微服务。