Dubbo as consumer registration process analysis

Please support the original: Http://www.cnblogs.com/donlianli/p/3847676.html The author currently analyzes the version is 2.5.x. The author in the analysis, are with questions to see the code, debug debugging, I write this article for reference only. Let's take a look at the process of the system as a consumer from startup to registration completion.

1. When the system starts, referencing the service first registers the system itself with the reference to zookeeper, then subscribes to the services required by the system, and finally receives the subscription information sent by zookeeper. For example, a consumer registered a userservice, the system at the start, the first statement that they are userservice a consumer, and then to zookeeper declare that they need to subscribe to UserService, finally, from zookeeper receive subscription services, Then store them locally.
2. If multiple interfaces are referenced at the same time, the services above are repeated multiple times.
3. The Montitorservice is executed before the subscription is executed.

Question: 1, Dubbo is through which class interacts with the zookeeper? 2. What class does the Dubbo store the subscription information in?

Registryprotocol.dorefer the registration here, will call failbackregistry.registry for real registration, the actual interaction with zookeeper, call is Zookeeperregistry Doregistry method. If the registration fails, the URL is added to the scheduled task for retry.

Abstractregistry.notify truly receives notification of zookeeper. Where is the Notify interface added to the Zookeeper Change event? In the Dosubscribe method of the Zookeeperregistry code (in the code that interacts with zookeeper), the subscribed interface is sent to zookeeper, and the list of available services is obtained from zookeeper. Zookeeperregistry Code:

Zkclient.create (path, false);//This is the service zookeeper returns the client subscription list<string> children = Zkclient.addchildlistener (path, Zklistener);  if (children! = null) {                     urls.addall (tourlswithempty (URL, path, children));} Outside the loop, notify the list that is already available.  Notify (URL, listener, URLs), called Abstractregistry.notify

Abstractregistry after receiving the notification, store the URL and continue to notify Notifylistener. Where did Notifylistener put the registry? The Registrydirectory.subscribe method is called when the Registryprotocol subscribes to the service. Registrydirectory This class itself implements the Notifylistener interface, and when invoking Failbackregistry's subscribe method, passes itself as a parameter to the Abstractregistry object. So abstractregistry after receiving the notice, continue to inform is registrydirectory. The Registrydirectory class maintains a mapping relationship from local methods to remote methods, remote parameters to local method invocation relationships, and so on. Several major classes in the registration process Zookeeperregistry: Responsible for interacting with zookeeper Registryprotocol: Obtain available services from the registry, or register the service with zookeeper, and then provide the service or provide the calling agent. registrydirectory: Maintains all available remote invoker or local invoker. This class implements the Notifylistner. Notifylistener: Responsible for registrydirectory and zookeeperregistry communication. FailbackregistrY: Inherits from registry, implements the failure retry mechanism. Answer the first question 1, through ZookeeperregistryInteracting with zookeeper, the related classes are also zookeeperclient,zkclientzookeeperclient and org.I0Itec.zkclient.ZkClient classes. By means of these classes, the registration and subscription of services and the delivery of information are implemented. 2, mainly abstractregistry and registrydirectory of the two classes. Where Registrydirectory stores the invoker that can be called directly by the client, Abstractregistry this class primarily stores the service interfaces that have been registered, the service interfaces that have been subscribed to, and the URLs of the interfaces that have been notified, and cannot be called directly.

Dubbo as consumer registration process analysis