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框架。
希望别的框架没有叫这个注解吧，不然可能就尴尬了。哈哈。
以上纯是个人理解，如果有错误希望在评论中不吝赐教。
以上纯原创。谢谢。