dubbo作为消费者注册过程分析
请支持原创：
http://www.cnblogs.com/donlianli/p/3847676.html
作者当前分析的版本为2.5.x。作者在分析的时候，都是带着疑问去查看代码，debug进行调试的，笔者写此文章仅供参考。
先大概了解一下系统作为一个消费者从启动到注册完成的过程
- 系统启动时，引用service时首先将系统本身自己需要引用的服务注册到zookeeper，然后订阅系统需要的服务，最后，会接收到zookeeper发送的订阅信息。比如一个消费者注册了一个UserService，系统在启动时，首先声明自己是UserService的一个消费者，然后再向zookeeper声明自己需要订阅UserService，最后，从zookeeper接收订阅的服务，然后存储到本地。
- 如果同时引用多个接口，则上面的服务会重复执行多次。
- montitorService是在执行的时候，才执行订阅。
问题：
1、dubbo是通过哪个类跟zookeeper进行交互的？
2、dubbo把订阅的信息存储到了哪个类？
RegistryProtocol.doRefer这里面进行的注册，将调用FailbackRegistry.registry进行真正的注册，实际跟zookeeper进行交互，调用的是ZookeeperRegistry的doRegistry方法。如果注册失败，会将url添加定定时任务中进行重试。
AbstractRegistry.notify真正接收到zookeeper的通知。在那儿将notify接口添加到zookeeper的改变事件的呢？
在ZookeeperRegistry代码的doSubscribe方法中（与zookeeper进行交互的代码中），将订阅的接口发送给zookeeper，并且从zookeeper取得可用的服务列表。
ZookeeperRegistry代码：
zkClient.create(path, false); //这个是zookeeper返回客户端订阅的服务 List<String> children = zkClient.addChildListener(path, zkListener); if (children != null) { urls.addAll(toUrlsWithEmpty(url, path, children)); } 在循环之外，将已经可用的列表进行通知。 notify(url, listener, urls);，调用了AbstractRegistry.notify
AbstractRegistry在收到通知后，将url进行存储，继续通知NotifyListener。
NotifyListener是在哪儿放入Registry的呢？
在RegistryProtocol订阅服务的时候，会调用RegistryDirectory.subscribe方法。RegistryDirectory这类本身就实现了NotifyListener接口，在调用FailbackRegistry的subscribe方法的时候，把自己当成一个参数传递给了AbstractRegistry对象。所以AbstractRegistry在收到通知后，继续通知的是RegistryDirectory。
RegistryDirectory这个类维护着从本地方法到远程方法的映射关系，远程参数到本地方法的调用关系等。
在注册过程中的几个主要类
ZookeeperRegistry：负责与zookeeper进行交互
RegistryProtocol：从注册中心获取可用服务，或者将服务注册到zookeeper，然后提供服务或者提供调用代理。
RegistryDirectory：维护着所有可用的远程Invoker或者本地的Invoker。这个类实现了NotifyListner。
NotifyListener：负责RegistryDirectory和ZookeeperRegistry的通信。
FailbackRegistry：继承自Registry，实现了失败重试机制。
回答一开始的问题
1、通过ZookeeperRegistry和Zookeeper进行交互，相关的类还有ZookeeperClient，ZkclientZookeeperClient和org.I0Itec.zkclient.ZkClient类。通过这些类的方法，实现服务的注册和订阅及信息的传递。
2、主要是AbstractRegistry和RegistryDirectory这两个类。其中RegistryDirectory存储的可供客户端直接调用的Invoker，而AbstractRegistry这个类主要存储的是已经注册的服务接口，已经订阅的服务接口和已经收到通知的接口的URL，不能直接调用。
