微服务 vs 单体应用：2024 年的正确选择

微服务和单体不是技术品味之争，而是组织复杂度、部署能力和业务边界是否匹配的问题。

别先问架构形态

在讨论拆服务之前，先看团队是否真的被独立部署、独立扩缩容或边界隔离卡住。如果没有，拆分很可能只是把复杂度搬到网络上。

单体的优势

单体应用拥有简单的调用链、直接的事务边界和更低的本地开发成本。对于早期产品，这些优势往往比“架构先进”更重要。

微服务真正的成本

服务拆开之后，CI/CD、监控、链路追踪、配置管理、灰度发布和故障演练都会成为基础设施要求。没有这些能力，微服务只会放大故障面。

选择框架

- 团队小于 8 人：优先模块化单体
- 边界稳定且部署频率不同：考虑拆服务
- 需要独立扩容的热点模块：拆出独立服务
- 缺少观测性平台：暂缓微服务化

好的架构决策应该让团队明天更容易交付，而不是让今天的图看起来更宏大。