470 lines
12 KiB
Markdown
470 lines
12 KiB
Markdown
|
|
# TYAPI Server 架构设计文档
|
|||
|
|
|
|||
|
|
## 📖 概述
|
|||
|
|
|
|||
|
|
TYAPI Server 是一个基于现代化软件工程实践构建的企业级 Go Web 应用架构。本架构综合了领域驱动设计(DDD)、CQRS、事件驱动架构、微服务设计模式等先进理念,旨在提供一个高性能、可扩展、易维护的 Web 服务基础框架。
|
|||
|
|
|
|||
|
|
## 🏗️ 核心设计理念
|
|||
|
|
|
|||
|
|
### 1. 领域驱动设计 (Domain-Driven Design)
|
|||
|
|
|
|||
|
|
**理念**:将复杂的业务逻辑组织成清晰的业务域,每个域负责特定的业务职责。
|
|||
|
|
|
|||
|
|
**实现方式**:
|
|||
|
|
|
|||
|
|
- **实体(Entities)**:包含业务逻辑的核心对象
|
|||
|
|
- **值对象(Value Objects)**:不可变的数据对象
|
|||
|
|
- **聚合根(Aggregate Root)**:实体集合的统一入口
|
|||
|
|
- **仓储(Repository)**:数据访问的抽象层
|
|||
|
|
- **域服务(Domain Service)**:跨实体的业务逻辑
|
|||
|
|
- **域事件(Domain Event)**:业务状态变化的通知机制
|
|||
|
|
|
|||
|
|
**优势**:
|
|||
|
|
|
|||
|
|
- 业务逻辑与技术实现分离
|
|||
|
|
- 代码组织清晰,易于理解和维护
|
|||
|
|
- 支持复杂业务场景的建模
|
|||
|
|
|
|||
|
|
### 2. CQRS (Command Query Responsibility Segregation)
|
|||
|
|
|
|||
|
|
**理念**:将数据的读操作和写操作分离,优化不同场景下的性能需求。
|
|||
|
|
|
|||
|
|
**实现方式**:
|
|||
|
|
|
|||
|
|
- **命令端**:处理数据修改操作(Create、Update、Delete)
|
|||
|
|
- **查询端**:处理数据读取操作(Read、List、Search)
|
|||
|
|
- **读写模型分离**:不同的数据结构优化不同的操作
|
|||
|
|
|
|||
|
|
**优势**:
|
|||
|
|
|
|||
|
|
- 读写性能独立优化
|
|||
|
|
- 支持复杂查询需求
|
|||
|
|
- 易于实现缓存策略
|
|||
|
|
|
|||
|
|
### 3. 事件驱动架构 (Event-Driven Architecture)
|
|||
|
|
|
|||
|
|
**理念**:通过事件实现系统组件间的松耦合通信。
|
|||
|
|
|
|||
|
|
**实现方式**:
|
|||
|
|
|
|||
|
|
- **事件总线**:异步消息分发机制
|
|||
|
|
- **事件处理器**:响应特定事件的业务逻辑
|
|||
|
|
- **事件溯源**:通过事件重建系统状态
|
|||
|
|
|
|||
|
|
**优势**:
|
|||
|
|
|
|||
|
|
- 系统组件解耦
|
|||
|
|
- 支持异步处理
|
|||
|
|
- 易于扩展和集成
|
|||
|
|
|
|||
|
|
### 4. 六边形架构 (Hexagonal Architecture)
|
|||
|
|
|
|||
|
|
**理念**:将应用程序的核心逻辑与外部系统隔离,通过端口和适配器进行交互。
|
|||
|
|
|
|||
|
|
**实现方式**:
|
|||
|
|
|
|||
|
|
- **内层**:业务逻辑和域模型
|
|||
|
|
- **中层**:应用服务和用例
|
|||
|
|
- **外层**:适配器和基础设施
|
|||
|
|
|
|||
|
|
**优势**:
|
|||
|
|
|
|||
|
|
- 核心逻辑与技术实现解耦
|
|||
|
|
- 易于测试和替换组件
|
|||
|
|
- 支持多种接口类型
|
|||
|
|
|
|||
|
|
## 🛠️ 技术栈详解
|
|||
|
|
|
|||
|
|
### Web 框架层
|
|||
|
|
|
|||
|
|
#### Gin Framework
|
|||
|
|
|
|||
|
|
- **选择理由**:高性能、轻量级、丰富的中间件生态
|
|||
|
|
- **核心特性**:快速路由、中间件支持、JSON 绑定
|
|||
|
|
- **性能优势**:比其他 Go 框架快 40 倍,内存占用低
|
|||
|
|
|
|||
|
|
#### 中间件系统
|
|||
|
|
|
|||
|
|
- **CORS 中间件**:跨域资源共享控制
|
|||
|
|
- **认证中间件**:JWT token 验证和用户身份识别
|
|||
|
|
- **限流中间件**:API 调用频率控制,防止滥用
|
|||
|
|
- **日志中间件**:请求追踪和性能监控
|
|||
|
|
- **安全中间件**:HTTP 安全头部设置
|
|||
|
|
|
|||
|
|
### 数据层
|
|||
|
|
|
|||
|
|
#### PostgreSQL
|
|||
|
|
|
|||
|
|
- **选择理由**:强一致性、复杂查询支持、JSON 文档存储
|
|||
|
|
- **特性使用**:
|
|||
|
|
- JSONB 字段存储灵活数据
|
|||
|
|
- 全文搜索功能
|
|||
|
|
- 事务支持
|
|||
|
|
- 扩展生态(UUID、pg_trgm 等)
|
|||
|
|
|
|||
|
|
#### GORM
|
|||
|
|
|
|||
|
|
- **选择理由**:功能强大、活跃维护、Go 生态最佳
|
|||
|
|
- **核心特性**:
|
|||
|
|
- 自动迁移
|
|||
|
|
- 关联查询
|
|||
|
|
- 钩子函数
|
|||
|
|
- 事务支持
|
|||
|
|
- 连接池管理
|
|||
|
|
|
|||
|
|
#### Redis
|
|||
|
|
|
|||
|
|
- **使用场景**:
|
|||
|
|
- 应用缓存:查询结果缓存
|
|||
|
|
- 会话存储:用户登录状态
|
|||
|
|
- 限流计数:API 调用频率统计
|
|||
|
|
- 分布式锁:并发控制
|
|||
|
|
|
|||
|
|
### 基础设施层
|
|||
|
|
|
|||
|
|
#### 依赖注入 - Uber FX
|
|||
|
|
|
|||
|
|
- **优势**:
|
|||
|
|
- 编译时依赖检查
|
|||
|
|
- 生命周期管理
|
|||
|
|
- 模块化设计
|
|||
|
|
- 测试友好
|
|||
|
|
|
|||
|
|
#### 日志系统 - Zap
|
|||
|
|
|
|||
|
|
- **特性**:
|
|||
|
|
- 高性能结构化日志
|
|||
|
|
- 多级别日志控制
|
|||
|
|
- 灵活的输出格式
|
|||
|
|
- 生产环境优化
|
|||
|
|
|
|||
|
|
#### 配置管理 - Viper
|
|||
|
|
|
|||
|
|
- **支持格式**:YAML、JSON、ENV 等
|
|||
|
|
- **特性**:
|
|||
|
|
- 环境变量替换
|
|||
|
|
- 配置热重载
|
|||
|
|
- 多层级配置合并
|
|||
|
|
|
|||
|
|
### 监控和观测性
|
|||
|
|
|
|||
|
|
#### Prometheus + Grafana
|
|||
|
|
|
|||
|
|
- **Prometheus**:指标收集和存储
|
|||
|
|
- **Grafana**:数据可视化和告警
|
|||
|
|
- **监控指标**:
|
|||
|
|
- HTTP 请求量和延迟
|
|||
|
|
- 数据库连接池状态
|
|||
|
|
- 缓存命中率
|
|||
|
|
- 系统资源使用率
|
|||
|
|
|
|||
|
|
#### Jaeger
|
|||
|
|
|
|||
|
|
- **分布式链路追踪**:请求在系统中的完整路径
|
|||
|
|
- **性能分析**:识别性能瓶颈
|
|||
|
|
- **依赖图谱**:服务间依赖关系可视化
|
|||
|
|
|
|||
|
|
## 📁 架构分层
|
|||
|
|
|
|||
|
|
### 1. 表现层 (Presentation Layer)
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
cmd/api/ # 应用程序入口
|
|||
|
|
├── main.go # 主程序启动
|
|||
|
|
└── handlers/ # HTTP处理器
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**职责**:
|
|||
|
|
|
|||
|
|
- HTTP 请求处理
|
|||
|
|
- 请求验证和响应格式化
|
|||
|
|
- 路由定义和中间件配置
|
|||
|
|
|
|||
|
|
### 2. 应用层 (Application Layer)
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
internal/app/ # 应用协调
|
|||
|
|
├── app.go # 应用启动器
|
|||
|
|
└── container/ # 依赖注入容器
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**职责**:
|
|||
|
|
|
|||
|
|
- 应用程序生命周期管理
|
|||
|
|
- 依赖关系配置
|
|||
|
|
- 跨领域服务协调
|
|||
|
|
|
|||
|
|
### 3. 领域层 (Domain Layer)
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
internal/domains/ # 业务领域
|
|||
|
|
├── user/ # 用户领域
|
|||
|
|
│ ├── entities/ # 实体
|
|||
|
|
│ ├── services/ # 领域服务
|
|||
|
|
│ ├── repositories/ # 仓储接口
|
|||
|
|
│ ├── events/ # 领域事件
|
|||
|
|
│ └── dto/ # 数据传输对象
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**职责**:
|
|||
|
|
|
|||
|
|
- 业务逻辑实现
|
|||
|
|
- 领域模型定义
|
|||
|
|
- 业务规则验证
|
|||
|
|
|
|||
|
|
### 4. 基础设施层 (Infrastructure Layer)
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
internal/shared/ # 共享基础设施
|
|||
|
|
├── database/ # 数据库连接
|
|||
|
|
├── cache/ # 缓存服务
|
|||
|
|
├── events/ # 事件总线
|
|||
|
|
├── logger/ # 日志服务
|
|||
|
|
└── middleware/ # 中间件
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**职责**:
|
|||
|
|
|
|||
|
|
- 外部系统集成
|
|||
|
|
- 技术基础设施
|
|||
|
|
- 通用工具和服务
|
|||
|
|
|
|||
|
|
## 🔄 数据流向
|
|||
|
|
|
|||
|
|
### 请求处理流程
|
|||
|
|
|
|||
|
|
1. **HTTP 请求** → **路由器**
|
|||
|
|
2. **中间件链** → **认证/限流/日志**
|
|||
|
|
3. **处理器** → **请求验证**
|
|||
|
|
4. **应用服务** → **业务逻辑协调**
|
|||
|
|
5. **领域服务** → **业务规则执行**
|
|||
|
|
6. **仓储层** → **数据持久化**
|
|||
|
|
7. **事件总线** → **异步事件处理**
|
|||
|
|
8. **响应构建** → **HTTP 响应**
|
|||
|
|
|
|||
|
|
### 事件驱动流程
|
|||
|
|
|
|||
|
|
1. **业务操作** → **触发领域事件**
|
|||
|
|
2. **事件总线** → **异步分发事件**
|
|||
|
|
3. **事件处理器** → **响应事件处理**
|
|||
|
|
4. **副作用执行** → **缓存更新/通知发送**
|
|||
|
|
|
|||
|
|
## 🔒 安全设计
|
|||
|
|
|
|||
|
|
### 认证和授权
|
|||
|
|
|
|||
|
|
#### JWT Token 机制
|
|||
|
|
|
|||
|
|
- **访问令牌**:短期有效(24 小时)
|
|||
|
|
- **刷新令牌**:长期有效(7 天)
|
|||
|
|
- **无状态设计**:服务端无需存储会话
|
|||
|
|
|
|||
|
|
#### 安全中间件
|
|||
|
|
|
|||
|
|
- **CORS 保护**:跨域请求控制
|
|||
|
|
- **安全头部**:XSS、CSRF、点击劫持防护
|
|||
|
|
- **输入验证**:防止 SQL 注入和 XSS 攻击
|
|||
|
|
- **限流保护**:防止暴力破解和 DDoS
|
|||
|
|
|
|||
|
|
### 数据安全
|
|||
|
|
|
|||
|
|
#### 密码安全
|
|||
|
|
|
|||
|
|
- **Bcrypt 加密**:不可逆密码存储
|
|||
|
|
- **盐值随机**:防止彩虹表攻击
|
|||
|
|
- **密码策略**:强密码要求
|
|||
|
|
|
|||
|
|
#### 数据传输
|
|||
|
|
|
|||
|
|
- **HTTPS 强制**:加密数据传输
|
|||
|
|
- **API 版本控制**:向后兼容性
|
|||
|
|
- **敏感信息过滤**:日志脱敏
|
|||
|
|
|
|||
|
|
## 🚀 性能优化
|
|||
|
|
|
|||
|
|
### 缓存策略
|
|||
|
|
|
|||
|
|
#### 多级缓存
|
|||
|
|
|
|||
|
|
- **应用缓存**:查询结果缓存
|
|||
|
|
- **数据库缓存**:连接池和查询缓存
|
|||
|
|
- **CDN 缓存**:静态资源分发
|
|||
|
|
|
|||
|
|
#### 缓存模式
|
|||
|
|
|
|||
|
|
- **Cache-Aside**:应用控制缓存
|
|||
|
|
- **Write-Through**:同步写入缓存
|
|||
|
|
- **Write-Behind**:异步写入数据库
|
|||
|
|
|
|||
|
|
### 数据库优化
|
|||
|
|
|
|||
|
|
#### 连接池管理
|
|||
|
|
|
|||
|
|
- **最大连接数**:控制资源消耗
|
|||
|
|
- **空闲连接**:保持最小连接数
|
|||
|
|
- **连接超时**:防止连接泄露
|
|||
|
|
|
|||
|
|
#### 查询优化
|
|||
|
|
|
|||
|
|
- **索引策略**:覆盖常用查询
|
|||
|
|
- **分页查询**:避免大结果集
|
|||
|
|
- **预加载**:减少 N+1 查询问题
|
|||
|
|
|
|||
|
|
### 并发处理
|
|||
|
|
|
|||
|
|
#### Goroutine 池
|
|||
|
|
|
|||
|
|
- **有界队列**:控制并发数量
|
|||
|
|
- **优雅降级**:过载保护机制
|
|||
|
|
- **超时控制**:防止资源泄露
|
|||
|
|
|
|||
|
|
## 🧪 可测试性
|
|||
|
|
|
|||
|
|
### 测试策略
|
|||
|
|
|
|||
|
|
#### 单元测试
|
|||
|
|
|
|||
|
|
- **Mock 接口**:隔离外部依赖
|
|||
|
|
- **测试覆盖**:核心业务逻辑 100%覆盖
|
|||
|
|
- **快速反馈**:毫秒级测试执行
|
|||
|
|
|
|||
|
|
#### 集成测试
|
|||
|
|
|
|||
|
|
- **Testcontainers**:真实数据库环境
|
|||
|
|
- **API 测试**:端到端功能验证
|
|||
|
|
- **并发测试**:竞态条件检测
|
|||
|
|
|
|||
|
|
#### 测试工具
|
|||
|
|
|
|||
|
|
- **Testify**:断言和 Mock 框架
|
|||
|
|
- **GoConvey**:BDD 风格测试
|
|||
|
|
- **Ginkgo**:规范化测试结构
|
|||
|
|
|
|||
|
|
## 🔧 可维护性
|
|||
|
|
|
|||
|
|
### 代码组织
|
|||
|
|
|
|||
|
|
#### 包结构设计
|
|||
|
|
|
|||
|
|
- **按功能分包**:清晰的职责边界
|
|||
|
|
- **依赖方向**:依赖倒置原则
|
|||
|
|
- **接口隔离**:最小化接口暴露
|
|||
|
|
|
|||
|
|
#### 编码规范
|
|||
|
|
|
|||
|
|
- **Go 官方规范**:gofmt、golint 标准
|
|||
|
|
- **命名约定**:一致的命名风格
|
|||
|
|
- **注释文档**:完整的 API 文档
|
|||
|
|
|
|||
|
|
### 配置管理
|
|||
|
|
|
|||
|
|
#### 环境分离
|
|||
|
|
|
|||
|
|
- **开发环境**:详细日志、调试工具
|
|||
|
|
- **测试环境**:稳定配置、自动化测试
|
|||
|
|
- **生产环境**:性能优化、安全加固
|
|||
|
|
|
|||
|
|
#### 配置热更新
|
|||
|
|
|
|||
|
|
- **文件监控**:配置文件变化检测
|
|||
|
|
- **优雅重启**:无停机配置更新
|
|||
|
|
- **回滚机制**:配置错误恢复
|
|||
|
|
|
|||
|
|
## 🌐 可扩展性
|
|||
|
|
|
|||
|
|
### 水平扩展
|
|||
|
|
|
|||
|
|
#### 无状态设计
|
|||
|
|
|
|||
|
|
- **会话外置**:Redis 存储用户状态
|
|||
|
|
- **负载均衡**:多实例部署
|
|||
|
|
- **自动伸缩**:基于指标的扩缩容
|
|||
|
|
|
|||
|
|
#### 数据库扩展
|
|||
|
|
|
|||
|
|
- **读写分离**:主从复制架构
|
|||
|
|
- **分库分表**:水平分片策略
|
|||
|
|
- **缓存预热**:减少数据库压力
|
|||
|
|
|
|||
|
|
### 服务拆分
|
|||
|
|
|
|||
|
|
#### 微服务就绪
|
|||
|
|
|
|||
|
|
- **领域边界**:清晰的服务边界
|
|||
|
|
- **API 网关**:统一入口和路由
|
|||
|
|
- **服务发现**:动态服务注册
|
|||
|
|
|
|||
|
|
#### 通信机制
|
|||
|
|
|
|||
|
|
- **REST API**:同步通信标准
|
|||
|
|
- **消息队列**:异步解耦通信
|
|||
|
|
- **事件溯源**:状态重建机制
|
|||
|
|
|
|||
|
|
## 📈 监控和运维
|
|||
|
|
|
|||
|
|
### 可观测性三大支柱
|
|||
|
|
|
|||
|
|
#### 日志 (Logging)
|
|||
|
|
|
|||
|
|
- **结构化日志**:JSON 格式便于检索
|
|||
|
|
- **日志级别**:灵活的详细程度控制
|
|||
|
|
- **日志聚合**:集中式日志管理
|
|||
|
|
|
|||
|
|
#### 指标 (Metrics)
|
|||
|
|
|
|||
|
|
- **业务指标**:用户行为和业务 KPI
|
|||
|
|
- **技术指标**:系统性能和资源使用
|
|||
|
|
- **SLI/SLO**:服务水平指标和目标
|
|||
|
|
|
|||
|
|
#### 链路追踪 (Tracing)
|
|||
|
|
|
|||
|
|
- **请求追踪**:完整的请求处理路径
|
|||
|
|
- **性能分析**:识别瓶颈和优化点
|
|||
|
|
- **依赖分析**:服务间调用关系
|
|||
|
|
|
|||
|
|
### 运维自动化
|
|||
|
|
|
|||
|
|
#### 健康检查
|
|||
|
|
|
|||
|
|
- **多层级检查**:应用、数据库、缓存
|
|||
|
|
- **智能告警**:基于阈值的自动通知
|
|||
|
|
- **故障恢复**:自动重启和故障转移
|
|||
|
|
|
|||
|
|
#### 部署策略
|
|||
|
|
|
|||
|
|
- **蓝绿部署**:零停机更新
|
|||
|
|
- **滚动更新**:渐进式版本发布
|
|||
|
|
- **回滚机制**:快速恢复到稳定版本
|
|||
|
|
|
|||
|
|
## 🚀 未来演进方向
|
|||
|
|
|
|||
|
|
### 技术演进
|
|||
|
|
|
|||
|
|
#### 云原生
|
|||
|
|
|
|||
|
|
- **容器化**:Docker 标准化部署
|
|||
|
|
- **编排平台**:Kubernetes 集群管理
|
|||
|
|
- **服务网格**:Istio 流量治理
|
|||
|
|
|
|||
|
|
#### 新技术集成
|
|||
|
|
|
|||
|
|
- **GraphQL**:灵活的 API 查询语言
|
|||
|
|
- **gRPC**:高性能 RPC 通信
|
|||
|
|
- **WebAssembly**:高性能计算扩展
|
|||
|
|
|
|||
|
|
### 架构演进
|
|||
|
|
|
|||
|
|
#### 事件溯源
|
|||
|
|
|
|||
|
|
- **完整事件历史**:业务状态重建
|
|||
|
|
- **审计日志**:合规性和追溯性
|
|||
|
|
- **时间旅行**:历史状态查询
|
|||
|
|
|
|||
|
|
#### CQRS 进阶
|
|||
|
|
|
|||
|
|
- **独立数据存储**:读写数据库分离
|
|||
|
|
- **最终一致性**:分布式数据同步
|
|||
|
|
- **投影视图**:优化的查询模型
|
|||
|
|
|
|||
|
|
这个架构设计文档展示了 TYAPI Server 的完整技术架构和设计理念,为开发团队提供了全面的技术指导和最佳实践参考。
|