代理模式

从Dubbo-SPI说开去

在dubbo暴露服务时,ServiceConfig中有这样一行代码

//
private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

代码大义:即通过SPI机制动态加载Protocol实现类,然后获取自适应实例;

    private Class<?> createAdaptiveExtensionClass() {
        String code = createAdaptiveExtensionClassCode();
        ClassLoader classLoader = findClassLoader();
        com.alibaba.dubbo.common.compiler.Compiler compiler = ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.common.compiler.Compiler.class).getAdaptiveExtension();
        return compiler.compile(code, classLoader);
    }

在构造动态适配类之前,会先扫描META-INF/services/,META-INF/dubbo目录下的service实现类,利用反射机制

• 构造实例,set注入
• 构造函数注入
  然后,构造java代码,大致逻辑为,根据URL参数,获取具体要执行的实现类名,然后也是通过调用ExtensionLoader.getExtensionLoader(Protocol.class).getExtension("name")获取实现类;
  代码构造完成后,通过javassist编译java代码,动态加载class类

动态代理

• 通过上面的例子,我们可以大致清楚下面几件事
  • 在调用方,我们无需关注具体的类实现
  • 代理类动态给我们提供不同的实现,我们只需按需传参即可

思考

在扩展性层面,代理模式带给我们更多可能,我们新增实现,在调用方无感知的情况下,通过动态调整调用参数,即可完成多元化的需求.同时我们也需要去思考,如何去根据不同场景,抽象出一个好的代理接口.