846518169eb536195a8bb4df9b55fb3c0eb6f18c
\345\237\272\344\272\216spi\346\234\272\345\210\266\345\256\236\347\216\260\345\274\225\346\223\216\345\217\257\346\211\251\345\261\225\345\212\237\350\203\275\346\226\271\346\241\210.md
... | ... | @@ -0,0 +1,58 @@ |
1 | + |
|
2 | +#### 一、引言 |
|
3 | +本方案旨在为现有引擎系统提供一个灵活且可扩展的方法,以支持不同类型的 SPI(Service Provider Interface)组件。通过定义标准化的 SPI 接口,并在运行时动态加载相应的实现,不需要修改引擎代码,我们可以提高系统的模块化程度,便于未来的维护和升级。 |
|
4 | +#### 二、总体架构 |
|
5 | +1. **SPI 接口定义**: |
|
6 | + - 在现有的引擎工程中创建一个专门的 `spi` 目录,用于存放所有 SPI 相关的接口。 |
|
7 | + - 新增 `spi/distributed` 包,其中包含了分布式相关的 SPI 接口,例如 `Installer`, `Registry`, 和 `Router` 等。 |
|
8 | + - 任何其他的 SPI 接口都可以在`spi`目录下进行定义,比如ORM等 |
|
9 | + |
|
10 | +2. **服务发现机制**: |
|
11 | + - 引入资源文件 `META-INF/services`,位于每个 SPI 实现项目的 `resources` 目录下。 |
|
12 | + - 该文件应包含具体实现类的全限定名,以便于系统在运行时自动识别和加载这些实现。 |
|
13 | +3. **依赖管理**: |
|
14 | + - 为了确保新实现的 SPI 组件能够被正确地集成到引擎系统中,我们建议通过现有的独立的`sie-snest-server`工程项目进行打包。 |
|
15 | + - 这样做的好处在于无需对引擎核心代码进行修改,只需调整`sie-snest-server`工程项目配置即可完成集成过程。 |
|
16 | +4. **打包与部署**: |
|
17 | + - 最终将整个`sie-snest-server`工程项目打包成镜像,这样就可以方便地将新的 SPI 功能部署到生产环境中。 |
|
18 | +#### 三、实施步骤 |
|
19 | +1. **定义 SPI 接口**: |
|
20 | + - 在引擎工程的 `src/main/java/spi/distributed` 包内添加所需的接口定义。 |
|
21 | +2. **注册服务实现**: |
|
22 | + - 在每个 SPI 实现项目中,编辑 `resources/META-INF/services` 文件,列出所有已实现的 SPI 类的全限定名。 |
|
23 | +3. **构建与测试**: |
|
24 | + - 构建服务器项目,确保所有的 SPI 实现都被正确地打包在内。 |
|
25 | + - 对服务器进行全面的测试,验证 SPI 接口的可用性和性能。 |
|
26 | +4. **部署与监控**: |
|
27 | + - 将服务器镜像部署到生产环境。 |
|
28 | + - 设置监控系统,持续观察 SPI 接口的运行状态和性能指标。 |
|
29 | +#### 四、优势与考虑因素 |
|
30 | +- **灵活性**: 通过定义清晰的 SPI 接口,系统能够轻松地切换不同的实现,而不影响其他部分。 |
|
31 | +- **可维护性**: 分离了接口定义与实现细节,使得代码更易于理解和维护。 |
|
32 | +- **性能优化**: 可以根据实际需求选择最优的实现方式,从而提升整体系统效率。 |
|
33 | +#### 五、未来展望 |
|
34 | +随着业务的不断发展,我们计划进一步探索更多类型的 SPI 接口,如数据库操作或缓存管理等,以增强系统的功能多样性和适应性。 |
|
35 | + |
|
36 | + |
|
37 | +### 引擎愿景 |
|
38 | + |
|
39 | +#### 引擎的功能: |
|
40 | +- 外部生态的适配,能够适应需求的变化; |
|
41 | +- 路由里面的逻辑,注入特殊逻辑,app可以注入,插件可以注入; |
|
42 | +- 元模型自身的扩展,增加一个元模型类型,如何增加? 默认auth1.0, 但是安装auth2.0; |
|
43 | +- 引擎本身要做扩展性,即可通过插件扩展,也可以通过app扩展,功能扩展,外围可以扩展它。插件补丁更新修复框架本身问题; |
|
44 | +- 引擎可测试性,比如orm实现得对不对?单元测试场景; |
|
45 | +- jsr40 元模型底层接口 |
|
46 | + |
|
47 | +#### 7大类接口,所有接口的标准都有一个”根”: |
|
48 | +- 1,路由相关的,controller相关的,不要反射; |
|
49 | +- 2,元模型操作相关的接口,比如加一个模型,建一个服务等操作,内存数据库; |
|
50 | +- 3,分布式相关的扩展接口,数据转发,调度等。加密传输等。中间件的适配; |
|
51 | +- 4,ORM适配接口; |
|
52 | +- 5,配置相关的接口。配置中心,app、引擎的配置; |
|
53 | +- 6,事件,监控类的接口,埋点,带回调函数; |
|
54 | +- 7,部署相关的接口,运维相关; |
|
55 | + |
|
56 | + |
|
57 | +--- |
|
58 | +这份方案设计文档详细规划了如何在现有引擎系统中集成和管理 SPI 组件,以确保系统的可扩展性、灵活性和高效性。 |