HaHafeng
e52020409c
- System architecture and design documentation - Business module docs (ASL/AIA/PKB/RVW/DC/SSA/ST) - ASL module complete design (quality assurance, tech selection) - Platform layer and common capabilities docs - Development standards and API specifications - Deployment and operations guides - Project management and milestone tracking - Architecture implementation reports - Documentation templates and guides
940 lines
26 KiB
Markdown
940 lines
26 KiB
Markdown
# 系统架构分层设计
|
||
|
||
> **文档版本：** v1.0
|
||
> **创建日期：** 2025-11-06
|
||
> **最后更新：** 2025-11-06
|
||
> **文档状态：** 架构设计中
|
||
> **作者：** 技术架构师
|
||
|
||
---
|
||
|
||
## 📋 文档说明
|
||
|
||
本文档是壹证循AI科研平台的**核心架构设计文档**，定义了：
|
||
1. **总体架构**：平台级的基础设施和通用能力
|
||
2. **业务模块**：各个独立的产品模块
|
||
3. **可复用能力**：跨模块共享的技术能力
|
||
4. **模块独立性**：如何支持模块独立部署和销售
|
||
|
||
**核心设计原则：**
|
||
- ✅ **总体与模块分离**：平台基础设施与业务模块清晰分层
|
||
- ✅ **能力可复用**：通用能力在平台层统一提供
|
||
- ✅ **模块可独立**：任何模块都可以独立部署和销售
|
||
- ✅ **架构可演进**：从单体到微服务平滑演进
|
||
|
||
---
|
||
|
||
## 🏗️ 架构分层总览
|
||
|
||
### 三层架构
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ 业务模块层（Product Layer） │
|
||
│ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │
|
||
│ │ AIA │ │ ASL │ │ PKB │ │ DC │ │ SSA │ … │
|
||
│ │智能问答│ │智能文献│ │知识库 │ │数据清洗│ │智能统计│ │
|
||
│ └────────┘ └────────┘ └────────┘ └────────┘ └────────┘ │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
↓ 依赖
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ 通用能力层（Capability Layer） │
|
||
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
|
||
│ │LLM网关 │ │文档处理 │ │RAG引擎 │ │数据ETL │ … │
|
||
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
↓ 依赖
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ 平台基础层（Platform Layer） │
|
||
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
|
||
│ │用户权限 │ │存储服务 │ │通知服务 │ │监控日志 │ … │
|
||
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 📐 第一层：平台基础层（Platform Layer）
|
||
|
||
### 定义
|
||
|
||
**平台基础层是所有业务模块的地基，提供通用的基础设施能力。**
|
||
|
||
### 核心特征
|
||
|
||
- ✅ **全局唯一**：整个平台只有一套
|
||
- ✅ **业务无关**：不涉及具体业务逻辑
|
||
- ✅ **强依赖性**：所有业务模块都必须依赖
|
||
- ✅ **稳定性高**：很少变动
|
||
|
||
### 包含的模块
|
||
|
||
#### 1. 用户与权限中心（UAM）
|
||
|
||
**职责：**
|
||
- 用户注册、登录、认证（JWT）
|
||
- 用户信息管理
|
||
- 角色与权限管理（RBAC）
|
||
- 多租户管理（SaaS版）
|
||
- Feature Flag控制（版本权限）
|
||
|
||
**数据表：**
|
||
```typescript
|
||
// 平台层Schema: platform_schema
|
||
- users // 用户基础信息
|
||
- roles // 角色定义
|
||
- permissions // 权限定义
|
||
- user_roles // 用户-角色关联
|
||
- role_permissions // 角色-权限关联
|
||
- tenants // 租户（SaaS多租户）
|
||
- feature_flags // Feature Flag配置
|
||
```
|
||
|
||
**API示例：**
|
||
```
|
||
POST /api/auth/register // 注册
|
||
POST /api/auth/login // 登录
|
||
GET /api/users/me // 获取当前用户
|
||
PUT /api/users/me // 更新用户信息
|
||
GET /api/users/permissions // 获取用户权限
|
||
GET /api/users/feature-flags // 获取用户Feature Flag
|
||
```
|
||
|
||
---
|
||
|
||
#### 2. 存储服务（Storage Service）
|
||
|
||
**职责：**
|
||
- 文件上传、下载、删除
|
||
- 对象存储（OSS/S3）
|
||
- 本地文件系统（单机版）
|
||
- 文件权限控制
|
||
|
||
**技术方案：**
|
||
```typescript
|
||
// 云端版：MinIO/阿里云OSS
|
||
// 单机版：本地文件系统
|
||
|
||
interface StorageService {
|
||
upload(file: File, path: string): Promise<string>; // 上传，返回URL
|
||
download(url: string): Promise<Buffer>; // 下载
|
||
delete(url: string): Promise<void>; // 删除
|
||
getSignedUrl(url: string, expiresIn: number): string; // 获取临时访问URL
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
#### 3. 通知服务（Notification Service）
|
||
|
||
**职责：**
|
||
- 站内消息
|
||
- 邮件通知
|
||
- WebSocket实时推送
|
||
|
||
**数据表：**
|
||
```typescript
|
||
// 平台层Schema: platform_schema
|
||
- notifications // 通知记录
|
||
- notification_templates // 通知模板
|
||
```
|
||
|
||
**API示例：**
|
||
```
|
||
GET /api/notifications // 获取通知列表
|
||
POST /api/notifications/:id/read // 标记已读
|
||
```
|
||
|
||
---
|
||
|
||
#### 4. 监控与日志（Monitoring & Logging）
|
||
|
||
**职责：**
|
||
- 操作日志
|
||
- 错误日志
|
||
- 性能监控
|
||
- 审计日志（合规要求）
|
||
|
||
**数据表：**
|
||
```typescript
|
||
// 平台层Schema: platform_schema
|
||
- admin_logs // 管理员操作日志
|
||
- error_logs // 错误日志
|
||
- audit_logs // 审计日志（合规）
|
||
```
|
||
|
||
---
|
||
|
||
#### 5. 系统配置（System Config）
|
||
|
||
**职责：**
|
||
- 系统级配置管理
|
||
- 多环境配置（开发、测试、生产）
|
||
- 动态配置更新
|
||
|
||
**数据表：**
|
||
```typescript
|
||
// 平台层Schema: platform_schema
|
||
- system_configs // 系统配置
|
||
```
|
||
|
||
---
|
||
|
||
## 🔧 第二层：通用能力层（Capability Layer）
|
||
|
||
### 定义
|
||
|
||
**通用能力层是跨业务模块共享的核心技术能力，是业务逻辑的基础。**
|
||
|
||
### 核心特征
|
||
|
||
- ✅ **可复用**：多个业务模块共享
|
||
- ✅ **业务相关**：包含领域知识
|
||
- ✅ **独立部署**：可以独立为微服务
|
||
- ✅ **高内聚**：每个能力职责单一
|
||
|
||
### 包含的能力
|
||
|
||
#### 1. LLM大模型网关（LLM Gateway）⭐⭐⭐⭐⭐ **核心**
|
||
|
||
**职责：**
|
||
- 统一管理所有LLM调用
|
||
- 根据用户版本动态切换模型
|
||
- 成本控制与限流
|
||
- Token计数与计费
|
||
|
||
**核心价值：**
|
||
```
|
||
这是商业模式的技术保障：
|
||
- 基础版：只能用DeepSeek-V3（便宜）
|
||
- 高级版：可用DeepSeek + Qwen3
|
||
- 旗舰版：可用DeepSeek + Qwen3 + Qwen-Long + Claude
|
||
|
||
成本控制：
|
||
- 统一监控所有LLM API调用
|
||
- 超出配额自动限流
|
||
- 按版本计费
|
||
```
|
||
|
||
**技术架构：**
|
||
```typescript
|
||
// LLM Gateway统一入口
|
||
interface LLMGateway {
|
||
// 调用LLM
|
||
chat(params: {
|
||
userId: string;
|
||
modelType?: 'deepseek-v3' | 'qwen3' | 'qwen-long' | 'claude';
|
||
messages: Message[];
|
||
stream?: boolean;
|
||
}): Promise<ChatResponse>;
|
||
|
||
// 根据用户版本选择模型
|
||
selectModel(userId: string, preferredModel?: string): string;
|
||
|
||
// 检查配额
|
||
checkQuota(userId: string): Promise<{ allowed: boolean; remaining: number }>;
|
||
|
||
// Token计数
|
||
countTokens(text: string): number;
|
||
}
|
||
```
|
||
|
||
**数据表：**
|
||
```typescript
|
||
// 通用能力Schema: capability_schema
|
||
- llm_usage_logs // LLM使用日志
|
||
- llm_quotas // 用户配额
|
||
```
|
||
|
||
**为什么是通用能力？**
|
||
- ✅ AIA模块需要（AI智能问答）
|
||
- ✅ ASL模块需要（AI智能文献筛选）
|
||
- ✅ PKB模块需要（知识库RAG问答）
|
||
- ✅ DC模块需要（数据清洗NER提取）
|
||
- ✅ 审稿模块需要（稿件审查）
|
||
|
||
**所有模块都依赖LLM Gateway！**
|
||
|
||
---
|
||
|
||
#### 2. 文档处理引擎（Document Processing Engine）⭐⭐⭐⭐⭐ **核心**
|
||
|
||
**职责：**
|
||
- 多格式文档提取（PDF/Docx/Txt/Excel）
|
||
- 文本清洗与预处理
|
||
- OCR处理
|
||
- 表格提取
|
||
|
||
**技术架构：**
|
||
```typescript
|
||
// Python微服务（已实现）
|
||
interface DocumentProcessor {
|
||
// 提取文本
|
||
extract(file: File, method: 'pymupdf' | 'nougat' | 'mammoth'): Promise<{
|
||
text: string;
|
||
metadata: {
|
||
charCount: number;
|
||
language: string;
|
||
quality: number;
|
||
};
|
||
}>;
|
||
|
||
// 提取表格
|
||
extractTables(file: File): Promise<Table[]>;
|
||
|
||
// OCR处理
|
||
ocr(image: Buffer): Promise<string>;
|
||
}
|
||
```
|
||
|
||
**为什么是通用能力？**
|
||
- ✅ ASL模块需要（文献PDF提取）
|
||
- ✅ PKB模块需要（知识库文档上传）
|
||
- ✅ DC模块需要（Excel/Docx数据导入）
|
||
- ✅ 审稿模块需要（稿件文档提取）
|
||
|
||
**至少4个模块依赖文档处理引擎！**
|
||
|
||
---
|
||
|
||
#### 3. RAG引擎（RAG Engine）⭐⭐⭐⭐ **核心**
|
||
|
||
**职责：**
|
||
- 向量化存储（Embedding）
|
||
- 语义检索（Semantic Search）
|
||
- 检索增强生成（RAG）
|
||
- Rerank重排序
|
||
|
||
**技术架构：**
|
||
```typescript
|
||
// 基于Dify或自建向量数据库
|
||
interface RAGEngine {
|
||
// 创建知识库
|
||
createDataset(name: string, description?: string): Promise<string>;
|
||
|
||
// 上传文档
|
||
uploadDocument(datasetId: string, file: File): Promise<string>;
|
||
|
||
// 语义检索
|
||
search(datasetId: string, query: string, topK?: number): Promise<SearchResult[]>;
|
||
|
||
// RAG问答
|
||
chatWithRAG(datasetId: string, query: string, history?: Message[]): Promise<string>;
|
||
}
|
||
```
|
||
|
||
**为什么是通用能力？**
|
||
- ✅ PKB模块需要（个人知识库问答）
|
||
- ✅ ASL模块需要（文献内容检索）
|
||
- ✅ AIA模块需要（@知识库问答）
|
||
|
||
**至少3个模块依赖RAG引擎！**
|
||
|
||
---
|
||
|
||
#### 4. 数据ETL引擎（Data ETL Engine）⭐⭐⭐ **中等**
|
||
|
||
**职责：**
|
||
- Excel多表JOIN
|
||
- 数据清洗
|
||
- 数据转换
|
||
- 数据验证
|
||
|
||
**技术架构：**
|
||
```python
|
||
# Python微服务（基于Polars）
|
||
class ETLEngine:
|
||
# 读取多个Excel
|
||
def read_excel(self, files: List[File]) -> List[DataFrame]:
|
||
pass
|
||
|
||
# JOIN操作
|
||
def join(self, dfs: List[DataFrame], keys: List[str]) -> DataFrame:
|
||
pass
|
||
|
||
# 数据清洗
|
||
def clean(self, df: DataFrame, rules: Dict) -> DataFrame:
|
||
pass
|
||
|
||
# 导出
|
||
def export(self, df: DataFrame, format: str) -> bytes:
|
||
pass
|
||
```
|
||
|
||
**为什么是通用能力？**
|
||
- ✅ DC模块需要（数据清洗整理）
|
||
- ✅ SSA模块需要（统计分析数据预处理）
|
||
|
||
**至少2个模块依赖ETL引擎！**
|
||
|
||
---
|
||
|
||
#### 5. 医学NLP引擎（Medical NLP Engine）⭐⭐⭐ **中等**
|
||
|
||
**职责：**
|
||
- 医学实体识别（NER）
|
||
- 医学术语标准化
|
||
- 疾病/药物识别
|
||
|
||
**技术架构：**
|
||
```python
|
||
# Python微服务（基于spaCy + 医学模型）
|
||
class MedicalNLP:
|
||
# 实体识别
|
||
def extract_entities(self, text: str) -> List[Entity]:
|
||
pass
|
||
|
||
# 术语标准化
|
||
def normalize(self, term: str) -> str:
|
||
pass
|
||
|
||
# 疾病识别
|
||
def extract_diseases(self, text: str) -> List[str]:
|
||
pass
|
||
```
|
||
|
||
**为什么是通用能力？**
|
||
- ✅ DC模块需要（病例数据NER提取）
|
||
- ✅ ASL模块可能需要（文献关键词提取）
|
||
|
||
---
|
||
|
||
## 🎨 第三层：业务模块层（Product Layer）
|
||
|
||
### 定义
|
||
|
||
**业务模块层是面向用户的产品功能，每个模块都是独立的产品单元。**
|
||
|
||
### 核心特征
|
||
|
||
- ✅ **独立部署**：可以单独打包部署
|
||
- ✅ **独立销售**：可以单独售卖
|
||
- ✅ **低耦合**：模块间不直接依赖
|
||
- ✅ **高内聚**：模块内功能完整
|
||
|
||
### 模块清单
|
||
|
||
| 模块代号 | 模块名称 | 核心功能 | 商业价值 | 技术栈 | 依赖的通用能力 |
|
||
|---------|---------|---------|---------|-------|--------------|
|
||
| **AIA** | AI智能问答 | 10+智能体 | ⭐⭐⭐⭐ 差异化 | Node.js + Dify | LLM网关、RAG引擎 |
|
||
| **ASL** | AI智能文献 | 文献筛选、提取 | ⭐⭐⭐⭐⭐ 核心 | Node.js + Python | LLM网关、文档处理、RAG引擎 |
|
||
| **PKB** | 个人知识库 | RAG问答 | ⭐⭐⭐ 辅助 | Node.js + Dify | LLM网关、文档处理、RAG引擎 |
|
||
| **DC** | 数据清洗整理 | 自动ETL + NER | ⭐⭐⭐⭐⭐ 核心 | Node.js + Python | LLM网关、文档处理、ETL引擎、医学NLP |
|
||
| **SSA** | 智能统计分析 | 3条分析路径 | ⭐⭐⭐⭐⭐ 刚需 | Node.js + R | 文档处理、ETL引擎 |
|
||
| **ST** | 统计分析工具 | 100+小工具 | ⭐⭐⭐⭐ 高频 | Node.js + R | 文档处理 |
|
||
| **RVW** | 稿件审查系统 | 方法学评估 | ⭐⭐⭐⭐ 独立 | Node.js + Python | LLM网关、文档处理 |
|
||
|
||
---
|
||
|
||
### 业务模块详述
|
||
|
||
#### 1. AIA - AI智能问答模块 ✅ **已完成**
|
||
|
||
**当前状态：**
|
||
- ✅ 10个智能体已实现
|
||
- ✅ 多轮对话
|
||
- ✅ 流式输出
|
||
- ✅ 模型切换
|
||
- ✅ @知识库问答
|
||
|
||
**数据Schema：**
|
||
```typescript
|
||
// 业务模块Schema: aia_schema
|
||
- projects // 项目
|
||
- conversations // 对话
|
||
- messages // 消息
|
||
- agents_config // 智能体配置
|
||
```
|
||
|
||
**独立部署能力：**
|
||
- ✅ 前端：可独立打包
|
||
- ✅ 后端：可独立运行（依赖LLM网关、RAG引擎）
|
||
- ✅ 数据库：独立Schema
|
||
- ⚠️ 需要：平台层（用户认证）
|
||
|
||
---
|
||
|
||
#### 2. ASL - AI智能文献模块 ⏳ **规划中**
|
||
|
||
**核心功能：**
|
||
1. 标题摘要初筛（双模型AI判断）
|
||
2. 全文复筛（PDF全文分析）
|
||
3. 全文解析与数据提取
|
||
4. 数据分析与报告生成
|
||
5. 系统评价与Meta分析
|
||
6. 文献管理
|
||
|
||
**数据Schema：**
|
||
```typescript
|
||
// 业务模块Schema: asl_schema
|
||
- literature_projects // 文献项目
|
||
- literature_items // 文献条目
|
||
- pico_configs // PICO(S)配置
|
||
- screening_results // 筛选结果
|
||
- screening_history // 筛选历史
|
||
- extraction_tasks // 提取任务
|
||
- extraction_results // 提取结果
|
||
- meta_analysis_tasks // Meta分析任务
|
||
```
|
||
|
||
**独立部署能力：**
|
||
- ✅ 前端：独立React应用
|
||
- ✅ 后端：独立Node.js服务
|
||
- ✅ 数据库：独立Schema
|
||
- ✅ 依赖：LLM网关、文档处理、RAG引擎
|
||
|
||
**独立销售价值：⭐⭐⭐⭐⭐ 非常高！**
|
||
- 可以作为独立产品"AI文献筛选系统"售卖
|
||
- 目标客户：系统评价研究者、循证医学中心
|
||
|
||
---
|
||
|
||
#### 3. PKB - 个人知识库模块 ✅ **已完成**
|
||
|
||
**当前状态：**
|
||
- ✅ 知识库CRUD
|
||
- ✅ 文档上传
|
||
- ✅ RAG问答
|
||
- ✅ @知识库引用
|
||
|
||
**数据Schema：**
|
||
```typescript
|
||
// 业务模块Schema: pkb_schema
|
||
- knowledge_bases // 知识库
|
||
- documents // 文档
|
||
```
|
||
|
||
**独立部署能力：**
|
||
- ✅ 前端：可独立打包
|
||
- ✅ 后端：可独立运行
|
||
- ✅ 数据库：独立Schema
|
||
- ✅ 依赖：LLM网关、文档处理、RAG引擎
|
||
|
||
---
|
||
|
||
#### 4. DC - 数据清洗整理模块 ⏳ **规划中**
|
||
|
||
**核心功能：**
|
||
1. 多Excel文件导入
|
||
2. 自动JOIN和清洗
|
||
3. 医学NER实体提取
|
||
4. 数据质量报告
|
||
5. 导出标准化数据
|
||
|
||
**数据Schema：**
|
||
```typescript
|
||
// 业务模块Schema: dc_schema
|
||
- dc_projects // 数据清洗项目
|
||
- dc_raw_files // 原始文件
|
||
- dc_cleaned_data // 清洗后数据
|
||
- dc_ner_results // NER提取结果
|
||
- dc_quality_reports // 质量报告
|
||
```
|
||
|
||
**独立部署能力：**
|
||
- ✅ 前端：独立React应用
|
||
- ✅ 后端：Node.js + Python微服务
|
||
- ✅ 数据库：独立Schema（SQLite for 单机版）
|
||
- ✅ 依赖：LLM网关、文档处理、ETL引擎、医学NLP
|
||
|
||
**独立销售价值：⭐⭐⭐⭐⭐ 非常高！**
|
||
- 可以作为独立产品"医学数据清洗工具"售卖
|
||
- 目标客户：临床科室、数据管理员
|
||
|
||
---
|
||
|
||
#### 5. SSA - 智能统计分析模块 ⏳ **规划中**
|
||
|
||
**核心功能：**
|
||
1. 队列研究分析
|
||
2. 预测模型构建
|
||
3. RCT研究分析
|
||
4. 数据质量核查
|
||
5. 统计分析报告
|
||
|
||
**数据Schema：**
|
||
```typescript
|
||
// 业务模块Schema: ssa_schema
|
||
- ssa_projects // 统计分析项目
|
||
- ssa_datasets // 数据集
|
||
- ssa_analysis_tasks // 分析任务
|
||
- ssa_results // 分析结果
|
||
- ssa_reports // 分析报告
|
||
```
|
||
|
||
**独立部署能力：**
|
||
- ✅ 前端：独立React应用
|
||
- ✅ 后端：Node.js + R微服务
|
||
- ✅ 数据库：独立Schema
|
||
- ✅ 依赖：文档处理、ETL引擎
|
||
|
||
**独立销售价值：⭐⭐⭐⭐⭐ 非常高！**
|
||
- 可以作为独立产品"临床统计分析平台"售卖
|
||
|
||
---
|
||
|
||
#### 6. ST - 统计分析工具模块 ⏳ **规划中**
|
||
|
||
**核心功能：**
|
||
- 100+小工具（t检验、卡方检验、ROC曲线等）
|
||
|
||
**数据Schema：**
|
||
```typescript
|
||
// 业务模块Schema: st_schema
|
||
- st_tool_usage // 工具使用记录
|
||
```
|
||
|
||
**独立部署能力：**
|
||
- ✅ 前端：独立React应用
|
||
- ✅ 后端：Node.js + R微服务
|
||
- ✅ 数据库：独立Schema（可选）
|
||
- ✅ 依赖：文档处理
|
||
|
||
---
|
||
|
||
#### 7. RVW - 稿件审查系统 ⏳ **规划中（已有核心功能）**
|
||
|
||
**当前状态：**
|
||
- ✅ 文档上传
|
||
- ✅ 文本提取
|
||
- ✅ 稿约规范性评估（editorial_review）
|
||
- ✅ 方法学评估（methodology_review）
|
||
- ✅ 综合评分
|
||
|
||
**未来扩展：**
|
||
- ⚠️ 审稿人管理
|
||
- ⚠️ 审稿流程管理
|
||
- ⚠️ 多轮审稿
|
||
- ⚠️ 审稿意见模板
|
||
|
||
**数据Schema：**
|
||
```typescript
|
||
// 业务模块Schema: review_schema
|
||
- review_tasks // 审查任务（已有）
|
||
// 未来扩展：
|
||
- review_journals // 期刊库
|
||
- review_reviewers // 审稿人
|
||
- review_workflows // 审稿流程
|
||
- review_comments // 审稿意见
|
||
```
|
||
|
||
**独立部署能力：**
|
||
- ✅ 前端：独立React应用
|
||
- ✅ 后端：独立Node.js服务
|
||
- ✅ 数据库：独立Schema
|
||
- ✅ 依赖：LLM网关、文档处理
|
||
|
||
**独立销售价值：⭐⭐⭐⭐⭐ 极高！**
|
||
- 可以作为完全独立的产品"AI辅助审稿系统"售卖
|
||
- 目标客户：期刊编辑部、出版社、学会
|
||
- 商业模式：按期刊订阅，或按稿件数量计费
|
||
|
||
**为什么审稿系统适合独立？**
|
||
1. ✅ **用户群独立**：期刊编辑部 vs 临床医生（完全不同）
|
||
2. ✅ **业务逻辑独立**：与其他模块无关联
|
||
3. ✅ **部署场景独立**：期刊编辑部有自己的部署需求
|
||
4. ✅ **商业模式独立**：可以按期刊订阅
|
||
|
||
---
|
||
|
||
## 🔗 模块间关系
|
||
|
||
### 依赖关系图
|
||
|
||
```
|
||
业务模块层
|
||
├── AIA (AI智能问答)
|
||
│ └── 依赖：LLM网关、RAG引擎
|
||
│
|
||
├── ASL (AI智能文献)
|
||
│ └── 依赖：LLM网关、文档处理、RAG引擎
|
||
│
|
||
├── PKB (个人知识库)
|
||
│ └── 依赖：LLM网关、文档处理、RAG引擎
|
||
│
|
||
├── DC (数据清洗)
|
||
│ └── 依赖：LLM网关、文档处理、ETL引擎、医学NLP
|
||
│
|
||
├── SSA (智能统计分析)
|
||
│ └── 依赖：文档处理、ETL引擎
|
||
│
|
||
├── ST (统计分析工具)
|
||
│ └── 依赖：文档处理
|
||
│
|
||
└── RVW (稿件审查)
|
||
└── 依赖：LLM网关、文档处理
|
||
|
||
通用能力层
|
||
├── LLM网关 ⭐ (所有AI模块依赖)
|
||
├── 文档处理引擎 ⭐ (所有文档模块依赖)
|
||
├── RAG引擎 (AIA、ASL、PKB依赖)
|
||
├── ETL引擎 (DC、SSA依赖)
|
||
└── 医学NLP (DC依赖)
|
||
|
||
平台基础层
|
||
├── 用户与权限中心 ⭐ (所有模块依赖)
|
||
├── 存储服务 ⭐ (所有模块依赖)
|
||
├── 通知服务
|
||
├── 监控与日志
|
||
└── 系统配置
|
||
```
|
||
|
||
### 关键洞察
|
||
|
||
**1. LLM网关是核心中枢**
|
||
```
|
||
依赖LLM网关的模块：
|
||
- AIA（AI智能问答）
|
||
- ASL（AI智能文献）
|
||
- PKB（个人知识库）
|
||
- DC（数据清洗）
|
||
- RVW（稿件审查）
|
||
|
||
共计：5个模块 / 7个模块 = 71%
|
||
|
||
结论：LLM网关必须优先设计和实现！
|
||
```
|
||
|
||
**2. 文档处理引擎使用广泛**
|
||
```
|
||
依赖文档处理的模块：
|
||
- ASL（文献PDF提取）
|
||
- PKB（知识库文档）
|
||
- DC（Excel/Docx导入）
|
||
- SSA（数据导入）
|
||
- ST（数据导入）
|
||
- RVW（稿件提取）
|
||
|
||
共计：6个模块 / 7个模块 = 86%
|
||
|
||
结论：文档处理引擎已实现，需要继续增强！
|
||
```
|
||
|
||
**3. 模块独立性分析**
|
||
|
||
| 模块 | 独立性 | 原因 |
|
||
|------|-------|------|
|
||
| **RVW（审稿）** | ⭐⭐⭐⭐⭐ 极高 | 用户群、业务逻辑、部署场景都完全独立 |
|
||
| **ASL（文献）** | ⭐⭐⭐⭐⭐ 极高 | 可作为独立产品售卖给系统评价研究者 |
|
||
| **DC（数据清洗）** | ⭐⭐⭐⭐⭐ 极高 | 可作为独立产品售卖给数据管理员 |
|
||
| **SSA（统计分析）** | ⭐⭐⭐⭐ 高 | 可独立，但与ST模块有协同效应 |
|
||
| **ST（分析工具）** | ⭐⭐⭐⭐ 高 | 可独立，但与SSA模块有协同效应 |
|
||
| **AIA（AI问答）** | ⭐⭐⭐ 中 | 可独立，但与PKB有较强关联（@知识库） |
|
||
| **PKB（知识库）** | ⭐⭐⭐ 中 | 可独立，但与AIA有较强关联（@知识库） |
|
||
|
||
---
|
||
|
||
## 💾 数据库架构设计
|
||
|
||
### Schema隔离策略
|
||
|
||
**当前问题：**
|
||
- ❌ 所有表在同一Schema（public）
|
||
- ❌ 未来微服务拆分困难
|
||
- ❌ 不支持模块独立部署
|
||
|
||
**目标架构：**
|
||
```sql
|
||
-- 平台层Schema
|
||
CREATE SCHEMA platform_schema;
|
||
- users
|
||
- roles
|
||
- permissions
|
||
- user_roles
|
||
- role_permissions
|
||
- tenants
|
||
- feature_flags
|
||
- notifications
|
||
- admin_logs
|
||
- system_configs
|
||
|
||
-- 通用能力Schema
|
||
CREATE SCHEMA capability_schema;
|
||
- llm_usage_logs
|
||
- llm_quotas
|
||
- document_processing_logs
|
||
|
||
-- 业务模块Schema
|
||
CREATE SCHEMA aia_schema; -- AI智能问答
|
||
CREATE SCHEMA asl_schema; -- AI智能文献
|
||
CREATE SCHEMA pkb_schema; -- 个人知识库
|
||
CREATE SCHEMA dc_schema; -- 数据清洗
|
||
CREATE SCHEMA ssa_schema; -- 智能统计分析
|
||
CREATE SCHEMA st_schema; -- 统计分析工具
|
||
CREATE SCHEMA review_schema; -- 稿件审查
|
||
```
|
||
|
||
### 迁移策略
|
||
|
||
**阶段一：逻辑隔离（当前阶段）**
|
||
```
|
||
目标：在代码层面按Schema组织，但数据库还是public
|
||
方式：Prisma中使用@@map指定表名前缀
|
||
|
||
例如：
|
||
@@map("aia_projects") // AI问答的项目表
|
||
@@map("asl_projects") // AI文献的项目表
|
||
@@map("dc_projects") // 数据清洗的项目表
|
||
```
|
||
|
||
**阶段二：物理隔离（微服务拆分时）**
|
||
```
|
||
目标：真正创建独立Schema
|
||
方式：
|
||
1. 创建新Schema
|
||
2. 迁移数据（INSERT INTO new_schema.table SELECT * FROM public.old_table）
|
||
3. 更新Prisma Schema
|
||
4. 测试验证
|
||
```
|
||
|
||
---
|
||
|
||
## 🎯 可复用能力总结
|
||
|
||
### 什么是可复用能力？
|
||
|
||
**定义：**
|
||
- ✅ 被多个模块使用的技术能力
|
||
- ✅ 可以独立为服务
|
||
- ✅ 有明确的接口定义
|
||
- ✅ 职责单一
|
||
|
||
### 核心可复用能力清单
|
||
|
||
| 能力 | 使用频率 | 复用模块 | 优先级 | 当前状态 |
|
||
|------|---------|---------|--------|---------|
|
||
| **LLM网关** | 71% (5/7) | AIA、ASL、PKB、DC、RVW | P0 | ❌ 未实现 |
|
||
| **文档处理引擎** | 86% (6/7) | 所有模块 | P0 | ✅ 已实现 |
|
||
| **RAG引擎** | 43% (3/7) | AIA、ASL、PKB | P1 | ✅ 已实现（基于Dify） |
|
||
| **ETL引擎** | 29% (2/7) | DC、SSA | P2 | ❌ 未实现 |
|
||
| **医学NLP** | 14% (1/7) | DC | P2 | ❌ 未实现 |
|
||
|
||
### 立即行动
|
||
|
||
**P0能力（必须立即设计）：**
|
||
1. ✅ **LLM网关** - 商业模式的基础，5个模块依赖
|
||
2. ✅ **文档处理引擎** - 已实现，需要增强（表格提取）
|
||
|
||
**P1能力（近期设计）：**
|
||
3. ✅ **RAG引擎** - 已实现，需要优化
|
||
4. ⚠️ **ETL引擎** - DC模块开发时再设计
|
||
|
||
**P2能力（延后）：**
|
||
5. ⚠️ **医学NLP** - DC模块开发时再设计
|
||
|
||
---
|
||
|
||
## 🚀 架构演进路径
|
||
|
||
### 阶段一：模块化单体（当前 - 6个月）
|
||
|
||
**架构特点：**
|
||
```
|
||
单一代码库，但严格按模块划分：
|
||
backend/
|
||
├── platform/ # 平台层
|
||
│ ├── auth/
|
||
│ ├── storage/
|
||
│ └── notification/
|
||
├── capabilities/ # 通用能力层
|
||
│ ├── llm-gateway/
|
||
│ ├── document/
|
||
│ └── rag/
|
||
├── modules/ # 业务模块层
|
||
│ ├── aia/
|
||
│ ├── asl/
|
||
│ ├── pkb/
|
||
│ ├── dc/
|
||
│ ├── ssa/
|
||
│ ├── st/
|
||
│ └── review/
|
||
└── shared/ # 共享工具
|
||
|
||
单一数据库，但逻辑隔离（表名前缀）
|
||
```
|
||
|
||
**关键纪律：**
|
||
- ✅ 模块间不直接import，只能通过接口调用
|
||
- ✅ 每个模块有独立的路由、服务、数据访问层
|
||
- ✅ 使用表名前缀（逻辑Schema隔离）
|
||
|
||
---
|
||
|
||
### 阶段二：首次拆分（6-18个月）
|
||
|
||
**触发条件：**
|
||
- 有客户要求私有化部署
|
||
- 有客户要求单机版
|
||
- 需要独立销售某个模块
|
||
|
||
**拆分策略：**
|
||
```
|
||
1. 优先拆分RVW（审稿系统）- 最独立
|
||
2. 其次拆分DC或ASL - 商业价值高
|
||
3. 引入API网关
|
||
4. 引入K8s（可选，私有化部署需要）
|
||
```
|
||
|
||
**架构：**
|
||
```
|
||
API网关 (Kong/Traefik)
|
||
├── 平台服务 (UAM、Storage)
|
||
├── LLM网关服务
|
||
├── 文档处理服务 (Python微服务)
|
||
├── 审稿模块服务 (独立部署)
|
||
└── 其他模块服务 (暂时仍为单体)
|
||
```
|
||
|
||
---
|
||
|
||
### 阶段三：全面微服务（18个月+）
|
||
|
||
**架构：**
|
||
```
|
||
所有模块独立部署，支持灵活组合和模块化售卖
|
||
```
|
||
|
||
---
|
||
|
||
## 📊 总结
|
||
|
||
### 架构分层回答了您的关键问题
|
||
|
||
**1. 哪些是总体的？**
|
||
- ✅ 平台基础层：用户权限、存储、通知、监控、配置
|
||
|
||
**2. 哪些是通用的技术能力？**
|
||
- ✅ 通用能力层：LLM网关、文档处理、RAG引擎、ETL引擎、医学NLP
|
||
|
||
**3. 哪些是各子模块独立的功能？**
|
||
- ✅ 业务模块层：AIA、ASL、PKB、DC、SSA、ST、RVW
|
||
|
||
**4. 哪些能力是复用的？**
|
||
- ✅ LLM网关（5个模块）
|
||
- ✅ 文档处理（6个模块）
|
||
- ✅ RAG引擎（3个模块）
|
||
|
||
**5. 哪些可以随时独立成系统？**
|
||
- ⭐⭐⭐⭐⭐ **RVW（审稿系统）** - 最适合独立
|
||
- ⭐⭐⭐⭐⭐ **ASL（智能文献）** - 商业价值高
|
||
- ⭐⭐⭐⭐⭐ **DC（数据清洗）** - 商业价值高
|
||
|
||
---
|
||
|
||
**下一步：基于这个架构分层，重新组织文档结构。**
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|