Introduction to Dubbo and Zookeeper as the registration center

Enter image description

Dubbo is a distributed services framework and SOA governance solution. Its functions mainly include: high-performance NIO communication and multi-protocol integration, service dynamic addressing and routing, soft load balancing and fault tolerance, dependency analysis and degradation, etc. It has 5 nodes, namely Provider, Consumer, Registry, Monitor, Container. Provider is a service provider, Consumer is a service consumer, Registry is a registry where services are registered and discovered, Monitor is a monitoring center that counts the number and time of service calls, and Container is a service running container. The calling relationship between them is: Container is responsible for starting, loading and running Provider. The Provider will register the services it provides with the registry when it starts up, and the Consumer will subscribe to the Registry for the services it needs when it starts. At this time, the Registry will return the Provider address list to the Consumer. If the address changes, the Registry will push the change data to the Consumer based on the persistent connection. The Consumer will select one provider to call based on the soft load balancing algorithm. If the call fails, it will select another provider. Provider and Consumer accumulate the number of calls and call time in memory, and periodically send statistical data to Monitor every minute. Dubbo has four characteristics, namely connectivity, robustness, scalability, and upgradeability to future architectures. Connectivity means that there is a relationship between them. For example, Provider, Consumer and Registry are all long connections, and Provider and Consumer have to report to the Monitor when they register services with the Registry and subscribe to services. The robustness of Jian indicates that it is stable. For example, when any one of the peer-to-peer clusters in the registry goes down, it will automatically switch to another. Even if the registry is down, the server and the consumer can still communicate through the local cache. The scalability is that new registries and service providers can be added by adding machine deployment instances. The upgradeability is the vision of the future architecture mentioned in the document. Compared with the current framework, it is characterized by a local proxy that can automatically deploy services and can automatically increase or decrease service providers through access pressure.

When Zookeeper acts as the registration center of Dubbo: When the service provider is initialized and started, it will create a child node and write the URL in the node under the providers node under the service node under the Dubbo node under Zookeeper and write the URL, the path is /dubbo/servicename/ providers/ , all child nodes under this path are service providers. At this point, these child nodes are all temporary nodes, because the life cycle of the temporary node is related to the client session, so once the machine where the provider is located fails and the provider cannot provide services, the temporary node will be automatically deleted from Zookeeper. At this time, because there is a long connection between the server, the registry, and the consumer, the registry can sense that the server is down and notify the consumer. The monitoring center is an important part of the Dubbo service governance system. It needs to know the changes of all service providers and consumers. So when it starts, it will register a watcher on the service node to monitor child node changes, the path is /dubbo/servicename/, so it can also sense the downtime of the service provider. The node creation process for service consumers is the same as for providers, and it is also a temporary node. Another feature is the node structure design of Zookeeper. It uses the service name and type, that is, /dubbo/servicename/ type as the node path, which meets the requirements of Dubbo subscription and notification, and ensures service-level change notification, and the scope of notification is easy control. So even if service providers and consumers change frequently, it will not have much impact on the performance of Zookeeper.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325330418&siteId=291194637