张翔
143 lines
2.6 KiB
Markdown
143 lines
2.6 KiB
Markdown
# 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+
|
||
- 重点：服务拆分、独立部署
|
||
|
||
---
|
||
|
||
## 相关文档
|
||
|
||
- [T-ILD-基础版-技术实现详细设计](../技术架构/T-ILD-基础版-技术实现详细设计.md)
|
||
- [EVAL-001-架构合理性评估报告](../../03-EVALUATION/EVAL-001-架构合理性评估报告.md)
|
||
|
||
---
|
||
|
||
## 参考资料
|
||
|
||
- Martin Fowler: MonolithFirst
|
||
- 微服务架构设计模式
|
||
- Spring Boot官方文档
|