微服务并不是大公司的专利。在某些情况下，即使是小团队也能受益。但复杂性的风险很高，所以决策需要有充分的依据。秘诀在于了解微服务何时有帮助以及[单体 0 ] 何时更高效。
本指南展示了微服务对小型团队有意义的用例以及如何避免常见的陷阱。
当微服务对小型团队有意义时
即使团队减少了，微服务在以下情况下也很有用：
- 有一个非常孤立的领域（例如支付）。
- 产品需要缩放特定部分。
- 一项功能需要高可靠性。
如果没有明确的需求，[monolith1] 通常更好。
实际用例
案例1：支付模块
支付需要稳定性和安全性。分离为一项服务可以降低风险并促进合规性。
案例2：文件上传及处理
如果应用程序处理大量视频或图像，隔离此流可以避免核心过载。
案例 3：通知
通知服务可以隔离，避免对主流程造成影响。
小团队的好处
- 有针对性的可扩展性。
- 误隔离。
- 灵活地发展关键部分。
小团队的风险
- 增加了复杂性。
- 需要强有力的监控。
- 更多的开发和基础设施。
如果团队没有能力，成本可能会超过收益。
推荐策略
对于小团队：
- 从 [monolith2] 开始。
- 只提取非常关键的模块。
- 逐步使用微服务。
这种方法避免了过度的复杂性。
决策清单
- 模块是否需要独立扩展？
- 团队可以维护基础设施吗？
- 将所有东西放在一起是否存在很高的风险？
如果答案是否定的，请保留 [monolith3]。
结论
在特定情况下，微服务对于小型团队可能很有用，但它们不应该是默认选择。 [monolith4] 仍然是大多数 MVP 的最佳选择。
通过本指南，小型团队可以更清楚地决定何时使用微服务以及何时避免微服务。
另请阅读
- [单体与微服务：实践中的用例5
- [应用程序中的微服务：扩展用例6
- [应用架构：初学者最佳实践7
- 【GraphQL应用：真实案例的成本与定价8
- [应用程序中的缓存9
- [应用程序中的缓存：良好实践和基础知识10