# 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官方文档