# 架构模式参考

## 目录
1. 单体架构
2. 模块化单体
3. 微服务架构
4. 事件驱动架构
5. 分层架构
6. CQRS（命令查询职责分离）
7. Serverless 架构
8. 模式选择指南

## 概览
本文档提供常见的软件架构模式，包括其特点、适用场景和权衡考虑，用于指导架构设计决策。

## 核心内容

### 1. 单体架构（Monolithic）

**特点**：
- 整个应用作为单一部署单元
- 共享数据库和代码库
- 调用方式为内存函数调用

**适用场景**：
- 初创项目快速验证
- 小型团队（< 10人）
- 业务逻辑相对简单
- 预期用户规模有限

**优势**：
- 开发简单，部署容易
- 调试和测试方便
- 无需复杂的服务间通信
- 初期开发速度快

**劣势**：
- 扩展性受限（只能整体扩展）
- 技术栈统一，灵活性低
- 代码耦合度高，维护成本随规模增长
- 故障影响范围大

---

### 2. 模块化单体（Modular Monolith）

**特点**：
- 仍是单一部署单元
- 代码按模块组织，模块间通过明确接口交互
- 强调内部边界和依赖管理

**适用场景**：
- 需要良好结构的中型项目
- 团队规模 5-20人
- 未来可能拆分为微服务的过渡阶段

**优势**：
- 保持单体部署的简单性
- 代码组织清晰，降低耦合
- 为未来微服务化做准备
- 比传统单体更易维护

**劣势**：
- 仍受限于整体部署
- 模块边界管理需要良好纪律
- 跨模块变更仍需整体测试

---

### 3. 微服务架构（Microservices）

**特点**：
- 系统拆分为多个独立服务
- 每个服务独立部署和扩展
- 服务间通过 API（HTTP/RPC/gRPC）通信
- 数据库通常独立（每个服务自己的数据库）

**适用场景**：
- 大型复杂系统
- 多团队协作开发
- 需要独立扩展不同模块
- 业务领域边界清晰

**优势**：
- 独立部署和扩展
- 技术栈灵活
- 故障隔离
- 团队自治

**劣势**：
- 分布式系统复杂度高
- 服务间通信开销
- 数据一致性挑战
- 运维和监控复杂
- 初期开发成本高

**关键实践**：
- 领域驱动设计（DDD）划分边界
- API 网关统一入口
- 服务注册与发现
- 分布式追踪
- 容错机制（熔断、降级）

---

### 4. 事件驱动架构（Event-Driven）

**特点**：
- 通过事件驱动业务流程
- 松耦合的组件通过事件总线通信
- 支持异步处理和实时响应

**适用场景**：
- 需要高实时性的系统
- 多系统集成场景
- 复杂业务流程编排
- 需要高扩展性的异步任务

**优势**：
- 松耦合，易扩展
- 异步处理提高吞吐量
- 天然支持审计和溯源
- 易于集成外部系统

**劣势**：
- 流程追踪困难
- 事件Schema 管理复杂
- 错误处理和重试机制复杂
- 最终一致性的挑战

**关键组件**：
- 事件总线（消息队列：Kafka、RabbitMQ）
- 事件存储
- 事件溯源（Event Sourcing）
- CQRS（命令查询分离）

---

### 5. 分层架构（Layered）

**特点**：
- 按职责分为不同层次
- 常见分层：表现层 → 业务层 → 持久层 → 数据库
- 严格依赖方向（上层依赖下层，下层不依赖上层）

**适用场景**：
- 几乎所有传统企业应用
- 需要清晰职责分离的系统
- 团队熟悉传统开发模式

**优势**：
- 结构清晰，易于理解
- 职责分离，便于测试
- 开发模式成熟
- 易于维护

**劣势**：
- 可能过度设计
- 层次间调用可能带来性能损耗
- 不适合所有场景（如纯 API 服务）

---

### 6. CQRS（命令查询职责分离）

**特点**：
- 读写操作分离
- 写操作（命令）使用领域模型
- 读操作（查询）使用优化的数据模型
- 可能使用不同的存储（写用关系数据库，读用 NoSQL）

**适用场景**：
- 读写差异大的系统（读多写少）
- 复杂业务逻辑的写操作
- 需要高性能的复杂查询
- 事件驱动架构的读模型

**优势**：
- 读写性能独立优化
- 复杂业务逻辑不影响查询性能
- 易于扩展读端
- 与事件溯源结合良好

**劣势**：
- 增加系统复杂度
- 数据同步问题（最终一致性）
- 不适合所有场景（读写简单的系统）

---

### 7. Serverless 架构

**特点**：
- 无需管理服务器
- 函数即服务（FaaS）
- 按执行时间和资源付费
- 自动弹性伸缩

**适用场景**：
- 波动性大的工作负载
- 事件驱动的短任务
- 快速原型和实验项目
- 无状态的服务

**优势**：
- 无需运维服务器
- 自动弹性伸缩
- 按量付费，成本灵活
- 快速部署

**劣势**：
- 冷启动延迟
- 厂商锁定风险
- 调试和监控困难
- 不适合长时间运行的任务
- 状态管理复杂

---

## 模式选择指南

### 决策树

```
系统规模？
├─ 小型（< 5万用户，< 10人团队）
│  └─ → 单体架构 或 模块化单体
├─ 中型（5-50万用户，10-30人团队）
│  ├─ 业务复杂度低？
│  │  └─ → 模块化单体
│  └─ 业务复杂度高？
│     └─ → 考虑早期微服务（从 2-3 个核心服务开始）
└─ 大型（> 50万用户，> 30人团队）
   ├─ 领域边界清晰？
   │  └─ → 微服务架构
   └─ 领域耦合紧密？
      └─ → 模块化单体 + 按需演进

需要高实时性和异步处理？
└─ 是 → 事件驱动架构（可与其他架构组合）

读写操作差异大？
└─ 是 → 考虑 CQRS

运维资源有限？
└─ 是 → 单体 或 Serverless
```

### 权衡考虑

**复杂度 vs 收益**：
- 微服务带来复杂度，只在需要时采用
- 单体架构简单但扩展性受限
- 避免为了微服务而微服务

**团队能力**：
- 微服务需要成熟的 DevOps 能力
- 新团队从单体开始，逐步演进
- 技术选型考虑团队熟悉度

**业务需求**：
- 业务快速变化？→ 模块化单体或微服务
- 需要独立扩展？→ 微服务
- 高实时性？→ 事件驱动
- 成本敏感？→ Serverless

**演进策略**：
- 从单体开始
- 随着需求增长拆分
- 按领域边界拆分微服务
- 避免"大爆炸"重构

## 示例

### 示例 1：电商平台
- **推荐架构**：微服务 + 事件驱动
- **原因**：业务复杂度高，需要独立扩展，多团队协作
- **核心服务**：用户服务、商品服务、订单服务、支付服务、库存服务
- **事件流**：下单 → 库存扣减 → 支付 → 物流 → 通知

### 示例 2：内容管理系统（CMS）
- **推荐架构**：模块化单体
- **原因**：业务相对简单，中型团队，未来可能需要扩展
- **模块划分**：内容管理、用户管理、评论、搜索

### 示例 3：IoT 数据处理平台
- **推荐架构**：事件驱动 + CQRS
- **原因**：高实时性，写密集，读查询复杂
- **设计**：设备数据写入事件流，读端使用时序数据库优化查询

### 示例 4：内部管理后台
- **推荐架构**：分层单体
- **原因**：传统企业应用，用户量有限，团队熟悉
- **分层**：Web 层 → Service 层 → DAO 层 → 数据库