A brief introduction to Dubbo Registry

In Dubbo microservices, the registry is one of its core components. Dubbo realizes the registration and discovery of various services in distributed environment through the registry, which is the link between various distributed nodes. Its main functions are as follows:

  • Dynamic join. Through the registry, a service provider can dynamically register its services in the registry and expose them to other consumers without the need for consumers to modify the configuration file for operation.

  • Dynamic discovery. In contrast, a consumer can dynamically perceive new configurations, route changes and contact new service providers without restarting the service for them to take effect.

  • Dynamic adjustment. The registry supports dynamic adjustment of parameters. New parameters are automatically updated to the relevant nodes, including service consumers, service providers, and so on.

  • Unified configuration. This avoids the problem that there are too many services and the configuration of each service is inconsistent.

The source code for the Dubbo Registry center is in Dubbo – Registry, which contains five submodules as shown below

As can be seen from the module of Dubbo-Registry, Dubbo mainly contains four kinds of registry implementations, namely ZooKeeper, Redis, Simple and Multicast.

Zookeeper, as the official recommended registry, has been widely used in the generation practice, and the specific content is in the Dubbo-Registry-ZooKeeper module. Inside Ali, Redis is not used as the registration center, and Redis has not been effectively verified whether it runs reliably. Its stability mainly depends on Redis. The Simple registry is a Simple memory-based registry implementation that is itself a standard RPC service that does not support cluster deployment and is subject to single points of failure. The Multicast model does not require any registries, as long as the broadcast address, can be found. When the service provider starts up, it broadcasts its own address. The service provider receives the subscription request and broadcasts it to the subscriber based on the configuration. This mode is not recommended for production environments.

Dubbo is very scalable and can be extended based on RegistryFactory and Registry if none of the above registries meet the requirements.

Dubbo Registry workflow

The overall process of the registry is relatively simple, and is explained in detail on the Dubbo website, as shown in the figure below

  • When the service provider starts, it writes its own metadata information to the registry and subscribes to configuration metadata information.
  • When a service consumer starts, it wants to write its own metadata information to the registry and subscribe to the service provider, routing, and configuration metadata information.
  • When the Service Governance Center (Dubo-admin) is started, it subscribes to all consumers, service providers, routes, and configuration meta-information simultaneously.
  • When a service provider leaves or a new service provider joins, the registry service provider catalog changes, and the change information is dynamically notified to consumers, service governance centers, and so on.
  • When the consumer initiates a service invocation, the invocation and statistics are asynchronously reported to the monitoring center (Dubbo-monitor-simple).

Dubbo Registry Zookeeper principle

Zookeeper is similar to the Linux file tree structure and is divided into the following four types of nodes

  • Persistent node: After service registration, the node is guaranteed not to be lost and the registry will still exist after restart
  • Persistent sequential node: The ability to add the sequential order of nodes to a persistent node
  • Temporary node: After service registration, the registered node will be automatically removed if the connection is lost or the Session times out
  • Temporary sequential nodes: Added the sequential ordering capability to the temporary node feature

When Dubbo uses Zookeeper as its registry, it creates two types of persistent nodes and temporary nodes, without much requirement on the creation order. Of course, some business scenarios can use this feature to achieve some content.

For example/dubbo/com. Nihui. TestService/will is the service provider in the path of a Zookeeper registry examples. It’s a tree structure

+dubbo
+--service
     +-- providers
     +-- consumers
     +-- routers
     +-- configurators
Copy the code

Tree structure relation:

  • (1) The root node of the tree is the registry group, which has multiple service interfaces from the group attribute in dubbo: Registry in the user configuration. The default is /dubbo.
  • (2) The service interface contains four subdirectories, including distributed Provicers, consumers, Routers, and Configurators. These paths are persistent nodes.
  • (3) Directory providers of service providers, including the URL metadata information of multiple service providers.
  • (4) Directory consumers of service consumers, including URL metadata information whose interfaces are multiple consumers.
  • (5) Routing configuration directories for routers, which contain metadata information of consumption routing policies in Togo.
  • Configurators, which contains metadata information for dynamically configuring urls for servers.

When the Dubbo framework is started, four directories are created in the registry according to user-defined services. Providers and consumers directories store metadata information of service providers and consumers respectively, including IP addresses, ports, weights, and application names.

When the Dubbo framework invokes services, users can use the service governance platform dubbo-admin to deliver routing configurations. If the parameters need to be changed during the running, you can deliver the dynamic configuration through the service governance platform dubbo-admin. The server receives property changes through the subscription mechanism and reexposes the modified service information. As shown in the figure below

All parameters in the service metadata are stored as key-value pairs. Take service metadata as an example

<beans>
    <! -- Zookeeper cluster -->
    <dubbo:registry protocol="zookeeper" address="ip:port,ip:port"/>
    <dubbo:registry protocol="zookeeper" address="ip:port,ip:port"/>
</beans>
Copy the code

Dubbo Registry Overview of Redis principles

The Redis registry also uses Dubbo’s abstract data structures of Root, Service, Type and URL. However, because Redis is a NoSQL database, data is stored in the form of key-value pairs, rather than in the form of tree storage like Zookeeper. Therefore, Redis is suitable for the implementation of Key/Map structure. Root, Service, and Type are combined into the Key of Redis. Redis value is a Map structure, with THE URL as the Key of the Map and the timeout time as the value of the Map, as shown in the figure.

The relevant code in the process of data structure assembly is as follows

String key = toCategoryPath(url)

String value = url.toFullString();

jedis.hset(key,value,expire);

Copy the code

conclusion

The above content mainly introduces the Dubbo registry related content, including the principle of Dubbo registry and two registries implementation scheme. The main purpose of this sharing is to help you understand how the Dubbo registry works and the data structure of the two registries.