Seata 中类SPI使用机制分析

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

JAVASPI是什么

全称为 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框架。

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

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

以上纯原创。谢谢。

posted @ 2019-10-17 10:42  每天进步一丶  阅读(557)  评论(0编辑  收藏  举报