[单体架构0 和微服务之间的选择是软件架构中最重要的决策之一。整体结构简单且启动速度快。微服务提供可扩展性和自主性，但增加了复杂性。正确答案取决于上下文，而不是时尚。
本指南比较了方法、展示了真实案例并提供了实践中的决策标准。
什么是单体
Monolith 是一个单一的应用程序，所有功能都集中在同一个系统中。它的开发和部署很简单，尤其是在早期阶段。
什么是微服务
微服务将应用程序划分为多个独立的服务，每个服务都有特定的职责。他们通过 API 进行通信。这种方法有利于可扩展性和并行工作。
快速比较
| 外观 | 巨石 | 微服务 |
|---|---|---|
| 家居简约 | 高 | 低 |
| 可扩展性 | 有限公司 | 高 |
| 部署 | 独特 | 独立 |
| 运营成本 | 未成年人 | 最大 |
实践中的用例
案例 1：初创公司 MVP
早期初创公司经常使用[单体架构1]。它可以让您快速构建、验证产品并节省成本。此时微服务会产生不必要的复杂性。
案例 2：不断发展的电子商务
当结帐需要独立于目录进行扩展时，需求较高的电子商务可以迁移到微服务。这避免了瓶颈。
案例 3：B2B SaaS
多模块的SaaS可以采用微服务来分隔团队，保证各个模块的独立演进。
整体式的优点
- 简单。
- 较低的初始成本。
- 易于调试。
非常适合小型产品或正在进行验证的产品。
微服务的优点
- 模块化可扩展性。
- 团队自主权。
- 更强的韧性。
非常适合复杂且不断增长的系统。
每种方法的风险
巨石
- 攀爬特定部位有困难。
- 风险较高的部署。
- 增长会导致缓慢。
微服务
- 操作复杂性。
- 需要[可观察性2。
- 成本更高。
决策标准
关键问题：
- 团队是否需要缩放特定部件？
- 是否有足够的团队来维护多项服务？
- 产品是否已经证明了其价值？
- 基础设施是否支持复杂性？
如果大多数答案是否定的，[monolith3] 仍然更好。
结论
Monolith 是理想的起点。当产品不断增长并需要真正的可扩展性时，微服务就有意义。决策必须基于背景，而不是趋势。
通过本指南，您可以为产品的每个阶段选择最合适的架构。
另请阅读
- [应用程序中的微服务：小型团队的用例4
- [应用程序中的微服务：扩展用例5
- [应用架构：初学者最佳实践6
- 【GraphQL应用：真实案例的成本和定价7
- [应用程序中的缓存8
- [应用程序中的缓存：良好实践和基础知识9