《RPC手撸专栏》第37章：基于SPI扩展JDK反射机制调用真实方法

作者：冰河
星球：http://m6z.cn/6aeFbs (opens new window)
博客：https://binghe.gitcode.host (opens new window)
文章汇总：https://binghe.gitcode.host/md/all/all.html (opens new window)

沉淀，成长，突破，帮助他人，成就自我。

大家好，我是冰河~~

在前面的章节中，我们基于SPI扩展了JDK、CGLib、Javassist、ByteBuddy和ASM动态代理机制，细心的读者可以发现，我们基于SPI扩展动态代理机制时，基本都是侧重于服务消费者来说的。其实，在服务提供者端也有很多可以基于SPI动态扩展的功能。

一、前言

我想在服务提供者端基于SPI扩展调用真实方法的方式，你能搞定吗？

在服务提供者一端，尽管在之前的文章中，我们实现了基于JDK和CGLib的反射机制调用真实方法，但是在之前的文章中，我们通过传入反射方式reflectType参数的形式，来选择使用JDK或者CGLib的方式来调用真实方法。

这里，存在着一个问题就是，不管是使用JDK的方式调用真实方法，还是使用CGLib的方式调用真实方法。这两种方式都是直接将方法写到了服务提供者的io.binghe.rpc.provider.common.handler.RpcProviderHandler类中，只是通过传入的反射方式reflectType参数进行区分，是使用JDK方式调用真实方法，还是使用CGLib方式调用真实方法。

这种方式不利于程序的扩展，如果需要支持其他的方式调用真实方法，就不得不修改框架的源代码来扩展对应的功能。

二、目标

本章目标很明确：基于SPI扩展JDK反射机制调用真实方法。

目前，我们手写的RPC框架中，将服务提供者调用真实方法的代码直接写到了服务提供者的io.binghe.rpc.provider.common.handler.RpcProviderHandler类中。

这种直接将调用真实方法的代码写到提供者的io.binghe.rpc.provider.common.handler.RpcProviderHandler类中，非常不利于程序后续的扩展，尤其是对于像RPC这种底层基础通信设施框架来说，不具备扩展性，后期的维护和升级就比较麻烦。

例如，我们自己手写的RPC框架中实现了通过JDK和CGLib调用真实方法的功能。但是，如果在真实场景中，需要支持其他的方式调用真实方法，此时，就不得不修改框架的源代码了，这种方式是非常不友好的。

所以，我们需要对服务提供者端调用真实方法的代码进行优化，使其能够基于SPI进行扩展。

本章，就先基于SPI扩展JDK反射机制调用真实方法。

三、设计

如果让你设计基于SPI扩展JDK反射机制调用真实方法，你会怎么设计呢？

基于SPI扩展JDK反射机制调用真实方法的流程图如图37-1所示。

由图37-1可以看到，服务提供者会以SPI的形式引用调用真实方法的SPI接口，基于JDK的反射机制调用真实方法是SPI接口的一种实现，服务提供者会通过SPI加载JDK反射机制调用真实方法的实现类。而JDK反射机制调用真实方法的实现类会实现SPI接口，最终调用真实方法。

四、实现

说了这么多，具体要怎么实现呢？

核心类实现关系

基于SPI扩展JDK反射机制调用真实方法的核心类关系如图37-2所示。

查看完整文章

加入冰河技术 (opens new window)知识星球，解锁完整技术文章与完整代码