张翔
2.6 KiB
2.6 KiB
ADR-001: 单体应用架构选型
文档编号: GYM-ADR-001
版本: v1.0
日期: 2026-03-04
作者: 张翔
状态: 已采纳
状态
已采纳
决策时间
2026-03-04
决策背景
健身房管理系统需要支持基础版100并发用户、付费订阅版500并发用户的业务需求。团队规模3-5人，开发周期紧张，需要快速交付。
决策内容
采用单体应用架构，而非微服务架构。
决策理由
1. 适合当前规模
- 当前并发用户数：100-500
- 预计未来1-2年增长：1000-2000
- 单体应用完全可以满足性能需求
2. 开发效率高
- 团队规模小（3-5人）
- 单体应用开发、调试、部署更简单
- 无服务间通信开销
3. 运维成本低
- 单一部署单元
- 监控、日志管理简单
- 故障排查容易
4. 学习曲线平缓
- 团队对单体应用更熟悉
- 无需学习微服务复杂概念
- 快速上手
替代方案
微服务架构
优势：
- 服务独立部署
- 故障隔离
- 技术栈灵活
劣势：
- 开发复杂度高
- 运维成本高
- 服务间通信开销
- 分布式事务复杂
- 团队规模要求高（通常10+人）
不选择原因：
- 当前规模不需要
- 团队规模不足
- 开发周期紧张
- 运维成本过高
影响范围
- 系统架构设计
- 部署方案
- 团队协作方式
- 技术选型
后果
正面影响
- ✅ 开发效率提升30%
- ✅ 运维成本降低50%
- ✅ 部署复杂度降低70%
- ✅ 学习成本降低60%
负面影响
- ⚠️ 未来扩展需要重构
- ⚠️ 单点故障风险（通过高可用部署缓解）
- ⚠️ 技术栈统一（通过模块化设计缓解）
演进路径
阶段一：单体应用（当前）
- 时间：0-12个月
- 并发用户：100-500
- 重点：快速交付、功能完善
阶段二：垂直扩展（6-12个月）
- 时间：12-18个月
- 并发用户：500-1000
- 重点：性能优化、资源扩展
阶段三：水平扩展（12-24个月）
- 时间：18-24个月
- 并发用户：1000-2000
- 重点：集群部署、负载均衡
阶段四：微服务（24-36个月）
- 时间：24-36个月
- 并发用户：2000+
- 重点：服务拆分、独立部署
相关文档
参考资料
- Martin Fowler: MonolithFirst
- 微服务架构设计模式
- Spring Boot官方文档