Dubbo学习记录二

记录在研究Dubbo代码中的学习点  （@SPI的接口类的接口方法的@Adaptive）

1  在与Spring进行整合的时候，利用Spring的xml配置创建出一系列的配置对象，存到Spring容器中

application 对应于ApplicationConfig

registry 对应 RegistryConfig

moniotr 对应 MonitorConfig

provider 对应 ProviderConfig

consumer 对应ConsumerConfig

protocol 对应ProtocolConfig

service 对应ServeriConfig

reference 对应ReferenceConfig

上面的对象不依赖Spring，如果想直接通过API启动，可以手动创建上述对象

对于提供者来说，为了在Spring启动的时候，也相应的启动provider发布服务注册服务的过程，加入一个和Spring相关联的ServiceBean，继承了ServiceConfig，而这个ServiceBean就是provider与Spring整合的关键

ServiceBean除了继承dubbo的配置抽象类以外，还实现了一系列的Spring接口用来参与到Spring容器的启动以及bean的创建过程中，由于ServiceBean是单例模式（每个配置就是唯一的一个ServiceBean，包含的interface以及ref都已经固定了），每个接口配置都需要一个<dubbo:service>配置项， 每个ServiceBean在初始化后，由于该类实现了InitializingBean，所以在初始化完成后会调用afterPropertiesSet完成整个dubbo的配置加载过程，而同时ServiceBean又实现了ApplicationListener，所以会在整个Spring容器加载完成后接收到消息，完成onApplicationEvent方法的调用，该方法就会将该ServiceBean配置的接口等信息完成服务的发布

同理对于消费者来说，就有ReferenceBean和ReferenceConfig，这两个完全对应ServiceBean和ServiceConfig，但是有个不同，因为提供者ServiceBean需要在Spring启动的时候就提供服务，所以是通过onApplicationEvent后完成的，但是消费者ReferenceBean是在程序需要的时候才会去执行，如果通过配置在Spring启动的过程中完成初始化是并不是合适的做法，而是在应用程序需要用到的时候，再去创建。所以ReferenceBean实现了FactoryBean，所以在通过Spring框架getBean的时候调用的是ReferenceBean的getObject方法，返回的是

    // 接口代理类引用
    private transient volatile T ref;

而这个引用对于每个<dubbo:reference>也是唯一的，因为会缓存起来，所以虽然ReferenceBean看上去是工厂模式，实际上返回的都是同一个引用，所以模拟成工厂bean主要是为了在应用程序需要吧使用的时候才去创建对象，毕竟Proxy创建的成本还是比较大的，这样做也能很大程序提高程序的效率