@@ -9,15 +9,88 @@ weight: 301
9
9
10
10
## 背景
11
11
12
- 原先 FastGPT 的各项功能均采用单体应用,子 packages 的方式进行构建。随着用户范围增多,个性化需求丰富,以及多次交付时遇到的系统工具定制困难问题,导致我们对
13
- 我们决定设计一种更为灵活的扩展
14
-
15
- 主要有如下的目的:
16
- 1 . 解耦合,模块化。
17
- 2 . FastGPT-plugin 可以快速迭代,版本不依赖于 FastGPT
18
- 3 . 降低开发复杂度(不需要运行 FastGPT 环境)
19
- 4 . 插件市场
20
-
21
- 更远期的设想:
22
- 1 . 以纯代码的形式构建应用
23
- 2 . 加入其他可以自定义的模块
12
+ 原先 FastGPT 的各项功能均在 FastGPT 的 Next.js 的框架内,通过 Monorepo 的方式进行组织。
13
+ 系统插件也作为一个 sub-repo 存在于 FastGPT/packages/plugin 下。
14
+
15
+ 然而随着用户的增加,这种组织模式的弊端凸显:
16
+
17
+ 1 . 虽然 FastGPT 以每周一次的频率进行发版,但同样,系统插件必须伴随 FastGPT 的发版而发版,极大限制了系统插件的迭代速率。
18
+ 2 . 如果社区希望为 FastGPT 提供插件,则需要将 FastGPT 整个应用运行起来,并且直接向主仓库发起 PR。
19
+ 3 . 如果社区希望使用自定义的插件,则需要维护一个 FastGPT 的 fork 版本,并且手动维护更新和代码的合并,增加了开发的难度。
20
+ 4 . 由于 Next.js/webpack 的限制,无法在运行时挂载新的插件,实现热插拔。
21
+
22
+ ## 设计方案
23
+
24
+ 因而,我们决定将系统插件拆分出来,到一个独立的 repo 中。
25
+
26
+ [ FastGPT-plugin] ( https://github.com/labring/fastgpt-plugin )
27
+
28
+ 拆分出来,主要有如下的目的:
29
+ 1 . 解耦合,模块化:不只是 系统工具可以作为热加载的模块,也可以是其他的插件,例如知识库的插件,RAG 等等。
30
+ 2 . FastGPT-plugin 可以快速迭代,版本不依赖于 FastGPT:FastGPT-plugin 可以更高频率的发版,支持热插拔可以在不发版的情况下更新插件。
31
+ 3 . 降低开发复杂度(不需要运行 FastGPT 环境):贡献插件时只需要独立运行 FastGPT-plugin 中提供的调试套件即可。
32
+ 4 . 插件市场:后续可以实现插件市场,用户可以通过插件市场发布、获取自己需要的插件。
33
+
34
+ ## 技术选型
35
+
36
+
37
+ 1 . 使用 ts-rest 作为 RPC 框架进行交互,提供 sdk 供 FastGPT 主项目调用
38
+ 2 . 使用 zod 进行类型验证
39
+ 3 . 用 bun 进行编译,每个工具编译为单一的 ` .js ` 文件,支持热插拔。
40
+
41
+ ``` mermaid
42
+ graph LR
43
+ A[FastGPT] --> |RESTful API|B[FastGPT-plugin]
44
+ B <--> C(Minio)
45
+ ```
46
+
47
+ ## 项目结构
48
+
49
+ - ** modules**
50
+ - **tool** FastGPT 系统工具
51
+ - **api** 接口实现逻辑
52
+ - **packages** 系统工具目录(每一个都是一个 package)
53
+ - getTime
54
+ - dalle3
55
+ - ...
56
+ - **type** 类型定义
57
+ - **utils** 工具
58
+ - ** scripts** 脚本(编译、创建新工具)
59
+ - ** sdk** : SDK 定义,供外部调用,发布到了 npm
60
+ - ** src** : 运行时,express 服务
61
+ - ** test** : 测试相关
62
+
63
+ 系统工具的结构可以参考 [ 如何开发系统工具] ( /docs/guide/plugins/dev_system_tool ) 。
64
+
65
+ ## 技术细节
66
+
67
+ ### ts-rest 构建 contract,自动构建 openapi 对象,导出 client
68
+
69
+ [ ts-rest] ( https://ts-rest.com/ ) 是一个 ts 的 restful api 框架。构建 contract 后,可以根据 contract 的定义
70
+ 编写处理逻辑,自动生成 openapi 对象、通过 createClient 导出 client 进行请求。
71
+
72
+ 类似的 ` tRPC ` 也是一个 ts 的 RPC 框架。
73
+ 然而 tRPC 使用自己的一套请求格式,导致其他工具不方便接入。而使用 ts-rest 本质就是对 RESTful API 的简单封装,也能直接生成 openapi 对象。
74
+
75
+ ### zod 类型校验
76
+
77
+ 我们使用 zod 来实现类型校验。
78
+ zod 可以实现在运行时的类型校验,也可以提供更高级的功能,例如参数转换,对象合并等。
79
+
80
+ ### 使用 worker 实现插件的并行运行以及环境隔离
81
+
82
+ 为了保证插件之间不会相互干扰,同时提高并发处理能力,FastGPT-plugin 采用 Worker 线程来实现插件的执行。每个工具在被调用时都会在独立的 Worker 中运行,
83
+ 这带来几个重要的优势:
84
+
85
+ 1 . 环境隔离:每个插件都是一个独立的 Worker 进程,插件之间不会影响。
86
+ 2 . 并行处理:每个插件可以并行处理,提高整体性能。
87
+
88
+ ### 使用 bun 进行打包
89
+
90
+ 将插件 bundle 为一个单一的 ` .js ` 文件是一个重要的设计。这样可以将插件发布出来直接通过网络挂载等的形式使用。
91
+
92
+ ## 未来规划
93
+
94
+ 1 . 可视化开发工具:提供可视化的插件开发和调试工具,降低开发门槛。
95
+ 2 . 插件市场:建立插件市场,允许开发者发布和分享自己的插件。
96
+ 3 . 更多插件类型:除了系统工具外,扩展到知识库插件、模型插件、RAG 插件等更多类型。
0 commit comments