Seata 中类SPI使用机制分析

Seata中采用了与sofa-rpc和dubbo中相同的服务扩展机制。都是基于JAVA自身的服务发现机制-SPI进行再次封装注解，sofa-rpc和dubbo（@Deprecated）中的注解名字叫做@Extension，Seata中叫做@LoadLevel。

JAVA的SPI是什么

全称为 Service Provider Interface，是一种服务发现机制。它通过在ClassPath路径下的META-INF/services文件夹查找文件，根据文件中描述的类的全路径名称，可以加载到相应的实现。

Seata为什么要使用类SPI机制

Seata现在支持的注册中心有zk,eurake,etcd3等，使用时一般情况下只需要其中的一种注册方式即可。其余的不需要，这时候一般都是引入其中的一个包。所以通过类似SPI的这种机制可以实现灵活的扩展引用。

Seata中的SPI与JDK中的不太相同，在Seata中首先使用@LoadLevel标记为扩展接口的类，如：

 

 

 

 

 

 

在注册中心的扩展上使用@LoadLevel标记，标记后在进行注册中心的类的初始化中进行甄别加载，如：

 

 

 

在EnhancedServiceLoader中的关键方法loadFile中首先与JDK中的处理方式相同，读取

 

 

 

该目录下的配置文件，生成Bean；但是可能会包含其他的框架中提供的非Seata扩展服务，所以需要进行判断该类是否包含@LoadLevel注解，进行甄别处理。这可能也是修改该注解名字的原因，因为在DUBBO和Sofa-Rpc中叫做@Extension，为了冲突的处理吧。毕竟Seata要兼容这两个RPC框架。

希望别的框架没有叫这个注解吧，不然可能就尴尬了。哈哈。

以上纯是个人理解，如果有错误希望在评论中不吝赐教。

以上纯原创。谢谢。