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
5.2 KiB
5.2 KiB
基础设施保留 / 废弃 / 重建清单（第一版）
本文档定义新 SaaS 项目启动时，哪些基础设施继续保留，哪些只保留经验不保留实现，哪些必须全新重建。
1. 分类原则
基础设施分为三类：
- 保留：直接作为新项目资产继续使用
- 废弃实现，仅保留经验：旧实现不进入新主线，但经验可复用
- 必须重建：新 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 工程结构
- 临时修复脚本文化
接下来优先重建
- 新项目仓库结构
- SaaS CI/CD
- 鉴权体系
- 存储体系
- 任务体系
- 观测性体系
9. 当前阶段结论
新 SaaS 项目不是从零开始，因为我们有：
- 仓库
- CI/CD 经验
- 巡检经验
- 服务器
- 业务规则
- 稳定性治理经验
但新 SaaS 也不能“沿用旧系统实现”，因为：
- 桌面架构不适合作为未来主线
- 发布方式完全不同
- 任务模型完全不同
- 存储模型完全不同
- 用户和权限模型未来也会不同
所以正确策略是：
- 保留资产
- 废弃旧实现
- 重建 SaaS 所需基础设施