Xiaoxia AI
b5a62ee9a3
- domain: User, Workspace, Project, AssetLibrary, Asset, IngestJob - ports: repository interfaces - application: use cases - adapters: in-memory - API: FastAPI 5 routes - worker: Celery ingest_asset - tests: 4 passing
264 lines
5.2 KiB
Markdown
264 lines
5.2 KiB
Markdown
# 基础设施保留 / 废弃 / 重建清单（第一版）
|
||
|
||
本文档定义新 SaaS 项目启动时，哪些基础设施继续保留，哪些只保留经验不保留实现，哪些必须全新重建。
|
||
|
||
---
|
||
|
||
## 1. 分类原则
|
||
|
||
基础设施分为三类：
|
||
|
||
1. **保留**：直接作为新项目资产继续使用
|
||
2. **废弃实现，仅保留经验**：旧实现不进入新主线，但经验可复用
|
||
3. **必须重建**：新 SaaS 需要重新搭建
|
||
|
||
---
|
||
|
||
## 2. 保留清单
|
||
|
||
### 2.1 代码仓库
|
||
|
||
- **保留项**：Gitea
|
||
- **原因**：已经是稳定的代码真相源，具备提交、历史、协作、推送能力
|
||
- **新项目做法**：新 SaaS 使用新的独立仓库或独立主目录，不与旧桌面版混线
|
||
|
||
### 2.2 CI/CD 思路和经验
|
||
|
||
- **保留项**：自动检查、测试、构建、发布的工程理念
|
||
- **原因**：这是正规软件必须保留的工程资产
|
||
- **新项目做法**：重建适合 Web/SaaS 的流水线
|
||
|
||
### 2.3 巡检机器人思路
|
||
|
||
- **保留项**：巡检、告警、状态监控思路
|
||
- **原因**：线上系统比桌面工具更需要健康巡检
|
||
- **新项目做法**：转为 SaaS 服务、任务、队列、磁盘、worker 的巡检
|
||
|
||
### 2.4 服务器与开发环境
|
||
|
||
- **保留项**：Windows 开发机、Ubuntu 服务器
|
||
- **原因**：开发和部署基础已有
|
||
- **新项目做法**：重新按 SaaS 需要规划开发/测试/生产用途
|
||
|
||
---
|
||
|
||
## 3. 旧实现废弃，但经验保留
|
||
|
||
### 3.1 Tkinter 桌面 UI 工程结构
|
||
|
||
- **旧实现**：Tkinter 主窗口 + 单体 GUI 文件
|
||
- **处理方式**：废弃为新主线实现
|
||
- **保留经验**：哪些业务交互复杂、哪些模块最容易耦合
|
||
|
||
### 3.2 安装版同步 / 发布脚本
|
||
|
||
- **旧实现**：`deploy_to_installed.py`、安装版同步链
|
||
- **处理方式**：不带入新 SaaS 主线
|
||
- **保留经验**：发布必须有清单、运行时文件必须明确登记
|
||
|
||
### 3.3 桌面版更新体系
|
||
|
||
- **旧实现**：本地补丁、manifest、rollback
|
||
- **处理方式**：不直接复用
|
||
- **保留经验**：版本状态、回滚、失败恢复、补丁安全校验思路
|
||
|
||
### 3.4 临时修复脚本文化
|
||
|
||
- **旧实现**：一批为临时问题而生的脚本
|
||
- **处理方式**：明确不继承到新主线
|
||
- **保留经验**：哪些问题容易高频复发，需要产品级能力解决
|
||
|
||
---
|
||
|
||
## 4. 必须重建的基础设施
|
||
|
||
### 4.1 新项目仓库结构
|
||
|
||
必须重建：
|
||
|
||
- 新仓库目录结构
|
||
- 前后端分层结构
|
||
- 文档结构
|
||
- 基础模块布局
|
||
|
||
### 4.2 Web/SaaS CI/CD 流水线
|
||
|
||
必须重建：
|
||
|
||
- 前端构建
|
||
- 后端测试
|
||
- 镜像/部署包构建
|
||
- 测试环境部署
|
||
- 正式环境部署
|
||
- 回滚流程
|
||
|
||
### 4.3 鉴权体系
|
||
|
||
必须重建：
|
||
|
||
- 用户认证
|
||
- 会话管理
|
||
- 权限控制
|
||
- 团队/工作区边界（如果需要）
|
||
|
||
### 4.4 存储体系
|
||
|
||
必须重建：
|
||
|
||
- 对象存储 / 素材存储方案
|
||
- 数据库存储方案
|
||
- 结果文件管理方案
|
||
- 清理和归档策略
|
||
|
||
### 4.5 任务体系
|
||
|
||
必须重建：
|
||
|
||
- 任务队列
|
||
- 异步生成任务
|
||
- 重试机制
|
||
- 状态追踪
|
||
- worker 管理
|
||
|
||
### 4.6 观测性体系
|
||
|
||
必须重建：
|
||
|
||
- 日志
|
||
- 指标
|
||
- 告警
|
||
- 错误追踪
|
||
- 健康检查
|
||
|
||
### 4.7 配置与密钥管理
|
||
|
||
必须重建：
|
||
|
||
- 环境变量规范
|
||
- 密钥注入方式
|
||
- 不同环境配置管理
|
||
- 敏感信息隔离
|
||
|
||
---
|
||
|
||
## 5. 项目推进器要不要
|
||
|
||
### 结论
|
||
|
||
要，但先轻量，不要一开始就搞太重。
|
||
|
||
### 轻量方案即可支撑初期
|
||
|
||
- 需求清单
|
||
- 里程碑
|
||
- issue / 任务列表
|
||
- 发布记录
|
||
- 架构文档
|
||
|
||
### 暂时不需要的重型能力
|
||
|
||
- 复杂流程引擎
|
||
- 重度项目管理系统
|
||
- 过度自动化的工单流转
|
||
|
||
---
|
||
|
||
## 6. 巡检机器人要不要
|
||
|
||
### 结论
|
||
|
||
要保留，而且未来价值更大。
|
||
|
||
### 在新 SaaS 中的职责
|
||
|
||
巡检机器人未来可以检查：
|
||
|
||
- API 服务是否在线
|
||
- 队列是否堆积
|
||
- worker 是否离线
|
||
- 生成失败率是否异常
|
||
- 存储空间是否异常
|
||
- 数据库连接是否异常
|
||
- 定时任务是否失效
|
||
|
||
### 定位
|
||
|
||
- 它是运维和健康检查系统的一部分
|
||
- 不是业务开发主流程的一部分
|
||
|
||
---
|
||
|
||
## 7. CI/CD 要不要
|
||
|
||
### 结论
|
||
|
||
必须保留，而且必须升级。
|
||
|
||
### 新 SaaS 项目里必须具备的能力
|
||
|
||
- 代码检查
|
||
- 自动测试
|
||
- 构建
|
||
- 测试环境部署
|
||
- 正式环境部署
|
||
- 回滚
|
||
|
||
### 原则
|
||
|
||
- 新项目不能没有 CI/CD
|
||
- 但 CI/CD 流程必须服务于 SaaS，不是延用桌面版套路
|
||
|
||
---
|
||
|
||
## 8. 当前建议的基础设施策略
|
||
|
||
### 立即保留
|
||
|
||
- Gitea
|
||
- 现有 CI/CD 思路
|
||
- 巡检机器人思路
|
||
- 服务器资源
|
||
|
||
### 立即停止依赖旧实现
|
||
|
||
- 桌面版发布链
|
||
- 安装同步链
|
||
- Tkinter 工程结构
|
||
- 临时修复脚本文化
|
||
|
||
### 接下来优先重建
|
||
|
||
1. 新项目仓库结构
|
||
2. SaaS CI/CD
|
||
3. 鉴权体系
|
||
4. 存储体系
|
||
5. 任务体系
|
||
6. 观测性体系
|
||
|
||
---
|
||
|
||
## 9. 当前阶段结论
|
||
|
||
新 SaaS 项目不是从零开始，因为我们有：
|
||
|
||
- 仓库
|
||
- CI/CD 经验
|
||
- 巡检经验
|
||
- 服务器
|
||
- 业务规则
|
||
- 稳定性治理经验
|
||
|
||
但新 SaaS 也不能“沿用旧系统实现”，因为：
|
||
|
||
- 桌面架构不适合作为未来主线
|
||
- 发布方式完全不同
|
||
- 任务模型完全不同
|
||
- 存储模型完全不同
|
||
- 用户和权限模型未来也会不同
|
||
|
||
所以正确策略是：
|
||
|
||
- **保留资产**
|
||
- **废弃旧实现**
|
||
- **重建 SaaS 所需基础设施**
|