dify二开之组件调用关系
Dify 系统架构文档
概述
Dify 是一个易于使用的 LLMOps 平台，旨在帮助开发者构建、测试和部署 AI 应用。系统采用前后端分离的架构，后端基于 Python Flask 框架构建，前端使用 Next.js 技术栈。
整体架构图
graph TB
subgraph "前端层"
A[Web 浏览器]
B[Next.js 前端]
A --> B
end
subgraph "API 网关层"
C[API 网关/负载均衡]
end
subgraph "应用服务层"
D[Flask 应用服务器]
E[Flask 应用服务器]
F[Flask 应用服务器]
end
subgraph "核心服务层"
G[任务队列 Celery]
H[缓存系统 Redis]
I[数据库 PostgreSQL]
J[向量数据库]
K[对象存储]
end
subgraph "第三方服务"
L[大语言模型 API]
M[外部数据源]
N[监控服务]
end
B --> C
C --> D
C --> E
C --> F
D --> G
D --> H
D --> I
D --> J
D --> K
E --> G
E --> H
E --> I
E --> J
E --> K
F --> G
F --> H
F --> I
F --> J
F --> K
G --> H
G --> I
G --> J
G --> K
D --> L
D --> M
D --> N
E --> L
E --> M
E --> N
F --> L
F --> M
F --> N
核心组件
1. Web 前端 (Next.js)
- 基于 Next.js 构建的单页应用
- 提供用户友好的界面用于创建和管理 AI 应用
- 通过 RESTful API 与后端通信
2. API 网关
- 负载均衡请求到多个应用服务器实例
- 处理 SSL 终止
- 提供限流和安全防护
3. 应用服务器 (Flask)
- 基于 Python Flask 框架构建
- 处理 HTTP 请求和业务逻辑
- 包含多个组件模块
3.1 控制器层 (Controllers)
处理 HTTP 请求，包括：
- Console API: 管理后台接口
- Service API: 服务接口
- Web API: 前端接口
- Inner API: 内部接口
- Files API: 文件处理接口
3.2 服务层 (Services)
实现核心业务逻辑：
- Account Service: 账户管理
- App Service: 应用管理
- Dataset Service: 数据集管理
- Model Service: 模型管理
- Workflow Service: 工作流管理
- Plugin Service: 插件管理
3.3 核心层 (Core)
提供核心功能实现：
- Model Runtime: 模型运行时
- RAG: 检索增强生成
- Agent: 智能代理
- Workflow Engine: 工作流引擎
- Plugin System: 插件系统
- Tools: 工具系统
4. 数据层
4.1 关系数据库 (PostgreSQL)
存储系统的核心数据：
- 用户账户信息
- 应用配置
- 对话历史
- 数据集元数据
4.2 向量数据库
存储向量化的文档数据：
- 文档段落的向量表示
- 相似性检索
4.3 缓存系统 (Redis)
- 会话存储
- 缓存热点数据
- 任务队列支持
4.4 对象存储
- 存储上传的文件
- 存储处理后的文档
5. 异步任务处理 (Celery)
- 处理耗时任务如文档处理、向量索引等
- 通过消息队列分发任务
- 支持任务重试和监控
6. 第三方集成
- 大语言模型 API (OpenAI, Anthropic等)
- 外部数据源 (Notion, Google Docs等)
- 监控服务 (Sentry, OpenTelemetry等)
组件调用关系
graph TD
A[客户端] --> B[API 网关]
B --> C[Flask 应用]
C --> D[控制器层]
D --> E[服务层]
E --> F[核心层]
E --> G[数据访问层]
F --> H[模型运行时]
F --> I[RAG引擎]
F --> J[工作流引擎]
F --> K[代理系统]
G --> L[数据库]
G --> M[向量数据库]
G --> N[缓存系统]
G --> O[对象存储]
C --> P[异步任务队列]
P --> Q[Celery Worker]
Q --> L
Q --> M
Q --> N
Q --> O
C --> R[第三方服务]
H --> R
I --> R
数据流向
1. 用户请求处理流程
- 用户通过 Web 前端发起请求
- 请求通过 API 网关路由到 Flask 应用服务器
- 控制器接收请求并进行参数验证
- 服务层处理业务逻辑
- 核心层执行具体功能（如调用 LLM、RAG 检索等）
- 数据访问层与数据库交互
- 返回响应给用户
2. 异步任务处理流程
- 应用服务器将耗时任务发送到任务队列
- Celery Worker 从队列中获取任务
- Worker 执行任务并与数据存储交互
- 任务完成后更新数据库状态
- 通过回调或轮询方式通知前端
部署架构
graph LR
subgraph "负载均衡器"
A[Load Balancer]
end
subgraph "Web 服务"
B[Next.js App]
end
subgraph "API 服务集群"
C1[Flask API 1]
C2[Flask API 2]
C3[Flask API N]
end
subgraph "Worker 集群"
D1[Celery Worker 1]
D2[Celery Worker 2]
D3[Celery Worker N]
end
subgraph "存储层"
E[(PostgreSQL)]
F[(向量数据库)]
G[(Redis)]
H[(对象存储)]
end
A --> B
A --> C1
A --> C2
A --> C3
C1 --> E
C2 --> F
C3 --> G
C1 --> H
D1 --> E
D2 --> F
D3 --> G
D1 --> H
扩展性设计
水平扩展
- 应用服务器可水平扩展以处理更多请求
- Worker 可以根据任务负载动态扩展
- 数据库可通过读写分离和分片扩展
插件系统
- 支持自定义工具和插件
- 提供标准接口用于集成第三方服务
- 支持自定义模型提供商
微服务潜力
- 当前为单体架构，但模块化设计便于未来拆分为微服务
- 核心组件间通过明确定义的接口交互
安全设计
认证与授权
- 基于 JWT 的身份验证
- 角色基础访问控制 (RBAC)
- 租户隔离
数据安全
- 敏感数据加密存储
- HTTPS 通信
- API 限流和防护
审计与监控
- 操作日志记录
- 性能监控
- 错误追踪
总结
Dify 采用分层架构设计，各层之间职责明确，便于维护和扩展。通过异步任务处理耗时操作，保证系统的响应性。模块化的核心层设计使得系统功能易于扩展，支持多种大语言模型和第三方服务集成。
浙公网安备 33010602011771号