dubbo：巧用dubbo的SPI机制实现各类定制功能（六）

文章目录

0. 引言
1. dubbo SPI机制
- 1.1 什么是SPI
- 1.2 java的SPI机制
- 1.3 dubbo的SPI机制
- 1.4 dubbo的SPI使用
2. 基于SPI实现定制功能
- 2.1 dubbo的上下文参数
- 2.2 实现权限校验、参数日志等功能
- 2.3 dubbo spi条件激活机制@Activate
3. dubbo的SPI与java的SPI有什么区别
4. 总结

0. 引言

1. dubbo SPI机制

1.1 什么是SPI

SPI(Service Provider Interface)，是一种服务发现机制，它允许服务提供者在运行时动态地为某个接口提供实现，而不需要在程序编译时进行硬编码。这种机制的核心思想是将装配的控制权移到程序之外，通过在模块化设计中实现接口与服务实现的解耦，从而提供一种插件化的扩展机制。SPI机制主要应用于框架和库的开发中，以支持服务的动态加载和替换。

1.2 java的SPI机制

在Java中，SPI机制的实现依赖于java.util.ServiceLoader类，它负责查找和加载实现了特定接口的服务提供者。服务提供者需要在其JAR包的META-INF/services目录下创建一个以服务接口全限定名为名称的文件，并在该文件中列出实现该接口的具体类的名称。当应用程序需要使用某个服务时，可以通过ServiceLoader类查找并加载这些实现类，进而使用它们提供的服务。

更加详尽的介绍可以参考我之前的文章：

Java进阶：利用SPI机制不侵入源码而实现定制功能【附带源码】

1.3 dubbo的SPI机制

官方介绍：https://cn.dubbo.apache.org/zh-cn/docsv2.7/dev/source/dubbo-spi/

Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。在 Dubbo 中，SPI 是一个非常重要的模块。基于 SPI，我们可以很容易的对 Dubbo 进行拓展。

1.4 dubbo的SPI使用

0、首先要引入dubbo依赖，这里的版本根据你的dubbo版本调整

<dependency>
            <groupId>org.apache.dubbo</groupId>
            <artifactId>dubbo-spring-boot-starter</artifactId>
            <version>3.1.2</version>
</dependency>

如果不是springboot框架，就直接引入以下dubbo依赖

<dependency>
   <groupId>org.apache.dubbo</groupId>
   <artifactId>dubbo</artifactId>
   <version>3.1.2</version>
</dependency>

1、与 Java SPI 实现类配置不同，Dubbo SPI 是通过键值对的方式进行配置，这样我们可以按需加载指定的实现类。首先创建一个接口类AuthService，用于后续拓展

这里需要注意的是，接口类中需要添加@SPI注解

import org.apache.dubbo.common.extension.SPI;

@SPI
public interface AuthService {
    String getInfo();
}

2、创建两个实现类AuthBasicService，AuthTokenService

public class AuthBasicService implements AuthService{
    @Override
    public String getInfo() {
        return "basic auth";
    }
}

public class AuthTokenService implements AuthService{

    @Override
    public String getInfo() {
        return "token auth";
    }
}

3、然后在项目的资源目录resources下创建META-INF/dubbo文件夹，然后根据接口类的全包名来创建一个文本文件wu.example.orderserver.spi.AuthService，文件内容为实现类的别名和对应的全包名

basic=wu.example.orderserver.spi.AuthBasicService
token=wu.example.orderserver.spi.AuthTokenService

在这里插入图片描述

4、而实现类的调用则通过即可ExtensionLoader.getExtensionLoader(AuthService.class)

ExtensionLoader<AuthService> extensionLoader = ExtensionLoader.getExtensionLoader(AuthService.class);
AuthService service = extensionLoader.getExtension(type);

5、我们创建一个测试接口用来验证，这里通过入参控制调用不同的实现类

@RestController
@RequestMapping("spi")
public class SpiController {

    @GetMapping("getInfo")
    public String getInfo(String type){
        ExtensionLoader<AuthService> extensionLoader =
                ExtensionLoader.getExtensionLoader(AuthService.class);
        AuthService service = extensionLoader.getExtension(type);
        return service.getInfo();
    }

}

6、调整入参，可以成功访问到不同的实现类，则说明正常
在这里插入图片描述

可以看到dubbo spi的使用相对java spi来说要更加简单一些

2. 基于SPI实现定制功能

dubbo 默认预留了很多功能的spi拓展接口，如协议、拦截器、监听器、集群容错策略等，可根据官方文档描述进行定制：
https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/reference-manual/spi/description/

在这里插入图片描述

2.1 dubbo的上下文参数

官方文档：https://cn.dubbo.apache.org/zh-cn/overview/tasks/develop/context/

某些场景下，我们在进行rpc接口交互过程中，需要传输一些额外的数据，但又不想改变原接口参数，这时就需要上下文参数来协助，比如调用rpc接口前在上下文参数重传入token，然后在被调用接口中获取token来进行权限校验。

在 Dubbo 3 中，rpc上下文参数被拆分为四大模块，官方对这4个上下文参数的定义是：

ServiceContext：在 Dubbo 内部使用，用于传递调用链路上的参数信息，如 invoker 对象等
ClientAttachment：在 Client 端使用，往 ClientAttachment 中写入的参数将被传递到 Server 端
ServerAttachment：在 Server 端使用，从 ServerAttachment 中读取的参数是从 Client 中传递过来的
ServerContext：在 Client 端和 Server 端使用，用于从 Server 端回传 Client 端使用，Server 端写入到 ServerContext 的参数在调用结束后可以在 Client 端的 ServerContext 获取到

特别注意：path, group, version, dubbo, token, timeout 这几个 key 是保留字段，上下文参数一定不要使用这几个名称

下面我们通过一个实例来体会他们的作用

2.2 实现权限校验、参数日志等功能

0、首先我们还是基于之前创建的演示项目order-server和user-server模块来进行演示，如果不清楚的可以查看前文
从零理解及搭建dubbo微服务框架

1、因为要实现权限校验和参数日志，我们可以利用dubbo自带的过滤器来实现，只需要拓展过滤器接口，在消费者服务order-server模块创建AuthFilter和LogInterceptor

声明Filter接口，实现invoke方法，这里权限校验我们就演示下，校验auth参数是否为空即可，该参数将从客户端（调用方）传入

public class AuthFilter implements Filter {

    @Override
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        String token = RpcContext.getClientAttachment().getAttachment("auth");
        if(StringUtil.isNullOrEmpty(token)){
            throw new RuntimeException("token为空");
        }
        Result result = invoker.invoke(invocation);
        return result;
    }
}

日志就简单记录下调用参数和返回结果即可

public class LogInterceptor implements Filter {

    private final static Logger logger = LoggerFactory.getLogger(LogInterceptor.class);

    @Override
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        String params = JSONObject.toJSONString(invocation.getArguments());
        logger.info(String.format("接口：%s，调用参数：%s",invocation.getMethodName(), params));
        Result result = invoker.invoke(invocation);
        String resultStr = JSONObject.toJSONString(result.getValue());
        logger.info(String.format("接口：%s，返回结果：%s",invocation.getMethodName(), resultStr));
        return result;
    }
}

2、在消费者order-server项目的资源目录resources中创建META-INF/dubbo目录，再根据Filter类的全包名创建文本文件org.apache.dubbo.rpc.Filter，同样内容为实现类的别名和全包名

log=wu.example.orderserver.filter.LogInterceptor
auth=wu.example.orderserver.filter.AuthFilter

3、在调用处传入auth参数，这里为了模拟效果，我们直接让auth从外部接口传入，可以看到从客户端（调用方）传入上下文参数是通过ClientAttachment，从服务端（被调用方）是通过ServerAttachment

同时客户端获取服务端传来的参数是通过ServerContext

声明提供服务时要通过filter参数指定需要的过滤器，其名称与在上一步说明的别名保持一致

    @DubboReference(filter = "auth,log")
    private UserService userService;

    @GetMapping("createOrder")
    public String createOrder(Integer id, String token){
        try{
            RpcContext.getClientAttachment().setAttachment("auth", token);
            String userName = userService.getUserById(id);
            String res = RpcContext.getServerContext().getAttachment("res");
            return userName + " createOrder success, "+res;
        }catch (Exception e){
            e.printStackTrace();
            return "createOrder fail: " + e.getMessage();
        }
    }

4、我们同样调整下生产者user-server的接口，获取auth参数，并且设置一个上下文参数res返回到客户端

@Override
    public String getUserById(Integer id){
        String token = RpcContext.getServerAttachment().getAttachment("auth");
        RpcContext.getServerContext().setAttachment("res", "返回"+id);
        return "用户" + token + ": "+ id;
    }

5、调用测试
在这里插入图片描述
打印的参数日志

如果不传入token参数，则会报出错误

当然，这里没有对错误返回实体进行封装，如果考虑可读性，大家可以再将rpc错误做一层实体包装

2.3 dubbo spi条件激活机制@Activate

dubbo spi支持根据条件自动激活和选择对应的实现类，就是通过@Activate注解实现。该注解主要有3个参数

group

分组条件，满足该分组名的才激活使用

value

URL路径中的参数名，有该参数名的才激活使用

order

调用顺序，group,value都相同时，按照order顺序先后调用

如下使用示例中，当实现类group为basic，且url参数中有id参数时就激活使用这个实现类

@Activate(group = "basic", value = "id")
public class AuthBasicService implements AuthService{
    @Override
    public String getInfo() {
        return "basic auth";
    }
}

获取实现类时就通过getActivateExtension方法来获取

ExtensionLoader<AuthService> extensionLoader =
                ExtensionLoader.getExtensionLoader(AuthService.class);
URL url = URL.valueOf("localhost:8081/getInfo?name="+type);
        List<AuthService> activateExtension = extensionLoader.getActivateExtension(url, "id", group);

3. dubbo的SPI与java的SPI有什么区别

1、dubbo SPI是懒加载，java SPI是预加载

正如我们之前演示的，java SPI使用时是通过ServiceLoader.load(xxx.class)加载所有的实现类，然后循环获取所需的实现类，尽管我们在上文中已经将实现类放到了Map中，避免重复加载，但是依然需要提前预载，而dubbo SPI是只有实际需要使用时，才会加载对应的实现类，可以减少消耗