☰
Current Page
Main Menu
Home
Home
Editing
基于spi机制实现引擎可扩展功能方案
Edit
Preview
h1
h2
h3
default
Set your preferred keybinding
default
vim
emacs
markdown
Set this page's format to
AsciiDoc
Creole
Markdown
MediaWiki
Org-mode
Plain Text
RDoc
Textile
Rendering unavailable for
BibTeX
Pod
reStructuredText
Help 1
Help 1
Help 1
Help 2
Help 3
Help 4
Help 5
Help 6
Help 7
Help 8
Autosaved text is available. Click the button to restore it.
Restore Text
#### 一、引言 本方案旨在为现有引擎系统提供一个灵活且可扩展的方式,以支持不同类型的 SPI(Service Provider Interface)组件。通过定义标准化的 SPI 接口,并在运行时动态加载相应的实现,不需要修改引擎代码,我们可以提高引擎的模块化程度,便于未来的维护和升级。 #### 二、总体架构 1. **SPI 接口定义**: - 在现有的引擎工程中创建一个专门的 `spi` 目录,用于存放所有 SPI 相关的接口。 - 目前新增的有 `spi/distributed` 包,其中包含了分布式相关的 SPI 接口,例如 `Installer`, `Registry`, 和 `Router` 等。 - 任何其他的 SPI 接口都可以在`spi`目录下进行定义,比如 ORM 等 [[http://iidp.chinasie.com:9999/iidpminio/spi/spi.jpg]] 2. **服务发现机制**: - 引入资源文件 `META-INF/services`,位于每个 SPI 实现项目的 `resources` 目录下。注意这些services不是定义在引擎的,而是分别定义在具体的实现类jar包中的。 - 该文件应包含具体实现类的全限定名,以便于系统在运行时自动识别和加载这些实现。 [[http://iidp.chinasie.com:9999/iidpminio/spi/spi-implement.jpg]] - 在spi使用方引擎中代码中加载实现类 [[http://iidp.chinasie.com:9999/iidpminio/spi/spi-loader.jpg]] 3. **依赖管理**: - 为了确保新实现的 SPI 组件能够被正确地集成到引擎系统中,我们建议通过现有的独立的`sie-snest-server`工程项目进行打包。 - 这样做的好处在于无需对引擎核心代码进行修改,甚至连引擎的配置文件也不需要修改,只需调整`sie-snest-server`工程项目配置即可完成集成过程。 [[http://iidp.chinasie.com:9999/iidpminio/spi/spi-dependency.jpg]] 4. **打包与部署**: - 最终将整个`sie-snest-server`工程项目打包成镜像,这样就可以方便地将新的 SPI 功能部署到生产环境中。 #### 三、实施步骤 1. **定义 SPI 接口**: - 在引擎工程的 `src/main/java/spi/distributed` 包内添加所需的接口定义。 2. **注册服务实现**: - 在每个 SPI 实现项目中,编辑 `resources/META-INF/services` 文件,列出所有已实现的 SPI 类的全限定名。 3. **构建与测试**: - 构建服务器项目,确保所有的 SPI 实现都被正确地打包在内。 - 对服务器进行全面的测试,验证 SPI 接口的可用性和性能。 4. **部署与监控**: - 将服务器镜像部署到生产环境。 - 设置监控系统,持续观察 SPI 接口的运行状态和性能指标。 #### 四、优势与考虑因素 - **灵活性**: 通过定义清晰的 SPI 接口,引擎能够轻松地切换不同的实现,而引擎不需要作任何的变化,包括配置文件也不需要变动。 - **可维护性**: 分离了接口定义与实现细节,使得代码更易于理解和维护。 - **性能优化**: 可以根据实际需求选择最优的实现方式,从而提升整体系统效率和扩展性。 #### 五、引擎愿景 随着业务的不断发展,我们计划进一步探索更多类型的 SPI 接口,如数据库操作或缓存管理等,以增强系统的功能多样性和适应性。 ##### 引擎的功能: - 外部生态的适配,能够适应需求的变化; - 路由里面的逻辑,注入特殊逻辑,app可以注入,插件可以注入; - 元模型自身的扩展,增加一个元模型类型,如何增加? 默认auth1.0, 但是安装auth2.0; - 引擎本身要做扩展性,即可通过插件扩展,也可以通过app扩展,功能扩展,外围可以扩展它。插件补丁更新修复框架本身问题; - 引擎可测试性,比如orm实现得对不对?单元测试场景; - jsr40 元模型底层接口 ##### 7大类接口,所有接口的标准都有一个"根": - 路由相关的,controller相关的,不要反射; - 元模型操作相关的接口,比如加一个模型,建一个服务等操作,内存数据库; - 分布式相关的扩展接口,数据转发,调度等。加密传输等。中间件的适配; - ORM适配接口; - 配置相关的接口。配置中心,app、引擎的配置; - 事件,监控类的接口,埋点,带回调函数; - 部署相关的接口,运维相关; --- 这份方案设计文档详细规划了如何在现有引擎系统中集成和管理 SPI 组件,以确保系统的可扩展性、灵活性和高效性。
Uploading file...
Sidebar
[[_TOC_]]
Edit message:
Cancel