dubbo版本:2.6.1
dubbo客户端硬编码方式的实现:最终通过referenceConfig的get方法完成消息的订阅.

get方法中调用init()方法:
在init()方法中完成了参数的赋值和一些校验,接着调用:
ref = createProxy(map);
如果客户端传递的url(代表着前面各种参数的集合)只有一个,则调用:
invoker = refprotocol.refer(interfaceClass, urls.get(0));
如果url有多个,即多个注册中心,则循环加入invoker的集合.
根据前台的url解析出最终要调用的protocol,当然和服务端一样,也需要经过
protocolListenerWrapper->protocolFilterWrapper->RegistryProtocol完成与通信模块以及注册中心的调用,最后走到自己在一开始定义的dubboProtocol:
Invoker<T> refer(Class<T> serviceType, URL url)
在registry模块,默认使用的是failBackRegistry,在一个注册中心调用失败的时候会自动寻找下一个.
最后一步就是需要根据返回的invoker实例获取到proxy:

也就是说根据JavassistProxyFactory返回的proxy实例就相当于最后客户端得到的ref.
整体流程思路:

在了解过服务端后,客户端理解起来也会简单容易,这里没有多分析内部的代码实现,给个简单的流程思路,在自己跟代码跑的时候就可以清晰一点了.
本文介绍了Dubbo 2.6.1版本中客户端(consumer层)的调用过程,详细讲解了从referenceConfig的get方法开始,如何通过init()方法初始化,包括参数赋值和校验,直至createProxy(map)生成代理对象。当URL只有一个时,直接创建Invoker,若有多个URL(多注册中心),则将Invoker加入集合。解析出的protocol与服务端类似,经过层层包装,最后由dubboProtocol执行实际通信。客户端还涉及到注册中心的failBack机制,确保调用的健壮性。整体流程提供了一个理解和跟踪代码的简化思路。
511

被折叠的 条评论
为什么被折叠?



