Files
ops2/backend/ai_work/ARCHITECTURE.md
T
2026-04-01 12:09:02 +08:00

5.3 KiB
Raw Blame History

OPS 后端重构架构设计文档

当前状态

已完成基础架构重构 新目录结构已创建 配置管理模块完成 数据库连接层完成 响应统一处理完成

目录结构

backend/
├── cmd/                       # 入口点
│   └── ops-server/           # 主应用程序入口
│       └── main.go
├── internal/                 # 私有应用程序代码
│   ├── config/               # 配置管理
│   │   ├── config.go         # 配置结构定义
│   │   └── [其他配置组件]
│   ├── database/             # 数据库层
│   │   ├── connection.go     # 数据库连接
│   │   └── migration.go      # 数据库迁移和模型定义
│   ├── models/               # 数据模型(待重构)
│   ├── repository/           # 数据访问层(待创建)
│   │   ├── user_repository.go
│   │   ├── purchase_repository.go
│   │   └── file_repository.go
│   ├── service/              # 业务逻辑层(待创建)
│   │   ├── auth_service.go
│   │   ├── purchase_service.go
│   │   └── file_service.go
│   ├── handler/              # HTTP处理器(待创建)
│   │   ├── auth_handler.go
│   │   ├── purchase_handler.go
│   │   └── file_handler.go
│   ├── middleware/           # 中间件(待创建)
│   │   ├── auth.go
│   │   ├── logging.go
│   │   └── recovery.go
│   └── pkg/                  # 内部公共库(待创建)
│       ├── errors/
│       ├── validation/
│       └── utils/
├── api/                      # API定义(待创建)
│   └── v1/
│       └── routes.go
├── pkg/                      # 公共库
│   └── response/
│       └── response.go       # API响应统一处理
├── data/                     # 数据目录(配置文件、数据库)
├── defConfig/                # 默认配置模板
├── dist/                     # 前端构建产物(编译后)
└── tests/                    # 测试文件

主要改进

1. 配置管理重构

旧方案问题:

  • 使用全局变量 var Configs map[string]interface{}
  • 使用奇怪的命名如 ConfigsWed, ConfigsFile
  • 拼写错误:Pahts 应该是 Paths
  • 缺少类型安全和验证

新方案:

  • 使用结构体定义配置,支持类型安全
  • 支持默认配置自动生成
  • 支持热重载(未来扩展)
  • 统一配置路径管理

2. 数据库层重构

旧方案问题:

  • 直接在路由层进行数据库操作
  • 缺少连接池配置
  • 错误处理不一致

新方案:

  • 集中管理数据库连接
  • 自动连接池配置
  • 支持多种数据库(SQLite/MySQL/PostgreSQL
  • 统一错误处理

3. 错误处理统一

旧方案问题:

  • 混合使用 panic、return error 和日志
  • HTTP 响应格式不一致
  • 错误码管理混乱

新方案:

  • 统一 API 响应格式
  • 标准错误码映射
  • 结构化错误信息
  • 详细的 HTTP 状态码

4. 中间件系统

新功能:

  • CORS 跨域支持
  • 请求日志记录
  • 认证中间件
  • 性能监控
  • 限流保护

迁移步骤

第一阶段:基础架构

  • 创建新的目录结构
  • 重构配置管理模块
  • 重构数据库连接层
  • 创建统一响应处理

第二阶段:数据访问层

  • 创建 Repository 层
  • 迁移用户相关数据访问
  • 迁移采购订单数据访问
  • 迁移文件管理数据访问

第三阶段:业务逻辑层

  • 创建 Service 层
  • 迁移用户认证逻辑
  • 迁移采购订单管理逻辑
  • 迁移文件上传逻辑

第四阶段:HTTP 层

  • 创建 Handler 层
  • 迁移用户认证 API
  • 迁移采购订单 API
  • 迁移文件管理 API

第五阶段:中间件和测试

  • 创建中间件系统
  • 添加单元测试
  • 添加集成测试
  • 性能测试

运行说明

准备步骤

  1. 运行配置迁移脚本:
python migrate-config.py
  1. 检查前端构建:
# 确保前端已构建,在frontend目录中运行
npm run build
# 或手动复制dist目录到backend/dist
  1. 启动新版本服务器:
# Windows
.\start-dev.bat

# Linux/Mac
go run ./cmd/ops-server/main.go

迁移过程中的注意事项

  1. 保持向后兼容:逐步迁移,确保 API 接口不变
  2. 数据库数据安全:旧数据库文件会自动迁移
  3. 配置文件备份:迁移前自动备份旧配置
  4. 增量测试:每次迁移后测试新功能

API 兼容性保证

保持不变的接口

  • 用户登录:POST /api/users/login
  • 用户注册:POST /api/users/register
  • 获取采购订单:GET /api/purchase/orders
  • 上传文件:POST /api/files/upload

响应的格式统一

{
  "code": "0",        // 错误码,0表示成功
  "message": "Success", // 人类可读的消息
  "data": {}          // 实际数据
}

性能改进目标

  1. 响应时间:平均 < 200ms
  2. 并发连接:支持 1000+ 并发
  3. 内存使用< 200MB
  4. 启动时间< 5s

监控和日志

  • 结构化日志输出
  • 请求追踪ID
  • 性能指标收集
  • 错误聚合报告