标准答案
- 单体应用把模块部署在同一个进程或同一套交付单元中，适合业务边界还在快速变化、团队规模较小、部署频率可统一协调的阶段。
- 微服务把相对独立的业务能力拆成可独立发布、扩容和治理的服务，适合边界稳定、团队拥有明确责任、不同模块有明显资源或发布差异的场景。
- 拆成微服务后会新增网络调用、分布式事务、链路追踪、版本兼容、配置治理和故障传播成本，因此不能把“服务多”当成架构成熟。
- 实际决策要比较业务变化速度、团队边界、独立扩容需求、故障隔离需求和现有运维能力，而不是只按公司规模套模板。
题目解析
单体的优势不是落后，而是调用链短、数据一致性直接、调试和交付简单。很多新业务在需求没有稳定前，先保持模块化单体反而能更快验证边界。
微服务的核心价值是组织和演进能力，不是把一次函数调用改成一次 HTTP 调用。只有当模块确实需要独立节奏、独立容量或独立责任人时，拆分才会带来净收益。
常见误区
- 把单体等同于代码耦合。模块化单体同样可以有清楚的领域边界和依赖规则。
- 为了“高并发”先拆服务，忽略真正瓶颈可能是数据库、缓存或外部依赖。
- 拆分后仍共享数据库和发布节奏，却承担了全部网络与运维复杂度。