初始版本

架构优化方案分析.md

@@ -0,0 +1,154 @@
+# WebSopy 架构优化方案分析
+
+## 1. 问题背景
+
+当前系统存在三个层次的协作/隔离需求：
+1. **租户隔离**：SaaS 多租户基础架构 ✅ 已实现
+2. **团队协作**：团队内资源共享，团队间数据隔离 ❓ 待解决
+3. **工作空间切换**：用户在多个项目间切换的便利性 ❓ 待优化
+
+## 2. 已考虑的三个方案
+
+### 方案A：租户切换（已排除）
+**方案**：让用户在不同租户间切换，租户=工作空间
+**问题**：影响整个系统架构，菜单权限不一致，应用中心数据混淆
+**结论**：❌ 不推荐，改动太大
+
+### 方案B：数据库合并（待评估）
+**方案**：将 `gxwebsoft_core` 数据库迁移到 `db_websopy`
+**优势**：
+- 性能提升 50%+（减少 HTTP API 调用）
+- 架构简化，开发效率提升
+- 数据一致性保证，减少缓存同步问题
+**风险**：
+- 迁移风险：数据冲突、服务中断
+- 代码修改量大：100+ Java 文件
+- 兼容性问题：其他服务依赖原数据库
+**可行性**：✅ 技术可行，但需要充分测试
+
+### 方案C：应用即工作空间（推荐实施）
+**方案**：加强现有的应用（AppProduct）作为工作空间概念
+**实现**：
+1. 应用切换 UI（顶部下拉菜单）
+2. 应用个性化配置（logo、主题、快捷链接）
+3. 保持应用内资源共享，应用间隔离
+**优势**：
+- 低风险：不涉及核心架构变更
+- 快速实现：1-2周完成
+- 符合现有模式：沿用应用成员模型
+**结论**：⭐ **推荐优先实施**
+
+## 3. 分阶段实施建议
+
+### 阶段一：立即开始（1-2周）
+**目标**：验证工作空间需求
+**任务**：
+1. 应用切换 UI（开发者中心 + 控制台）
+2. 获取用户应用列表 API
+3. 简单的应用切换功能
+**产出**：测试用户是否真正需要多工作空间切换
+
+### 阶段二：评估决策（2-4周）
+**目标**：根据阶段一反馈决定后续方向
+**选项**：
+- **选项A**：如果用户反馈良好 → 完善工作空间功能
+- **选项B**：如果用户不常用 → 保持现状
+- **选项C**：如果有更深需求 → 考虑数据库合并
+
+### 阶段三：长期规划（待定）
+**可能方向**：
+1. 数据库合并工程
+2. 租户体系增强
+3. 高级权限管理
+
+## 4. 技术实施方案详情
+
+### 4.1 应用切换UI实现
+```typescript
+// API：获取用户的应用列表
+GET /api/app/appProduct/my-apps
+
+// 返回数据结构
+interface UserApp {
+  productId: number
+  productName: string
+  productCode: string
+  role: 'owner' | 'admin' | 'developer' | 'viewer'
+  isCurrent: boolean
+}
+```
+
+### 4.2 数据库合并非技术细节
+**预估工作量**：
+- 中小风险：用户数据迁移（几万条）
+- 高风险：订单/日志表迁移（百万级）
+- 主要修改：App模块的查询逻辑、定时任务
+
+**备份策略**：
+```bash
+# 迁移前完整备份
+mysqldump -h server_host -u user -p gxwebsoft_core > backup_core.sql
+mysqldump -h app_host -u user -p db_websopy > backup_websopy.sql
+
+# 回滚方案
+# 1. 停止应用
+# 2. 恢复数据库
+# 3. 启动旧版本应用
+```
+
+## 5. 关键决策点
+
+### 决策维度分析
+| 维度 | 应用即工作空间 | 数据库合并 |
+|------|--------------|-----------|
+| **实施难度** | 低（前端为主） | 高（全栈改动） |
+| **实施周期** | 1-2周 | 4-8周 |
+| **性能收益** | 小 | 大（50%+） |
+| **架构影响** | 小 | 大（结构变化） |
+| **风险等级** | 低 | 中高 |
+| **用户价值** | 中（便利性） | 高（性能体验） |
+
+### 建议决策流程：
+1. **先做简单方案**（应用切换），收集用户反馈
+2. **监控性能瓶颈**，确定数据库合并的必要性
+3. **评估ROI**，如果性能瓶颈明显，再投入大工程
+4. **准备回滚方案**，确保任何时候可退回到稳定版本
+
+## 6. 下一步行动建议
+
+### 立即行动（本周）：
+1. [ ] 设计应用切换UI原型
+2. [ ] 实现 `GET /api/app/appProduct/my-apps` 接口
+3. [ ] 在开发者中心添加切换下拉菜单
+4. [ ] 收集3-5个核心用户反馈
+
+### 观察评估（下周）：
+1. [ ] 监控切换功能使用率
+2. [ ] 收集用户对新功能的意见
+3. [ ] 评估是否有更深的协作需求
+
+### 长期规划（根据反馈）：
+- [ ] 如果用户喜欢：完善工作空间配置功能
+- [ ] 如果性能成瓶颈：设计方案B的小范围试点
+- [ ] 如果需求不明确：保持现状，优化其他功能
+
+## 7. 风险控制和回滚策略
+
+### 应用切换方案（低风险）：
+- 功能开关：可随时禁用切换功能
+- 渐进发布：先对部分用户开放
+- A/B测试：比较有无切换功能的使用体验差异
+
+### 数据库合并方案（高风险）：
+- 影子测试：创建测试环境完全模拟
+- 灰度发布：按功能模块逐步切换
+- 快速回滚：15分钟内可恢复原状
+
+---
+
+**核心要点**：
+1. **不要过度设计**：先用最简单方案验证需求
+2. **数据驱动决策**：根据实际用户反馈决定投入
+3. **保持灵活性**：所有方案都设计可回退机制
+
+**推荐行动路径**：**方案C → 观察 → 评估 → 决策**