单体应用与微服务是数字产品架构中最重要的决策之一。对于某些团队来说，简单的[单体0] 交付速度更快且成本更低。对于其他人来说，微服务允许演进和扩展。本指南展示了用例和示例来帮助您做出决定。
当每种方法有意义时，重点是摆脱理论并在实践中理解。
什么是单体
Monolith 是一个单一的应用程序，其中所有内容都位于相同的基本代码中，并且通常在单个部署中。优点：
- 开发简单。
- 单一且快速的部署。
- 降低操作复杂性。
缺点：
- 难以攀爬孤立的部分。
- 代码可能会变得庞大且耦合。
什么是微服务
微服务是几个小型应用程序，每个应用程序都专注于特定领域。优点：
- 按服务隔离的规模。
- 独立团队。
- 更大的技术灵活性。
缺点：
- 操作复杂性。
- 基础设施成本较高。
- 需要很强的[可观察性1]。
快速比较
| 关键 | 巨石 | 微服务 |
|---|---|---|
| 初始速度 | 高 | 媒体 |
| 复杂性 | 低 | 高 |
| 按领域扩展 | 有限公司 | 高 |
| 运营成本 | 低音 | 高 |
| 可观察性 | 简单 | 复杂 |
这种比较有助于了解权衡。
典型用例
当整体架构有意义时
- 处于初始阶段的初创公司。
- 产品功能很少。
- 小而精干的团队。
[整体式2]可以实现快速交付和市场验证。
当微服务有意义时
- 具有多种业务线的产品。
- 大型且分散的团队。
- 需要独立的可扩展性。
当业务复杂性增加时，微服务会有所帮助。
实际例子
示例1：初始阶段的SaaS
产品具有 3 个主要模块。 [整体架构3 可以专注于交付和验证。微服务将会过剩。
示例 2：不断增长的市场
随着用户的增加，搜索和订购服务的增长速度比其他服务快得多。微服务允许您仅扩展必要的部分。
示例 3：数字银行
对于多个团队，每个域都是隔离的。微服务保证自治，但需要在[可观察性4方面进行大量投资。
隐藏成本
微服务需要：
- 单独部署。
- 更复杂的监控。
- 日志管理和跟踪。
- 容错。
对于小团队来说，这可能是一种负担。
推荐策略
对于大多数人来说：
- 从[结构良好的单体5开始。 2.内部划分域。
- 仅在有明确需要时才进行迁移。
这种策略避免了早期的复杂性。
决策清单
- 我有微服务团队和结构吗？
- 我需要攀爬孤立的部分吗？
- 我的 [monolith6] 是否会成为瓶颈？
- 运营成本是否符合预算？
如果答案是否定的，请保留[整体7。
结论
单体应用与微服务并不是时尚问题。这是基于团队规模、业务复杂性和规模需求的决策。在大多数情况下，从 [monolith8] 开始是最有效的路径。当复杂性需要时，微服务才有意义。
##常见问题解答
微服务总是更好吗？
不会。它们会增加复杂性和成本。
我可以从[单体9迁移到微服务吗？
是的，但必须分阶段进行，并在确实需要时进行。
单体无法扩展？
规模，但根据产品的大小可能有限制。
微服务最大的风险是什么？
操作复杂且需要[可观察性10。
您知道何时迁移？
当特定领域成为瓶颈并且[单体11]阻止扩展时。
另请阅读
- [单体 vs 微服务：选择哪种架构12
- [单体与微服务：用例和决定清单13
- [单体与微服务：实践中的用例14
- 【应用中的微服务：日常生活中出现的用例15
- [应用中的微服务：移动分布式架构16
- [应用程序架构：可扩展系统完整指南17