Shulou(Shulou.com)05/31 Report--

This article mainly explains "what is the design concept of Dubbo". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the design concept of Dubbo".

1. Service registration and discovery mechanism

Dubbo's service registration and discovery mechanism is shown in the following figure:

There are four types of roles in Dubbo:

Registry registry.

Consumer service caller, consumer.

Provider service provider.

Monitor monitoring center.

The specific interaction process includes the following key steps:

The service provider registers with the registry at startup.

The message consumer subscribes to the specified service from the registry at startup, and the registry will inform the consumer of the list of service providers in some mechanism (push or pull) mode.

When the number of service providers changes (such as expansion, reduction, downtime, etc.), the registry needs to inform the consumer in some way (push or pull) so that the consumer can carry out normal load balancing.

Service providers and service consumers report TPS and other call data to the monitoring center for visual display by the monitoring center.

Dubbo officially provides a variety of registries, and then we will further introduce the principles of registries with the most commonly used Zookeeper.

First of all, let's take a look at the data storage directory structure in the Zookeeper registry and peek into its implementation mechanism from the directory structure.

The Dubbo Zookeeper registry has a directory organization structure of / dubbo/ {ServiceName}, and there are 4 directories under each service name:

List of providers service providers.

Consumers Consumer list

List of routers routing rules, multiple routing rules can be set for a service.

Configurators dynamic configuration entry. In Dubbo, you can dynamically modify the configuration of service providers and service providers without restarting consumers and service providers, such as the number of threads, timeout and other parameters.

The details of the implementation based on Zookeeper registry are as follows:

When the service provider starts, it registers with the registry, mainly by adding a record (temporary node) under the providers directory of the corresponding service, while listening on the configurators node.

When starting, service consumers subscribe to the registry, mainly by adding a record (temporary node) under the consumers directory of the corresponding service, while listening to the configurators and routers directories.

Because a record is added to the providers directory when a new service provider comes online, consumers can immediately receive a notification of a change in the list of service providers and push the latest list of service providers to the service caller (consumer side). If a service provider goes down, because the created node is a temporary node, Zookeeper will remove the node, which will also trigger an event, and the consumer will know the latest list of service providers, thus realizing the dynamic registration and discovery of routes.

When the new version of Dubbo is launched, if you need to publish in grayscale, you can add routing rules through management platforms such as dubbo-admin, which will eventually be written to the router node (persistent node) of the specified service. The service caller will listen to the changes of this node, thus perceiving the latest routing rules and using them to filter service providers to achieve grayscale publishing and other functions.

The operation mechanism of configurators node is the same as that of router node, so it will not be introduced repeatedly.

Expand your thinking:

1. If the registry is completely down, what will be the impact on the entire service system?

If the whole registry is down, the whole service invocation can work properly and will not affect the existing service consumer invocation, but the consumer can not find the newly registered service provider.

2. If the registry memory overflows or Full Gc occurs frequently, what will be the impact on the entire cluster?

If Full GC occurs frequently, and if the Full GC time exceeds the expiration time of the Zookeeper session, it will have a very serious impact. It will trigger all temporary nodes to be deleted, consumers will not be aware of the existence of service providers, affect service calls, and will throw errors such as No provider in a large area. It is called a temporary node for success and a temporary node for failure.

In order to avoid the serious consequences of Full Gc, Zookeeper used in Dubbo registries must be exclusive, and monitor and alarm memory and CPU in a timely manner.

2. Service call

Dubbo's service invocation design is elegant, and its implementation principle is shown in the following figure:

Service invocation, which focuses on all the implementation details when the client initiates a RPC service call, including service discovery, failover, route forwarding, load balancing and so on, is the theoretical basis for Dubbo to achieve grayscale publishing.

2.1 Service Discovery

When a client initiates a request to the server, the first thing it needs to know is which service providers are currently available. There are usually two service discovery mechanisms:

Static configuration may recall that before the advent of micro-service frameworks such as Dubbo, the common practice for one module to call another module was to use a configuration file to configure the list configuration provided by the service in the configuration file, and the client fell according to the list in the configuration file.

Its disadvantages are also very obvious: if there are many services to be called, the configuration file will become bloated, and it is not friendly to the management of capacity expansion and reduction, machine downtime and other changes, and the management is very difficult.

Dynamic discovery

The registration and dynamic discovery of services are usually implemented based on the registry, and since it has been described in detail above, I will not repeat it here.

2.2 load balancing

Through the service discovery mechanism, the client can dynamically discover the list of current surviving service providers. The next thing to consider is if you select a service provider from the list of service providers to initiate the call, which is the so-called load balancing, namely LoadBalance.

Load balancing algorithms such as random, weighted random, least active connections and consistent Hash are provided by default in Dubbo.

2.3 routing mechanism

In fact, Dubbo provides not only load balancing mechanism, but also intelligent routing mechanism, which is the theoretical basis of Dubbo grayscale publishing.

The so-called routing mechanism is to set certain rules in the list of service providers to filter and select. When load balancing, it is only selected from the list of service providers filtered by route filtering rules. In order to more vividly explain the working principle of the routing mechanism, the following diagram is given:

A routing rule is set above, that is, the query user request information with ID 102 of the query organization should be sent to the new version, that is, 19168.3.102, which mainly executes the routing rule before load balancing, filters the original service provider list according to the routing rule, and selects the list of providers that meet the requirements, and then carries out the load balancing.

The core idea of the routing mechanism is to apply routing rules to the list of service providers before load balancing to get a list of providers participating in load balancing.

2.4 failover

Remote service invocation usually involves factors such as network. When a client initiates a RPC request call to a service provider, it may not be 100% successful. What strategy should be adopted when the invocation fails?

Dubbo provides the following strategies:

If the failover fails, select another service provider to retry. The number of retries can be configured, which is usually suitable for scenarios where idempotent services are implemented.

Failfast

Fail quickly and return an error immediately after failure.

After a failed failsafe call, an error log is printed and a success is returned. It is usually used to record audit logs and other scenarios.

When the failback call fails, it returns success, but it will be retried indefinitely in the background, and will not be retried after reboot.

Forking is called concurrently, and the first response result is received and returned to the client. It is usually suitable for scenarios with high real-time requirements, but server resources are wasted. You can usually set the degree of concurrent invocation through forks parameters.

3. Thread dispatch mechanism

The communication thread model of Dubbo is shown in the following figure:

3.1 Network communication protocol

Network transmission usually requires a custom communication protocol, which usually adopts the protocol design concept of Header + Body, and the Header is of fixed length and contains a length field to record the size of the entire protocol packet.

In order to improve the transmission efficiency, network transmission can compress the transmitted data, usually serializing and compressing the body.

Dubbo supports java, compactedjava, nativejava, fastjson, fst, hessian2, kryo and other serialization protocols.

3.2 Thread dispatch mechanism

By default in Dubbo, 200 threads are created to handle business methods. The so-called thread dispatch mechanism is how IO threads decide which requests are forwarded to which threads for execution.

Currently, all heartbeats and network reads and writes in Dubbo are performed in IO threads and cannot be modified through configuration.

Dubbo provides the following thread dispatch mechanisms (Dispatcher):

All all requests are forwarded to the business thread pool for execution (except IO read / write, heartbeat)

The message executes only in the request event thread pool, and the rest is executed on the IO thread.

Connection request events are executed in the thread pool, and connect and disconnect events are queued for execution (a thread pool with one thread).

Direct

All requests are executed directly in the IO thread.

> Tip: for more information about threading model and network communication mode, please refer to the following article.

Thread dispatch mechanism will have a variety of strategies, mainly considering whether the overhead caused by thread switching can be tolerated, that is, the overhead caused by thread switching is less than that caused by multithreading.

For example, in Dubbo, you only need to return the PONG packet (OK) directly to the heartbeat package. The logic is very simple. If you convert it to the business thread pool, it will not bring performance improvement. On the contrary, it will bring performance loss due to the need for thread switching, so it is very desirable to send the response package directly in the IO thread.

There is a best practice to follow in network programming: there can be no blocking operations in IO threads, and blocking operations need to be forwarded to the business thread pool.

Thank you for your reading, the above is the content of "what is the design concept of Dubbo". After the study of this article, I believe you have a deeper understanding of what the design concept of Dubbo is, and the specific use needs to be verified by practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.