Dubbo泛化调用

1.泛化调用

DubboBootstrap#start()

①初始化

②暴露服务exportServices：ConfigManager配置管理者把所有配置(包括应用、注册中心、服务)存放在Map容器中，暴露服务时会取出所有ServiceConfig执行export进行暴露。

③引用服务referServices：首先先从configManager中取出所有的ReferenceConfig，执行get方法初始化。首先根据引用配置对象生成key然后从缓存中取代理，如果没有则通过调用ReferenceConfig的init方法创建代理对象。

DubboBootstrap启动流程 (opens new window)

ReferenceConfigCache

ReferenceConfig实例是一个比较重的实例，其中init初始化方法里，实现了通过与注册中心与提供者连接创建代理的过程。因此需要ReferenceConfigCache作为缓存，根据referenceConfig对象生成的key获取对应的泛化代理对象。最终Dubbo代理是通过Javassist字节码增强技术创建动态代理。

此处key的生成规则是group/版本/接口，可以根据业务和场景需求通过SPI修改生成策略。

2.Dubbo缓存

• referenceConfig获取GenericService泛化调用对象时，会先从缓存取出实例化对象

①根据实验结果分析，这里服务提供方接口缓存是持久化的缓存，也就是说Dubbo每向zk暴露一个泛化接口，都会保存在本地，无论zk与Dubbo启动还是关闭都存在。

②从缓存Map中取出泛化服务引用的key，是根据分组+版本号+接口全限定名来生成。

这也就解释了为什么后面改了一个版本号就又不能进行泛化调用了。

• 如果缓存没有实例化过，则会调用init根据Dubbo连接传入的配置，实例化"服务引用"

实例化"服务引用"过程默认要check服务提供者是否存在，不存在则抛异常导致实例化失败(此时已经在zookeeper上创建了消费者节点)。下一次通过ReferenceConfig获取"服务引用"又会失败(也会创建消费者节点，消费者节点上会带上时间戳所以每次都会创建新的节点)。可能会出现无限重复创建zk消费者节点。