一、引言

本方案旨在为现有引擎系统提供一个灵活且可扩展的方法，以支持不同类型的 SPI（Service Provider Interface）组件。通过定义标准化的 SPI 接口，并在运行时动态加载相应的实现，不需要修改引擎代码，我们可以提高系统的模块化程度，便于未来的维护和升级。

二、总体架构

  1. SPI 接口定义:
    • 在现有的引擎工程中创建一个专门的 spi 目录，用于存放所有 SPI 相关的接口。
    • 新增 spi/distributed 包，其中包含了分布式相关的 SPI 接口，例如 Installer, Registry, 和 Router 等。
    • 任何其他的 SPI 接口都可以在spi目录下进行定义，比如ORM等
  2. 服务发现机制:
    • 引入资源文件 META-INF/services，位于每个 SPI 实现项目的 resources 目录下。
    • 该文件应包含具体实现类的全限定名，以便于系统在运行时自动识别和加载这些实现。
  3. 依赖管理:
    • 为了确保新实现的 SPI 组件能够被正确地集成到引擎系统中，我们建议通过现有的独立的sie-snest-server工程项目进行打包。
    • 这样做的好处在于无需对引擎核心代码进行修改，只需调整sie-snest-server工程项目配置即可完成集成过程。
  4. 打包与部署:
    • 最终将整个sie-snest-server工程项目打包成镜像，这样就可以方便地将新的 SPI 功能部署到生产环境中。

      三、实施步骤

  5. 定义 SPI 接口:
    • 在引擎工程的 src/main/java/spi/distributed 包内添加所需的接口定义。
  6. 注册服务实现:
    • 在每个 SPI 实现项目中，编辑 resources/META-INF/services 文件，列出所有已实现的 SPI 类的全限定名。
  7. 构建与测试:
    • 构建服务器项目，确保所有的 SPI 实现都被正确地打包在内。
    • 对服务器进行全面的测试，验证 SPI 接口的可用性和性能。
  8. 部署与监控:
    • 将服务器镜像部署到生产环境。
    • 设置监控系统，持续观察 SPI 接口的运行状态和性能指标。

      四、优势与考虑因素

       - **灵活性**: 通过定义清晰的 SPI 接口，系统能够轻松地切换不同的实现，而不影响其他部分。
 - **可维护性**: 分离了接口定义与实现细节，使得代码更易于理解和维护。
 - **性能优化**: 可以根据实际需求选择最优的实现方式，从而提升整体系统效率。 #### 五、未来展望 随着业务的不断发展，我们计划进一步探索更多类型的 SPI 接口，如数据库操作或缓存管理等，以增强系统的功能多样性和适应性。

引擎愿景

引擎的功能：

  • 外部生态的适配，能够适应需求的变化；
  • 路由里面的逻辑，注入特殊逻辑，app可以注入，插件可以注入；
  • 元模型自身的扩展，增加一个元模型类型，如何增加? 默认auth1.0, 但是安装auth2.0；
  • 引擎本身要做扩展性，即可通过插件扩展，也可以通过app扩展，功能扩展，外围可以扩展它。插件补丁更新修复框架本身问题；
  • 引擎可测试性，比如orm实现得对不对？单元测试场景；
  • jsr40 元模型底层接口

7大类接口，所有接口的标准都有一个”根”:

  • 1，路由相关的，controller相关的，不要反射；
  • 2，元模型操作相关的接口，比如加一个模型，建一个服务等操作，内存数据库；
  • 3，分布式相关的扩展接口，数据转发，调度等。加密传输等。中间件的适配；
  • 4，ORM适配接口；
  • 5，配置相关的接口。配置中心，app、引擎的配置；
  • 6，事件，监控类的接口，埋点，带回调函数；
  • 7，部署相关的接口，运维相关；

这份方案设计文档详细规划了如何在现有引擎系统中集成和管理 SPI 组件，以确保系统的可扩展性、灵活性和高效性。

Table of Contents