第一次听说 SPI 是阅读《软件框架设计的艺术》,以后陆续在 JDBC 和 SpringBoot 中发现了以这种形式组织代码的方式,本位给出为什么要区分 SPI 和 API 的一个思考过程。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
- 项目地址:https://github.com/YunaiV/ruoyi-vue-pro
- 视频教程:https://doc.iocoder.cn/video/
我们在“调用方”和“实现方”之间引入了“接口”,上图没有给出“接口”应该位于哪个“包”中,从纯粹的可能性上考虑,我们有三种选择:
下面让我们依次分析这三种可能性,如果现实中确实有这种可能性,不如我们就为其起个名字以方便交流。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
- 项目地址:https://github.com/YunaiV/yudao-cloud
- 视频教程:https://doc.iocoder.cn/video/
我们先想象一个场景,以仓储的接口为例:
我们将“仓储接口”放置于“领域层”这个“包”中,实现放在一个独立的“包”中,我们看DDD大师的实现都是这样子,现在来思考一下为什么这么做。
“领域层”的“领域服务”会依赖“仓储接口”,“仓储接口”也会依赖“聚合根”,这两者都是除了“实现依赖”之外的依赖关系,如果将“接口”放到“仓储实现”中就丧失了面向接口编程的意义(编译也不会通过),如果放到“独立层”中呢?会编译不通过,出现双向依赖了。
对于类似这种情况下接口,我们将其称为“SPI”,全程为:service provider interface
,“SPI”的规则如下:
我们先想象一个场景,以Unity提供的IUnityContainer接口为例,除了维护这个框架的团队之外,我们没有发现谁实现了这个接口,虽然理论上是可以实现这个接口的(如果能实现的话,我们何不自己弄额Ioc容器呢?)。
对于类似这种情况下的接口,我们将其称作为“API”,“API”的规则如下:
这里就不说场景了,如果一个“接口”在一个上下文是“API”,在另一个上下文是“SPI”,那么你就可以这么组织。
不管是 SPI 或 API,接口都是可以组织到独立的“包”中,这么做是否有意义,自己来做出决定了。
SPI 和 API 也不一定是接口,我这里都是指狭义的具体的接口。
每一次思考都伴随着收获,也离不开和朋友们的交流,天更蓝了。
定义 :SPI 是一种服务提供者接口,它允许在运行时加载不同的服务实现。
- 模块化设计 :当系统需要高度模块化,且希望将核心功能与具体实现分离时。
- 可插拔架构 :需要支持多种服务实现,并且可以在不修改代码的情况下替换或增加新的服务实现。
- 服务发现 :在运行时根据配置或服务注册表动态发现和加载服务。
- 微服务架构 :在微服务架构中,SPI 可用于服务间的动态交互和集成。
- 提供了一种机制来在运行时选择和加载服务实现,增加了系统的灵活性和可扩展性。
定义 :API 是一组预定义的函数、协议和工具,用于构建软件应用,它定义了软件组件之间交互的契约。
- 客户端和服务器交互 :当需要设计客户端和服务器之间的通信协议时。
- 库和框架 :提供给开发者使用的库或框架的公共接口。
- 内部组件通信 :在大型系统中,不同组件或模块之间的交互。
- 为开发者提供了清晰的接口文档和规范,易于理解和使用。
- 有助于保持系统的稳定性,因为 API 变更需要遵循版本控制和兼容性规则。
选择使用 SPI 还是 API 的考虑因素:
- 扩展性 :如果需要在不修改代码的情况下扩展功能,SPI 更合适。
- 交互性 :API 更适合定义系统内部或系统之间的稳定交互接口。
- 动态性 :SPI 允许在运行时动态发现和加载服务,而 API 通常在编译时就已经确定。
- 安全性和稳定性 :API 由于其稳定性和可预测性,通常更受青睐。SPI 虽然灵活,但可能引入运行时错误。
- 版本控制和兼容性 :API 变更需要考虑版本控制和向后兼容性,而 SPI 可以通过服务版本协商来处理兼容性问题。
架构是“取舍”,而非“银弹”。