154 lines
5.0 KiB
Markdown
154 lines
5.0 KiB
Markdown
# 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 → 观察 → 评估 → 决策** |