Dubbo Registration Center (1)-Overview

Overview

In the Dubbo microservice system, the registry is one of its core components. Dubbo realizes
registration and discovery between services in a distributed environment through the registration center , which is the link between distributed nodes. Its main functions are as follows:
1. Dynamically join. A service provider can dynamically expose itself to other consumers through the registry, without the need for
consumers to update configuration files one by one

2. Dynamic discovery. A consumer can dynamically perceive new configurations, routing rules, and new service providers without having to
restart the service to make them effective.
3. Dynamic adjustment. The registration center supports dynamic adjustment of parameters, and new parameters are automatically updated to all relevant service nodes.
4. Unified configuration. This avoids the problem of inconsistent configuration of each service caused by local configuration.

Dubbo's registry source code is in the module dubbo-registry, which contains five sub-modules, as shown in the figure below

As can be seen from the module of dubbo-registry , Dubbo mainly includes the implementation of four registration centers, namely ZooKeeper , Redis , Simple , and Multicast .
Among them, ZooKeeper is the officially recommended registration center. It has been actually used in the production environment. The specific implementation is in the dubbo-registry-zookeeper module of the Dubbo source code.

Dubbo has good scalability. If none of the above registries can meet the needs, then users can expand by themselves based on RegistryFactory and Registry. Later chapters will specifically introduce the extension of the registry

work process


The overall process of the registration center is relatively simple, and Dubbo officials also have more detailed instructions. The overall process is shown in Figure 3-1.
• When the service provider starts, it will write its own metadata information to the registry, and will subscribe to the configuration metadata information at the same time.
• When consumers start, they will also write their own metadata information to the registry, and subscribe to service providers, routing and
configuration metadata information.
• When the service management center (dubbo-admin) is started, it will simultaneously subscribe to all consumers, service providers, routing and
configuration metadata information.
• When a service provider leaves or a new service provider joins, the registry service provider directory will change
, and the change information will be dynamically notified to consumers and the service management center.
• When the consumer initiates a service call, it will asynchronously report the call, statistical information, etc. to the monitoring center (dubbo-monitor・simple)

data structure


The overall process of the registration center is the same, but different registration centers have different implementation methods and their data structures are also different.
ZooKeeper. Redis and other registries have implemented this process. Since some registries are not commonly used, this chapter only
analyzes the data structures implemented by ZooKeeper and Redis.
Overview of ZooKeeper principle

ZooKeeper is a tree-structured registry, and each node type is divided into persistent nodes, persistent sequential nodes, temporary
nodes and temporary sequential nodes.
• Persistent node: After the service is registered, it is guaranteed that the node will not be lost, and the registry will also exist after restarting.
• Persistent sequence nodes: The ability to sequence nodes is added on the basis of the characteristics of persistent nodes.
• Temporary node: After the service is registered, the connection is lost or the session times out, the registered node will be automatically removed.
• Temporary sequence node: On the basis of the feature of temporary node, the ability of node sequence is added.
When Dubbo uses ZooKeeper as the registry, it will only create persistent nodes and temporary nodes,
and there is no requirement on the order of creation .
/dubbo/com.foo.BarService/providers is an example of the path of the service provider in the ZooKeeper registry. It
is a tree structure. The structure is divided into four layers: root (root node, corresponding to dubbo in the example), service ( Interface name,
corresponding to com.foo.BarService in the example)>Four service directories (corresponding to providers in the example, other directories include
consumers, routers, and configurators). Under the service classification node is the specific Dubbo service URL.
An example of the tree structure is as follows:
+ /dubbo
+-- service
+-- providers
+-- consumers
+-- routers
+-- configurators
The relationship of the tree structure:
(1) The root node of the tree is the registry group. There are multiple service interfaces below. The group value comes from
the group attribute in the user configuration <dubbo:registry>, and the default is /dubbo.
(2) There are 4 types of subdirectories under the service interface, namely providers>
this path is a persistent node.
consumers> routers> configurators,
(3) Service provider directory (/dubbo/service/providers)
metadata information.
(4)
Metadata information of the service consumer directory (/dubbo/service/consumers) .
(5) The routing configuration directory (/dubbo/service/routers) contains multiple
metadata information for consumer routing strategies . Routing configuration will be introduced in detail in Chapter 7.
(6) The dynamic configuration directory (/dubbo/service/configurators) contains multiple
URL metadata information for the dynamic configuration of the server . Dynamic configuration will also be described in detail in Chapter 7.
Let's make a simple demonstration through the tree structure, as shown in the figure below.

When Dubbo frame start, according to the configurations of the service, to create four directories in the registry, the providers
and consumers directories are stored service providers, consumer metadata information, including IP, port, weight and should be
used Name and other data.
When invoking a service in the Dubbo framework, users can issue routing configurations through the service management platform (dubbo-admin)
. If you want to change service parameters at runtime, users can issue dynamic configurations through the service management platform (dubbo-admin)
. The server will receive the attribute changes through the subscription mechanism and renew the exposed services.
Before explaining the internal principles of Dubbo in depth, you can refer to the information contained in the table of contents in Table 3-2.

All parameters in the service metadata are stored in the form of key-value pairs. Take the service metadata as an example:
dubbo://192.168.0.1.20880/com.alibaba.demo.Service?category=provider&name=demo-prov
ider&.. The service metadata contains 2 key-value pairs, the first key For category, the value associated with key is provider.
To enable the registry in Dubbo, you can refer to the following methods:
<beans>
<!--Applicable to ZooKeeper
—A cluster has multiple nodes, and multiple IPs and ports are separated by commas--> <dubbo:registry protocol="zookeeper" address ="ip:port, ip:port" />
<!--Suitable for ZooKeeper multiple clusters with multiple nodes, multiple IPs and ports are separated by vertical bars-->
<dubbo:registry protocol="zookeeper" address= "ip:port|ip:port" />
</beans>
Redis principle overview

The Redis registry also uses the four-layer structure of Root, Service> Type> URL abstracted by Dubbo. However, because Redis
belongs to a NoSQL database, data is stored in the form of key-value pairs, and it cannot directly implement a tree-shaped
directory structure like ZooKeeper . Therefore, Redis uses the key/Map structure to achieve this requirement. Root, Service, and Type are combined into Redis
's keyo. The value of Redis is a Map structure, the URL is used as the key of the Map, and the timeout period is used as the value of the Map,
as shown in the following figure.